Menu
▾
▴
numpy-discussion
|
From: Rudolph v. d. M. <rud...@gm...> - 2006-10-19 12:35:36
|
I get the following error with RC3 on a RHE Linux box: Python 2.4.3 (#4, Mar 31 2006, 12:12:43) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy >>> numpy.__version__ '1.0rc3' >>> numpy.test() Found 5 tests for numpy.distutils.misc_util Found 3 tests for numpy.lib.getlimits Found 31 tests for numpy.core.numerictypes Found 32 tests for numpy.linalg Found 13 tests for numpy.core.umath Found 4 tests for numpy.core.scalarmath Found 9 tests for numpy.lib.arraysetops Found 42 tests for numpy.lib.type_check Found 183 tests for numpy.core.multiarray Found 3 tests for numpy.fft.helper Found 36 tests for numpy.core.ma Found 12 tests for numpy.lib.twodim_base Found 10 tests for numpy.core.defmatrix Found 1 tests for numpy.lib.ufunclike Found 4 tests for numpy.ctypeslib Found 41 tests for numpy.lib.function_base Found 2 tests for numpy.lib.polynomial Found 8 tests for numpy.core.records Found 26 tests for numpy.core.numeric Found 4 tests for numpy.lib.index_tricks Found 47 tests for numpy.lib.shape_base Found 0 tests for __main__ .......................................................................................................Warning: invalid value encountered in divide ..Warning: invalid value encountered in divide ..Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide ..Warning: invalid value encountered in divide .Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide ..Warning: invalid value encountered in divide ..Warning: invalid value encountered in divide ..Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide .Warning: divide by zero encountered in divide ........Warning: invalid value encountered in divide .Warning: invalid value encountered in divide ..Warning: divide by zero encountered in divide ........................................................................................................................................................................................................Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide Warning: divide by zero encountered in divide .....................Warning: invalid value encountered in sqrt Warning: invalid value encountered in log Warning: invalid value encountered in log10 ..Warning: invalid value encountered in sqrt Warning: invalid value encountered in sqrt Warning: divide by zero encountered in log Warning: divide by zero encountered in log Warning: divide by zero encountered in log10 Warning: divide by zero encountered in log10 Warning: invalid value encountered in arcsin Warning: invalid value encountered in arcsin Warning: invalid value encountered in arccos Warning: invalid value encountered in arccos Warning: invalid value encountered in arccosh Warning: invalid value encountered in arccosh Warning: divide by zero encountered in arctanh Warning: divide by zero encountered in arctanh Warning: invalid value encountered in divide Warning: invalid value encountered in true_divide Warning: invalid value encountered in floor_divide Warning: invalid value encountered in remainder Warning: invalid value encountered in fmod ............................................................................................................................................................... ---------------------------------------------------------------------- Ran 516 tests in 0.368s OK <unittest.TextTestRunner object at 0xb7abf46c> >>> -- Rudolph van der Merwe KAT (Karoo Array Telescope) / www.kat.ac.za |
|
From: Tim H. <tim...@ie...> - 2006-10-19 13:32:45
|
Rudolph van der Merwe wrote:
> I get the following error with RC3 on a RHE Linux box:
>
> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
>>>> import numpy
>>>> numpy.__version__
>>>>
> '1.0rc3'
>
[SNIP lots of warnings]
Ah! I see that Travis has turned up the default warning level.
Excellent! This will require some tweaking of the tests, but that
shouldn't be a big deal. If I have time I will try to work on that later
today. For the moment, try this:
>>> olderr = numpy.seterr(all='ignore')
>>> numpy.test()
>>> numpy.seterr(*olderr)
This should run the tests with the warnings suppressed.
On a visual studio build, I'm getting a real failure though:
FAIL: Ticket #112
----------------------------------------------------------------------
Traceback (most recent call last):
File
"C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
line 219, in check_longfloat_repr
assert(str(a)[1:9] == str(a[0])[:8])
AssertionError
The code in question is dependent on the spelling of INF(or at least the
*length* of the spelling) on a given platform which is why it's failing.
I suspect that the correct test is:
str(a)[1:-1] == str(a[0])
However, I'm not entirely sure what this is testing, so I'm reluctant to
check that in.
-tim
|
|
From: Ted H. <ted...@ea...> - 2006-10-26 12:56:50
|
On Mac OS X tiger (10.4) ppc, long double has increased precision but
the same range as double (it really is 128 bits not 80, btw), so
e**1000 is inf, so this is not really an error.
I'm not sure what is the right thing to do in the test, check for
overflow? Also, finfo has never worked properly for this type.
Ted
On Oct 23, 2006, at 05:50, Mark Hymers wrote:
> On Thu, 19, Oct, 2006 at 08:29:26AM -0600, Travis Oliphant spoke
> thus..
>> Actually, you shouldn't be getting an INF at all. This is what the
>> test is designed to test for (so I guess it's working). The test was
>> actually written wrong and was never failing because previously
>> keyword
>> arguments to ufuncs were ignored.
>>
>> Can you show us what 'a' is on your platform.
>
> Hi,
>
> I've just done a Mac OS X PPC build of the SVN trunk and am getting
> this
> failure too.
>
> nidesk046:~/scratch/upstream/scipy mark$ python
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy as N
>>>> N.__version__
> '1.0.dev3378'
>>>> N.array([1000],dtype=N.float).dtype
> dtype('float64')
>>>> N.array([1000],dtype=N.longfloat).dtype
> dtype('float128')
>>>> N.test()
> ...snip...
> FAIL: Ticket #112
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/numpy/core/tests/test_regression.py", line
> 220, in check_longfloat_repr
> assert(str(a)[1:9] == str(a[0])[:8])
> AssertionError
>>>> a = N.exp(N.array([1000],dtype=N.longfloat))
>>>> str(a)
> '[inf]'
>
>
> Any ideas about this?
>
> Mark
>
> --
> Mark Hymers <mark at hymers dot org dot uk>
>
> "I once absent-mindedly ordered Three Mile Island dressing in a
> restaurant
> and, with great presence of mind, they brought Thousand Island
> Dressing and
> a bottle of chili sauce."
> Terry Pratchett, alt.fan.pratchett
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> _________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
|
|
From: Charles R H. <cha...@gm...> - 2006-10-26 15:20:46
|
On 10/26/06, Ted Horst <ted...@ea...> wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased precision but > the same range as double (it really is 128 bits not 80, btw), Looks like you are right: http://www.freestandards.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html#PREC Actually two doubles with some strange rules, the quad value is the sum. Hmmm, I can see why compiler support was problematic. The extended precision also has some oddities. This "Extended precision" differs from the IEEE 754 Standard in the following ways: - The software support is restricted to round-to-nearest mode. Programs that use extended precision must ensure that this rounding mode is in effect when extended-precision calculations are performed. - Does not fully support the IEEE special numbers NaN and INF. These values are encoded in the high-order double value only. The low-order value is not significant. - Does not support the IEEE status flags for overflow, underflow, and other conditions. These flag have no meaning in this format. so > e**1000 is inf, so this is not really an error. > > I'm not sure what is the right thing to do in the test, check for > overflow? Also, finfo has never worked properly for this type. See above. Chuck |
|
From: Charles R H. <cha...@gm...> - 2006-10-26 17:08:57
|
On 10/26/06, Travis Oliphant <oli...@ie...> wrote: > > Ted Horst wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased precision but > > the same range as double (it really is 128 bits not 80, btw), so > > e**1000 is inf, so this is not really an error. > > > > > > Thanks for the clarification. Long-double is not standard across > platforms with different platforms choosing to do different things with > the extra bytes. This helps explain one more platform. > > > I'm not sure what is the right thing to do in the test, check for > > overflow? Also, finfo has never worked properly for this type. > > > In machar.py is the code that runs to detect all of the parameters. I > think the code should be moved to C as detecting precision on a > long-double takes too long. > > The overflow check is a good idea. The test should probably check for > overflow and not try to run if it's detected. How to check overflow? According to the documentation the flag is not set by the hardware. And the precision is variable! Somewhere in the neighborhood of 31 decimal digits, more or less, depending. So I think it is hard to figure out what to do here. Chuck. |
|
From: Travis O. <oli...@ie...> - 2006-10-26 18:12:42
|
Charles R Harris wrote: > > > On 10/26/06, *Travis Oliphant* <oli...@ie... > <mailto:oli...@ie...>> wrote: > > Ted Horst wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased > precision but > > the same range as double (it really is 128 bits not 80, btw), so > > e**1000 is inf, so this is not really an error. > > > > > > Thanks for the clarification. Long-double is not standard across > platforms with different platforms choosing to do different things > with > the extra bytes. This helps explain one more platform. > > > I'm not sure what is the right thing to do in the test, check for > > overflow? Also, finfo has never worked properly for this type. > > > In machar.py is the code that runs to detect all of the > parameters. I > think the code should be moved to C as detecting precision on a > long-double takes too long. > > The overflow check is a good idea. The test should probably check for > overflow and not try to run if it's detected. > > > How to check overflow? According to the documentation the flag is not > set by the hardware. And the precision is variable! Somewhere in the > neighborhood of 31 decimal digits, more or less, depending. So I think > it is hard to figure out what to do here. Let's drop the test. Long-double is available but is not consistent across platforms and NumPy has done nothing to try and make it so. Thus, let's just let the user beware. -Travis |
|
From: Ted H. <ted...@ea...> - 2006-10-27 00:55:18
|
On Oct 26, 2006, at 12:26, Travis Oliphant wrote: > Charles R Harris wrote: >> >> >> On 10/26/06, *Travis Oliphant* <oli...@ie... >> <mailto:oli...@ie...>> wrote: >> >> Ted Horst wrote: >>> On Mac OS X tiger (10.4) ppc, long double has increased >> precision but >>> the same range as double (it really is 128 bits not 80, btw), so >>> e**1000 is inf, so this is not really an error. >>> >>> >> >> Thanks for the clarification. Long-double is not standard >> across >> platforms with different platforms choosing to do different >> things >> with >> the extra bytes. This helps explain one more platform. >> >>> I'm not sure what is the right thing to do in the test, check for >>> overflow? Also, finfo has never worked properly for this type. >>> >> In machar.py is the code that runs to detect all of the >> parameters. I >> think the code should be moved to C as detecting precision on a >> long-double takes too long. >> >> The overflow check is a good idea. The test should probably >> check for >> overflow and not try to run if it's detected. >> >> >> How to check overflow? According to the documentation the flag is not >> set by the hardware. And the precision is variable! Somewhere in the >> neighborhood of 31 decimal digits, more or less, depending. So I >> think >> it is hard to figure out what to do here. > > Let's drop the test. Long-double is available but is not consistent > across platforms and NumPy has done nothing to try and make it so. > Thus, let's just let the user beware. > > -Travis Yeah, that seem like the thing to do. Just for completeness: >>> N.seterr(all = 'raise') >>> fa = N.array([1e308], dtype=N.float) >>> lfa = N.array([1e308], dtype=N.longfloat) >>> fa + fa Traceback (most recent call last): File "<stdin>", line 1, in ? FloatingPointError: overflow encountered in add >>> lfa + lfa Traceback (most recent call last): File "<stdin>", line 1, in ? FloatingPointError: overflow encountered in add >>> N.exp(fa) Traceback (most recent call last): File "<stdin>", line 1, in ? FloatingPointError: overflow encountered in exp >>> N.exp(lfa) array([inf], dtype=float128) Ted |
|
From: Travis O. <oli...@ie...> - 2006-10-19 14:28:29
|
Tim Hochberg wrote: > Rudolph van der Merwe wrote: > >> I get the following error with RC3 on a RHE Linux box: >> >> Python 2.4.3 (#4, Mar 31 2006, 12:12:43) >> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >> >> >>>>> import numpy >>>>> numpy.__version__ >>>>> >>>>> >> '1.0rc3' >> >> > > On a visual studio build, I'm getting a real failure though: > > FAIL: Ticket #112 > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py", > line 219, in check_longfloat_repr > assert(str(a)[1:9] == str(a[0])[:8]) > AssertionError > > The code in question is dependent on the spelling of INF(or at least the > *length* of the spelling) on a given platform which is why it's failing. > Actually, you shouldn't be getting an INF at all. This is what the test is designed to test for (so I guess it's working). The test was actually written wrong and was never failing because previously keyword arguments to ufuncs were ignored. Can you show us what 'a' is on your platform. -Travis |
|
From: Tim H. <tim...@ie...> - 2006-10-19 15:05:23
|
Travis Oliphant wrote: > Tim Hochberg wrote: > >> Rudolph van der Merwe wrote: >> >> >>> I get the following error with RC3 on a RHE Linux box: >>> >>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43) >>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 >>> Type "help", "copyright", "credits" or "license" for more information. >>> >>> >>> >>>>>> import numpy >>>>>> numpy.__version__ >>>>>> >>>>>> >>>>>> >>> '1.0rc3' >>> >>> >>> >> On a visual studio build, I'm getting a real failure though: >> >> FAIL: Ticket #112 >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py", >> line 219, in check_longfloat_repr >> assert(str(a)[1:9] == str(a[0])[:8]) >> AssertionError >> >> The code in question is dependent on the spelling of INF(or at least the >> *length* of the spelling) on a given platform which is why it's failing. >> >> > > Actually, you shouldn't be getting an INF at all. This is what the > test is designed to test for (so I guess it's working). The test was > actually written wrong and was never failing because previously keyword > arguments to ufuncs were ignored. > > Can you show us what 'a' is on your platform. Sure: >>> import numpy as N >>> a = N.exp(N.array([1000],dtype=N.longfloat)) Warning: overflow encountered in exp >>> a array([1.#INF], dtype=float64) |
|
From: Travis O. <oli...@ee...> - 2006-10-19 15:10:23
|
Tim Hochberg wrote: >Travis Oliphant wrote: > > >>Tim Hochberg wrote: >> >> >> >>>Rudolph van der Merwe wrote: >>> >>> >>> >>> >>>>I get the following error with RC3 on a RHE Linux box: >>>> >>>>Python 2.4.3 (#4, Mar 31 2006, 12:12:43) >>>>[GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 >>>>Type "help", "copyright", "credits" or "license" for more information. >>>> >>>> >>>> >>>> >>>> >>>>>>>import numpy >>>>>>>numpy.__version__ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>'1.0rc3' >>>> >>>> >>>> >>>> >>>> >>>On a visual studio build, I'm getting a real failure though: >>> >>> FAIL: Ticket #112 >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File >>> "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py", >>> line 219, in check_longfloat_repr >>> assert(str(a)[1:9] == str(a[0])[:8]) >>> AssertionError >>> >>>The code in question is dependent on the spelling of INF(or at least the >>>*length* of the spelling) on a given platform which is why it's failing. >>> >>> >>> >>> >>Actually, you shouldn't be getting an INF at all. This is what the >>test is designed to test for (so I guess it's working). The test was >>actually written wrong and was never failing because previously keyword >>arguments to ufuncs were ignored. >> >>Can you show us what 'a' is on your platform. >> >> >Sure: > > >>> import numpy as N > >>> a = N.exp(N.array([1000],dtype=N.longfloat)) >Warning: overflow encountered in exp > >>> a >array([1.#INF], dtype=float64) > > O.K. We need to modify the test in case to check and see that the size of longfloat isn't the same as double. -Travis |
|
From: Tim H. <tim...@ie...> - 2006-10-19 16:49:00
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>
>> Travis Oliphant wrote:
>>
>>
>>
>>> Tim Hochberg wrote:
>>>
>>>
>>>
>>>
>>>> Rudolph van der Merwe wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I get the following error with RC3 on a RHE Linux box:
>>>>>
>>>>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>>>>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>> import numpy
>>>>>>>> numpy.__version__
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> '1.0rc3'
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> On a visual studio build, I'm getting a real failure though:
>>>>
>>>> FAIL: Ticket #112
>>>> ----------------------------------------------------------------------
>>>> Traceback (most recent call last):
>>>> File
>>>> "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>>>> line 219, in check_longfloat_repr
>>>> assert(str(a)[1:9] == str(a[0])[:8])
>>>> AssertionError
>>>>
>>>> The code in question is dependent on the spelling of INF(or at least the
>>>> *length* of the spelling) on a given platform which is why it's failing.
>>>>
>>>>
>>>>
>>>>
>>>>
>>> Actually, you shouldn't be getting an INF at all. This is what the
>>> test is designed to test for (so I guess it's working). The test was
>>> actually written wrong and was never failing because previously keyword
>>> arguments to ufuncs were ignored.
>>>
>>> Can you show us what 'a' is on your platform.
>>>
>>>
>>>
>> Sure:
>>
>>
>>>>> import numpy as N
>>>>> a = N.exp(N.array([1000],dtype=N.longfloat))
>>>>>
>> Warning: overflow encountered in exp
>>
>>>>> a
>>>>>
>> array([1.#INF], dtype=float64)
>>
>>
>>
> O.K. We need to modify the test in case to check and see that the size
> of longfloat isn't the same as double.
>
How about:
def check_longfloat_repr(self,level=rlevel):
"""Ticket #112"""
if N.dtype(N.longfloat) != N.dtype(N.float):
a = N.exp(N.array([1000],dtype=N.longfloat))
assert(str(a)[1:9] == str(a[0])[:8])
That seems to work here.
-tim
|
|
From: Tim H. <tim...@ie...> - 2006-10-19 17:08:54
|
[CHOP]
OK, I've checked in changes to suppress all the warnings in the test
suite. I tried to be as targeted as possible so that any regressions
from the current state in terms of warnings should show up.
I suspect that there may be some issues with regards to masked arrays
issuing spurious warnings. I'm not a ma user, so I didn't take the time
to investigate this, but someone who cares should probably look at this
and consider how to resolve it.
Also with regard to the recent addition of the errcall argument to
errstate, it appears that if errcall is *not* specified, self.errcall
will be set to None. This means that any existing error callback will be
removed when entering the block (and replaced when you leave). I don't
think that's the desired behavior. Instead, if errcall is not specified,
I believe we should leave the value of errcall alone. Does that sound
right, or am I missing something? This would result in something like:
def __init__(self, **kwargs):
if 'errcall' in kwargs:
self.errcall = kwargs.pop('errcall')
else:
self.errcall = geterrcall()
self.kwargs = kwargs
This still allows you to set the errcall to None for the block by using:
with errstate(errcall=None):
# do stuff
Hmm. Should that be 'errcall' or just 'call'? 'errstate(errcall...)'
seems somewhat redundant.
Finally, and this is a moot point anyway assuming the above rewrite, is
there a reason to use:
if 'errcall' in kwargs:
self.errcall = kwargs.pop('errcall')
else:
self.errcall = geterrcall()
rather than simply:
self.errcall = kwargs.pop('errcall', None)
?
regards,
-tim
|
|
From: Tim H. <tim...@ie...> - 2006-10-19 15:09:10
|
Travis Oliphant wrote:
> Tim Hochberg wrote:
>
>> Rudolph van der Merwe wrote:
>>
>>
>>> I get the following error with RC3 on a RHE Linux box:
>>>
>>> Python 2.4.3 (#4, Mar 31 2006, 12:12:43)
>>> [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>
>>>
>>>>>> import numpy
>>>>>> numpy.__version__
>>>>>>
>>>>>>
>>>>>>
>>> '1.0rc3'
>>>
>>>
>>>
>> On a visual studio build, I'm getting a real failure though:
>>
>> FAIL: Ticket #112
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File
>> "C:\Python24\lib\site-packages\numpy\core\tests\test_regression.py",
>> line 219, in check_longfloat_repr
>> assert(str(a)[1:9] == str(a[0])[:8])
>> AssertionError
>>
>> The code in question is dependent on the spelling of INF(or at least the
>> *length* of the spelling) on a given platform which is why it's failing.
>>
>>
>
> Actually, you shouldn't be getting an INF at all. This is what the
> test is designed to test for (so I guess it's working). The test was
> actually written wrong and was never failing because previously keyword
> arguments to ufuncs were ignored.
>
> Can you show us what 'a' is on your platform.
>
I expect that the problem is related to this:
>>> N.array([1000],dtype=N.float).dtype
dtype('float64')
>>> N.array([1000],dtype=N.longfloat).dtype
dtype('float64')
longfloat appears to just be an alias for float under VS.
-tim
> -Travis
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>
|
|
From: Mark H. <ma...@hy...> - 2006-10-23 11:00:36
|
On Thu, 19, Oct, 2006 at 08:29:26AM -0600, Travis Oliphant spoke thus..
> Actually, you shouldn't be getting an INF at all. This is what the=20
> test is designed to test for (so I guess it's working). The test was=20
> actually written wrong and was never failing because previously keyword=
=20
> arguments to ufuncs were ignored.=20
>=20
> Can you show us what 'a' is on your platform.
Hi,
I've just done a Mac OS X PPC build of the SVN trunk and am getting this
failure too.
nidesk046:~/scratch/upstream/scipy mark$ python
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)=20
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as N
>>> N.__version__
'1.0.dev3378'
>>> N.array([1000],dtype=3DN.float).dtype
dtype('float64')
>>> N.array([1000],dtype=3DN.longfloat).dtype
dtype('float128')
>>> N.test()
=2E..snip...
FAIL: Ticket #112
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/sit=
e-packages/numpy/core/tests/test_regression.py", line 220, in check_longflo=
at_repr
assert(str(a)[1:9] =3D=3D str(a[0])[:8])
AssertionError
>>> a =3D N.exp(N.array([1000],dtype=3DN.longfloat))
>>> str(a)
'[inf]'
Any ideas about this?
Mark
--=20
Mark Hymers <mark at hymers dot org dot uk>
"I once absent-mindedly ordered Three Mile Island dressing in a restaurant
and, with great presence of mind, they brought Thousand Island Dressing and
a bottle of chili sauce."
Terry Pratchett, alt.fan.pratchett
|
|
From: Mark H. <ma...@hy...> - 2006-10-24 09:57:52
|
On Mon, 23, Oct, 2006 at 11:50:27AM +0100, Mark Hymers spoke thus..
> Hi,
>=20
> I've just done a Mac OS X PPC build of the SVN trunk and am getting this
> failure too.
<snip>
> FAIL: Ticket #112
</snip>
I've just been looking into this a bit further (though I may be heading
down the wrong road) and come across this which doesn't exactly look
right. Again this is on a PPC Mac OS X 10.4 install:
In [1]: import numpy
In [2]: numpy.__version__=20
Out[2]: '1.0.dev3390'
In [3]: print numpy.finfo(numpy.float32).min, numpy.finfo(numpy.float32).ma=
x, numpy.finfo(numpy.float32).eps
-3.40282346639e+38 3.40282346639e+38 1.19209289551e-07
In [4]: print numpy.finfo(numpy.float64).min, numpy.finfo(numpy.float64).ma=
x, numpy.finfo(numpy.float64).eps
-1.79769313486e+308 1.79769313486e+308 2.22044604925e-16
In [5]: print numpy.finfo(numpy.float128).min, numpy.finfo(numpy.float128).=
max, numpy.finfo(numpy.float128).eps
Warning: overflow encountered in add
Warning: invalid value encountered in subtract
Warning: invalid value encountered in subtract
Warning: overflow encountered in add
Warning: invalid value encountered in subtract
Warning: invalid value encountered in subtract
9223372034707292160.0 -9223372034707292160.0 1.38178697010200053743e-76
Anyone got any comments /thoughts on this? Should I file it as a bug?
I just tested this on an x86 Linux box (running Debian though that
should be irrelevant) and numpy.float128 doesn't exist on x86 Linux
but float96 does gives:
>>> print numpy.finfo(numpy.float96).min, numpy.finfo(numpy.float96).max, n=
umpy.finfo(numpy.float96).eps
-1.18973149535723176502e+4932 1.18973149535723176502e+4932 1.08420217248550=
443401e-19
which seems right.
Any ideas?
Cheers,
Mark
--=20
Mark Hymers <mark at hymers dot org dot uk>
"The relationship between journalists and politicians has often been likened
to that between a dog and a lamp post, although I have never worked out who
is supposed to be which."
Nick Assinder, BBC Online Political Correspondent
|
|
From: Charles R H. <cha...@gm...> - 2006-10-24 13:48:42
|
On 10/24/06, Mark Hymers <ma...@hy...> wrote: > > On Mon, 23, Oct, 2006 at 11:50:27AM +0100, Mark Hymers spoke thus.. > > Hi, > > > > I've just done a Mac OS X PPC build of the SVN trunk and am getting this > > failure too. > <snip> > > FAIL: Ticket #112 > </snip> > > I've just been looking into this a bit further (though I may be heading > down the wrong road) and come across this which doesn't exactly look > right. Again this is on a PPC Mac OS X 10.4 install: > > In [1]: import numpy > > In [2]: numpy.__version__ > Out[2]: '1.0.dev3390' > > In [3]: print numpy.finfo(numpy.float32).min, numpy.finfo(numpy.float32).max, > numpy.finfo(numpy.float32).eps > -3.40282346639e+38 3.40282346639e+38 1.19209289551e-07 > > In [4]: print numpy.finfo(numpy.float64).min, numpy.finfo(numpy.float64).max, > numpy.finfo(numpy.float64).eps > -1.79769313486e+308 1.79769313486e+308 2.22044604925e-16 > > In [5]: print numpy.finfo(numpy.float128).min, numpy.finfo(numpy.float128).max, > numpy.finfo(numpy.float128).eps > Warning: overflow encountered in add > Warning: invalid value encountered in subtract > Warning: invalid value encountered in subtract > Warning: overflow encountered in add > Warning: invalid value encountered in subtract > Warning: invalid value encountered in subtract > 9223372034707292160.0 -9223372034707292160.0 1.38178697010200053743e-76 These aren't right. Are you running on a 64 bit system? Currently float80, float96, and float128 are all float80 with different alignments, so show up as float96 on 32 bit machines and float128 on 64 bit machines. This is probably set by a combination of compiler defaults and machine architecture. It sounds like something is getting misidentified, but I don't know much about that. Anyone got any comments /thoughts on this? Should I file it as a bug? > I just tested this on an x86 Linux box (running Debian though that > should be irrelevant) and numpy.float128 doesn't exist on x86 Linux > but float96 does gives: My impression is that it is a bug. Chuck |
|
From: Travis O. <oli...@ie...> - 2006-10-24 16:30:24
|
Mark Hymers wrote:
> On Thu, 19, Oct, 2006 at 08:29:26AM -0600, Travis Oliphant spoke thus..
>
>> Actually, you shouldn't be getting an INF at all. This is what the
>> test is designed to test for (so I guess it's working). The test was
>> actually written wrong and was never failing because previously keyword
>> arguments to ufuncs were ignored.
>>
>> Can you show us what 'a' is on your platform.
>>
>
> Hi,
>
> I've just done a Mac OS X PPC build of the SVN trunk and am getting this
> failure too.
>
I thought we had this fixed.
The basic problem is that the longfloat type is not very
cross-platform. The functionality depends on your C-compiler /
platform when a long double is specified as the type. I suspect it
doesn't work well with all compilers. In particular gcc 3.3 on apple I
know has trouble with the long double type.
Bascially, the "failure" is a failure of the platform. The best we can
do in NumPy is not run the test or print something instead of raising an
error.
> nidesk046:~/scratch/upstream/scipy mark$ python
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>
>>>> import numpy as N
>>>> N.__version__
>>>>
> '1.0.dev3378'
>
>>>> N.array([1000],dtype=N.float).dtype
>>>>
> dtype('float64')
>
>>>> N.array([1000],dtype=N.longfloat).dtype
>>>>
> dtype('float128')
>
Please show us what N.array([1000],dtype=N.longfloat).itemsize is?
-Travis
|
|
From: Mark H. <ma...@hy...> - 2006-10-24 17:39:47
|
On Tue, 24, Oct, 2006 at 10:31:30AM -0600, Travis Oliphant spoke thus..
> The basic problem is that the longfloat type is not very=20
> cross-platform. The functionality depends on your C-compiler /=20
> platform when a long double is specified as the type. I suspect it=20
> doesn't work well with all compilers. In particular gcc 3.3 on apple I=
=20
> know has trouble with the long double type.
Ah. I've just realised that we're using a MacPython build compiled with
gcc-3.3 but our default compiler is 4.0.1. This could be causing an
issue. Let me try building the extension with gcc-3.3 and, if I can
find one, upgrading python to a version compiled with 4.0 (I really
don't want to have to do a framework python build from source though).
> Please show us what N.array([1000],dtype=3DN.longfloat).itemsize is?
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.0.dev3390'
>>> numpy.array([1000],dtype=3Dnumpy.longfloat).itemsize
16
Cheers,
Mark
--=20
Mark Hymers <mark at hymers dot org dot uk>
"I once absent-mindedly ordered Three Mile Island dressing in a restaurant
and, with great presence of mind, they brought Thousand Island Dressing and
a bottle of chili sauce."
Terry Pratchett, alt.fan.pratchett
|
|
From: Mark H. <ma...@hy...> - 2006-10-24 17:50:35
|
On Tue, 24, Oct, 2006 at 10:31:30AM -0600, Travis Oliphant spoke thus..
> The basic problem is that the longfloat type is not very=20
> cross-platform. The functionality depends on your C-compiler /=20
> platform when a long double is specified as the type. I suspect it=20
> doesn't work well with all compilers. In particular gcc 3.3 on apple I=
=20
> know has trouble with the long double type.
Apologies, I'm a complete moron.
If you compile python with gcc-3.3 and the module with 4.0, things
break. If I recompile numpy with gcc-3.3, you just don't get a
float80,96 or 128 type which as far as I'm concerned is fine; certainly
much better than it breaking. This is all on Mac OS X 10.4, I haven't
had time to look at what would happen with a python and module compiled
with 4.0. Sigh, the sooner we move these machines to Debian the better :-)
Cheers,
Mark
--=20
Mark Hymers <mark at hymers dot org dot uk>
"I told you I was ill"
The epitaph of Spike Milligan (1918-2002)
|
|
From: Travis O. <oli...@ie...> - 2006-10-26 16:13:11
|
Ted Horst wrote: > On Mac OS X tiger (10.4) ppc, long double has increased precision but > the same range as double (it really is 128 bits not 80, btw), so > e**1000 is inf, so this is not really an error. > > Thanks for the clarification. Long-double is not standard across platforms with different platforms choosing to do different things with the extra bytes. This helps explain one more platform. > I'm not sure what is the right thing to do in the test, check for > overflow? Also, finfo has never worked properly for this type. > In machar.py is the code that runs to detect all of the parameters. I think the code should be moved to C as detecting precision on a long-double takes too long. The overflow check is a good idea. The test should probably check for overflow and not try to run if it's detected. -Travis |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X