I don't know if your 'long double' detection code is complete yet, but I
thought I'd share the current build output on one of our Solaris
machines. It looks like it may just be a typo difference between
'IEEE_QUAD_BE' in long_double_representation() and 'IEEE_QUAD_16B_BE' in
setup.py, but I wanted to confirm.
> uname -a
SunOS grail.stsci.edu 5.8 Generic_117350-62 sun4u sparc SUNW,Ultra-5_10
compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/stsci/pyssgdev/Python-2.5.4/include/python2.5 -c'
cc: _configtest.c
removing: _configtest.c _configtest.o
Traceback (most recent call last):
File "setup.py", line 187, in <module>
setup_package()
File "setup.py", line 180, in setup_package
configuration=configuration )
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/core.py", line 186, in setup
return old_setup(**new_attr)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 974, in run_commands
self.run_command(cmd)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/install.py", line 52, in run
r = old_install.run(self)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/command/install.py", line 506, in run
self.run_command('build')
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build.py", line 37, in run
old_build.run(self)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/command/build.py", line 112, in run
self.run_command(cmd_name)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/stsci/pyssgdev/Python-2.5.4/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 152, in run
self.build_sources()
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 169, in build_sources
self.build_extension_sources(ext)
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 328, in build_extension_sources
sources = self.generate_sources(sources, ext)
File "/grail/data1/iraf/work/build.grail.numpy.iraf/numpy/numpy/distutils/command/build_src.py", line 385, in generate_sources
source = func(extension, build_dir)
File "numpy/core/setup.py", line 425, in generate_config_h
raise ValueError("Unrecognized long double format: %s" % rep)
ValueError: Unrecognized long double format: IEEE_QUAD_BE
David Cournapeau wrote:
> On Thu, Nov 5, 2009 at 4:55 AM, Michael Droettboom <mdroe at stsci.edu> wrote:
>
>> David Cournapeau wrote:
>>
>>> On Thu, Nov 5, 2009 at 2:15 AM, Michael Droettboom <mdroe at stsci.edu> wrote:
>>>
>>>
>>>> I'm getting the following from r7603 on Solaris Sparc -- somehow related
>>>> to not having a long double version of next after available. I realise
>>>> not everyone has access to (or is dependent on) this platform, so I'm
>>>> willing to help in whatever way I can, I'm just not sure I understand
>>>> the change yet.
>>>>
>>>>
>>> The only way to implement nextafter that I know of requires to know
>>> the exact representation of the floating point number, and long double
>>> is unfortunately platform dependent.
>>>
>>> What is the long double format on solaris sparc ? (big endian I
>>> suppose, but how many bits for the mantissa and exponent ? Does it
>>> follow IEER754 ?)
>>>
>>>
>> I honestly don't know -- I've never had to use them. It would be great
>> to solve this properly but it's difficult to find definitive information
>> about these things.
>>
>> Assuming we can't solve this the "right" way before the next release,
>> would it be possible for this to raise a runtime "NotImplemented" error
>> (by not defining the LONGDOUBLE_nextafter ufunc) rather than raising a
>> compiler error which prevents the build from completing?
>>
>
> To be honest, I thought this condition would never arise (I am quite
> surprised that solaris does not have nextafter - both BSD and GNU libc
> use the Sun implementation for this function).
>
> If this is not fixed within the code freeze (16th november), the
> feature will be removed altogether for 1.4.0. I don't want to go down
> the road of different feature set for different platforms.
>
> David
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA