On Wed, Mar 31, 2010 at 11:03 PM, Anne Archibald <peridot.faceted@gmail.com>wrote:
On 31 March 2010 16:21, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, Mar 31, 2010 at 11:38 AM, T J <tjhnson@gmail.com> wrote:
On Wed, Mar 31, 2010 at 10:30 AM, T J <tjhnson@gmail.com> wrote:
Hi,
I'm getting some strange behavior with logaddexp2.reduce:
from itertools import permutations import numpy as np x = np.array([-53.584962500721154, -1.5849625007211563, -0.5849625007211563]) for p in permutations([0,1,2]): print p, np.logaddexp2.reduce(x[list(p)])
Essentially, the result depends on the order of the array...and we get nans in the "bad" orders. Likely, this also affects logaddexp.
Sorry, forgot version information:
$ python -c "import numpy;print numpy.__version__" 1.5.0.dev8106 __
Looks like roundoff error.
No. The whole point of logaddexp and logaddexp2 is that they function correctly - in particular, avoid unnecessary underflow and overflow - in this sort of situation. This is a genuine problem.
Well, it did function correctly for me ;) Just some roundoff error.
I see it using the stock numpy in Ubuntu karmic: In [3]: np.logaddexp2(-0.5849625007211563, -53.584962500721154) Out[3]: nan
In [4]: np.logaddexp2(-53.584962500721154, -0.5849625007211563) Out[4]: nan
In [5]: np.log2(2**(-53.584962500721154) + 2**(-0.5849625007211563)) Out[5]: -0.58496250072115608
In [6]: numpy.__version__ Out[6]: '1.3.0'
In [8]: !uname -a Linux octopus 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux
(the machine is a 32-bit Pentium M laptop.)
I think this is related to 32 bits somehow. The code for the logaddexp and logaddexp2 functions is almost identical. Maybe the compiler? Chuck