This issue contains a list of the missing specialisations in qutip-tensorflow. These are shorted by priority.

• reshape (PR #22)
• norm (PR #24)
• ptrace
• permute
• dimensions
• indices
• eigs (written locally but tests missing)
• make:
• diag
• one_element
• constant
• zeros
• identity
• properties
• isherm
• isdiag
• iszero
• tidyup (should not be needed after PR 1615 in QuTiP)

Note that although these operations do not have specialisations, the will still work since QuTiP will default to the specialisation for one of the other data types. This is a problem for auto differentiation though it realistically only affects ptrace, permute and eigs.

To be written.

Description

One of features that QuTiP brings with the new data layer is the possibility to automatically convert between data layers to perform operations for which an specialisation does not exist. This is useful in some cases as it means you will not need to define every specialisation once a new data type has been added. However, this may pose some problems for qutip-tensorflow as we do not want automatic conversion of data types to happen, for example, when using the following non-defined specialisation:
add(TfTensor128, TfTenso64)
I am no sure whether TfTensor128 will be downcasted to TfTensor64 or the other way around. In any case, if such operation is being performed I would prefer a warning being raised. Similarly, converting from Dense to TfTensor is okay but converting TfTensor to Dense is probably not desired in most (if not all) cases. This is because it can happen automatically and not be noticed while using the automatic differentiation feature.

I anticipate that in most cases this issue will affect the user because the user forgot to convert one of the Qobj to the appropriate data type. Raising an error in some of these cases would be ideal to help debugging.

Note, that we still want to use the to method when used by the user explicitly.

Possible solution 1 - not ideal

We can create an specialisation for the cases were no conversion is wanted, add(TfTensor128, TfTensor64), add(Dense, TfTensor64) for example. This specialisation will raise a TypeError exception. However, this means that new specialisations added by other packages will still be converted, so it is not ideal.

Possible solution 2

Instead of adding a new specialisation, we can make the conversion specialisations (_tf_to_dense in this case) to raise a custom warning: NotASafeConversion. This conversion would then be caught by the to method in Qobj and be ignored assuming that the to method for Qobj is used only if the user is sure of what it is doing.

I would ideally like to raise an exception and not a warning but I am not sure how to do this as raising an exception in the conversion specialisation would also break the to method at the Qobj level. Maybe modifying the dispatcher allow this to work?

Some issues with using some basic regular qutip commands within a QObj defined with qutip_tensorflow.

Example 1: QObj.unit()

import tensorflow as tf
import qutip as qp
import numpy as np
import qutip_tensorflow as qtf

g = qp.basis(2,0).to('TfTensor128')
e = qp.basis(2,1).to('TfTensor128')

plus = (g+e).unit()

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
----> 9: plus = (g+e).unit()
File ....\lib\site-packages\qutip\core\qobj.py:1062, in Qobj.unit(self, inplace, norm, kwargs)
-> 1062     out = self / norm
File ...\lib\site-packages\tensorflow\python\util\traceback_utils.py:153, in filter_traceback.<locals>.error_handler(*args, **kwargs)
--> 153   raise e.with_traceback(filtered_tb) from None
File ...\lib\site-packages\tensorflow\python\framework\constant_op.py:102, in convert_to_eager_tensor(value, ctx, dtype)
--> 102 return ops.EagerTensor(value, ctx.device_name, dtype)
ValueError: TypeError: object of type 'Qobj' has no len()

Example 2: Trace QObj.tr()

import tensorflow as tf
import qutip as qp
import numpy as np
import qutip_tensorflow as qtf

g = qp.basis(2,0).to('TfTensor128')
e = qp.basis(2,1).to('TfTensor128')

plus = (g+e)/np.sqrt(2)

plus_dm = qp.ket2dm(plus)

print(plus_dm.tr())

 ---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
---> 13 print(plus_dm.tr())
File ...\lib\site-packages\qutip\core\qobj.py:788, in Qobj.tr(self)
--> 788 return out.real if self.isherm else out
File ...\lib\site-packages\tensorflow\python\framework\ops.py:446, in Tensor.__getattr__(self, name)
--> 446 self.__getattribute__(name)
AttributeError: 'tensorflow.python.framework.ops.EagerTensor' object has no attribute 'real'

_Versions:

• Tensorflow v2.10.0
• Qutip v5.0.0.dev0+116dc88
• Numpy v1.23.1
• Qutip-Tensorflow v0.1.0.dev0+65faa45_

Paths from the traceback data has been redacted for privacy

These are some modules in QuTiP for which there are no tests written yet. I will try to write them since they are very useful to define what an operation should do. This facilitates the development of new data types.

• Eigen
• ptrace

Currently we catch the deprecation warning from importing tensorflow in every specialisation. It may be possible to catch this in the init file instead.

I was trying to find out where the initial hooking of qutip-tensorflow and qutip happens and it turns out that its all done in convert.py when imported in the the init.py. I feel it would be a bit more verbose to see this happen inside the init as qutip-cupy does it. That makes it very clear to see and follow the magic of how qutip-tensorflow hooks on to the data layer.

@AGaliciaMartinez what do you think? I will follow this for qutip-jax.

Coming soon.

I have been able to make the following code work:

@tf.function
def fastfunction(tensor):
    print('hi')
    qobj = qutip.Qobj(tensor)
    qobj += qobj
    return qobj.data._tf

fastfunction(tf.constant([10]))  # prints hi
fastfunction(tf.constant([10]))  # Does not print hi since it only executes the graph.

It does not work with the current version of TfTensor as the instantiation process does as first step:

data = tf.constant(data)

Not sure what the error message I get means, but removing this line of code makes the above compiled function to work. tf.constant is meant to create "constant" nodes in the graph, so it makes sense it complains as you are making a constant value from a variable input. The fix is quite easy, just check if it is a tensor an do not do the tf.constant in that case. However, having fastfunction accept Qobj as input is a little bit more involved and will most likely require us to create our own qtf.function. I believe it is doable though.

These are all the functions that the TensorFlow data layer could implement. Not all of these will be specialized as the may not be necessary thanks to the to method. These are not sorted in any particular way.

Data-layer:

• copy
• to_array
• conj
• transpose
• adjoint
• trace

Specializations:

• convert:
  • to
  • create
• add:
  • add
  • sub
• matmul
• expm
• adjoint:
  • adjoint
  • conj
  • transpose
• expect:
  • expect
  • expect_super
• inner:
  • inner
  • inner_op
• mul:
  • mul
  • imul
  • neg
• kron
• norm:
  • l2
  • one
  • frobenius
  • max
  • trace
• pow
• trace

Remaining specialisations sorted by priority:

• eigen:
  • eigs
• reshape
  • reshape
  • column_stack
  • column_unstack
  • split_columns
• expect:
  • expect_super
• project
• ptrace
• make
  • diag
  • one_element
• constant
  • zeros
  • identity
• properties
  • ishemr
  • isdiag
  • iszero
• permute
  • dimensions
  • indices
• tidy_up