Floating point limitations of QObj?

[Marek Nečada]

Hi all,

I am having serious trouble getting any computations to work. It seems like it would be impossible to have any number below about 1e-12 saved in QObj.

>>> from qutip import *
QuTiP warning: cython setup failed: invalid literal for int() with base 10: '1post0'
>>> (qeye(2)*1.0e-20)*1.0e20
Quantum object: dims = [[2], [2]], shape = [2, 2], type = oper, isherm = True
Qobj data =
[[ 0.  0.]
 [ 0.  0.]]

What could be wrong?

Maybe I am missing something obvious here, because I am new to QuTiP and I am not a regular user of Python either.

Thanks for advice.

Marek

[jrjoh...@gmail.com]

You probably need to turn off the "auto tidyup" function, which removes small elements from the sparse matrices used internally in Qobj. Or alternatively you can reduce the tidyup-threshold. Try something like

from qutip import *

settings.auto_tidyup = False

or

from qutip import *

settings.auto_tidyup_atol = 1e-25

Rob

[Marek Nečada]

Thank you, I actually found this out before the approval of my original post. By looking at the source, I could not find it in the documentation until seeing the exact name of the parameters from the source. 

I think it should be mentioned in the beginning instead of in the last section of the users guide. In a big red box, preferably.

Marek

Dne úterý, 22. dubna 2014 15:54:04 UTC Robert Johansson napsal(a):

[Paul Nation]

If you need to multiply operators by 1e-20 then you are probably not making your equations dimensionless by scaling your Hamiltonian by a characteristic energy scale of your system.  If you are normalizing, and you still have constants that are that small, then you will find that your problem will be very difficult to solve given the very large difference in energy / time-scales.

We do not highlight the auto_tidyup setting until the end because changing this number is rarely needed.  Indeed, tidyup is set to remove numbers that slightly larger than machine precision ~2e-16.

Even with auto_tidyup off, if you ever add qeye(2)*1e-20 to any other operator that is of order 1e-11 or larger the small quantities will be lost in the roundoff because you get only 8 decimal places to work with.

Paul

--
You received this message because you are subscribed to the Google Groups "qutip" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qutip+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jrjoh...@gmail.com]

That said, I agree with the OP that tidyup operation can be surprise to a user since we do not emphasize that it is carried out in the documentation. It is a quite an disruptive operation when one works with small numbers, and although it is usually best to work with normalized units it is sometimes justified to work with more physical units. I had this problem myself a few times and it confused me at first too. I think that at least we should ​make it clear documentation that tidyup is carried out, or I would even favor that settings.auto_tidyup is False by default, so that it is an opt-in rather than opt-out feature. Just my two cents..

Rob

[Paul Nation]

I guess my few cents is that we should mention it, but not turn it off by default.  Using tidyup results in smaller sparse matrices and faster computations due to the fewer nonzero elements. 

I can not think of a good reason to work in physical units rather than normalized units.  One can always easily go back to units at the end of the calculation.  This is especially true for ODE solving where having dimensionless time is critical to proper/efficient evaluation by the underlying routines.

On 04/23/2014 10:32 AM, jrjoh...@gmail.com wrote:

That said, I agree with the OP that tidyup operation can be surprise to a user since we do not emphasize that it is carried out in the documentation. It is a quite an disruptive operation when one works with small numbers, and although it is usually best to work with normalized units it is sometimes justified to work with more physical units. I had this problem myself a few times and it confused me at first too. I think that at least we should ​make it clear documentation that tidyup is carried out, or I would even favor that settings.auto_tidyup is False by default, so that it is an opt-in rather than opt-out feature. Just my two cents..

Rob

[jrjoh...@gmail.com]

In my experience tidyup itself can actually be a quite time-consuming operation, so in many cases you will get a speedup if you disable it. Especially when doing a lot of arithmetic with Qobj instances, because tidyup is applied after every operation (whether it is necessary or not). In some cases, of course, you will get speedups by reducing the number of elements in the sparse matrices, but it is certainly not always the case. So I think it is a matter of what kind of use-case we should optimize for.. I would prefer opt-in rather than opt-out for this feature, but I'm also OK with keeping it as it is. If there is no consensus on this, status quo is probably the best way to go.

Rob

[Marek Nečada]

Yes, I was not working in normalized units when I encountered the problem.

Dne středa, 23. dubna 2014 6:43:23 UTC+3 Paul Nation napsal(a):

I can not think of a good reason to work in physical units rather than normalized units.  One can always easily go back to units at the end of the calculation.  This is especially true for ODE solving where having dimensionless time is critical to proper/efficient evaluation by the underlying routines.

Really? How does that matter? I would guess that if one correctly sets the time step (and does not add anything ridiculously large to it), it should not cause any issues in the floating point arithmetics.

[anna hambi]

Dear all, I had the same problem as Marek (cython setup failed: invalid literal...) and used your solution (from qutip import *  \\\  settings.auto_tidyup = False).  But when I run the qutip-test like this:

>>> from qutip import *
>>> settings.auto_tidyup = False

>>> qutip.testing.run()

I get a failure for Qobj expm

Qobj expm ... FAIL
======================================================================
ERROR: Failure: ValueError (invalid literal for int() with base 10: '1post0')
----------------------------------------------------------------------

[Marek Nečada]

Dear Anna,

this is an issue different from the one discussed in this thread. However, which operating system and QuTiP version do you use? How did you install it?

Quick google search suggests that the bug is somewhere in the cython debian package.

For me, updating cython helped. You can do that on the user level (so that you don't need to break your packaging system) like that:

 easy_install --user --upgrade cython

Marek

[anna hambi]

I have installed QuTiP on Ubuntu 14 running in an Oracle Virtual Box on Windows 8. After installation I ran the attached bash file. Your solution
easy_install --user --upgrade cython


has fixed the cython error message : ) Thanks a lot.

--
You received this message because you are subscribed to a topic in the Google Groups "qutip" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qutip/Pe2zhHBzNkE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qutip+un...@googlegroups.com.

[whoca...@hotmail.de]

Hey,

Im currently using Qutip and after the upgrade from Ubuntu 13.10 to 14.04 I would get the same Error.  easy_install --user --upgrade cython
fixed it though.

Ty!