Signed zeros: is this a bug?

[Mark Dickinson]

I get the following behaviour on Python 2.5 (OS X 10.4.8 on PowerPC,
in case it's relevant.)

>>x, y = 0.0, -0.0
x, y

(0.0, 0.0)

>>x, y = -0.0, 0.0
x, y

(-0.0, -0.0)

I would have expected y to be -0.0 in the first case, and 0.0 in the
second. Should the above be considered a bug, or is Python not
expected to honour signs of zeros? I'm working in a situation
involving complex arithmetic where branch cuts, and hence signed
zeros, are important, and it would be handy if the above code could be
relied upon to do the right thing.

Mark

[Jorge Godoy]

al***@mac.com (Alex Martelli) writes:

Incidentally (and I know you know that, Paul, but others interested in
this thread might not) fast exact rational arithmetic (based on the LGPL
library named GMP) is supplied, among other functionality, by module
gmpy, currently found at http://code.google.com/p/gmpy/ (this version is
more recent than the older one at sourceforce, which for some reason
doesn't let me update things right any more).

For some reason setuptools isn't finding it:

jupiter:~ # easy_install gmpy
Searching for gmpy
Reading http://cheeseshop.python.org/pypi/gmpy/
Reading http://code.google.com/p/gmpy/
Reading http://cheeseshop.python.org/pypi/gmpy/1.02
No local packages or download links found for gmpy
error: Could not find suitable distribution for Requirement.par se('gmpy')
I believe that setuptools isn't ready to find packages on code.google.com
yet... ;-)

--
Jorge Godoy <jg****@gmail.c om>

[Alex Martelli]

Jorge Godoy <jg****@gmail.c omwrote:

al***@mac.com (Alex Martelli) writes:

Incidentally (and I know you know that, Paul, but others interested in
this thread might not) fast exact rational arithmetic (based on the LGPL
library named GMP) is supplied, among other functionality, by module
gmpy, currently found at http://code.google.com/p/gmpy/ (this version is
more recent than the older one at sourceforce, which for some reason
doesn't let me update things right any more).

For some reason setuptools isn't finding it:

jupiter:~ # easy_install gmpy
Searching for gmpy
Reading http://cheeseshop.python.org/pypi/gmpy/
Reading http://code.google.com/p/gmpy/
Reading http://cheeseshop.python.org/pypi/gmpy/1.02
No local packages or download links found for gmpy
error: Could not find suitable distribution for Requirement.par se('gmpy')
I believe that setuptools isn't ready to find packages on code.google.com
yet... ;-)

I'm not familiar with setuptools, what exactly is it looking for?

If it's looking for stuff to download it should start at

http://code.google.com/p/gmpy/downloads/list

(but what does it want -- the sources' zipfile, or some binary, and in
what format and with what naming convention?) -- I'll be glad to edit
the URL for gmpy at cheeseshop if some setuptools expert can explain
these subtleties... thanks for pointing out that there's a problem
btw!-)
Alex

[Jorge Godoy]

al***@mac.com (Alex Martelli) writes:

I'm not familiar with setuptools, what exactly is it looking for?

If it's looking for stuff to download it should start at

http://code.google.com/p/gmpy/downloads/list

(but what does it want -- the sources' zipfile, or some binary, and in
what format and with what naming convention?) -- I'll be glad to edit
the URL for gmpy at cheeseshop if some setuptools expert can explain
these subtleties... thanks for pointing out that there's a problem
btw!-)

Thanks for caring ;-)
It looks for several things: eggs (for the Python version it is being used),
zipfiles and tarballs (I dunno if it looks for more things).

If it finds, for example, gmpy-1.0.2-py2.4.egg it won't install here 'cause I
use Python 2.5 and then it will continue searching for gmpy-1.0.2-py2.5.egg or
an alternative format that can be used. The last resort is the tarball / zip
with the sources so that the package can be rebuilt.

Probably other people that are more experienced with it can help more. I'm
more an end user of it and I know the essential for my needs.

I just pointed out because setuptools helps a lot on obtaining a package and
installing it (even if there's some building needed before installing).
Sorry for not being able to help more.
With regards to the hyperlink, I believe that if the link on Pypi was to the
URL above it would be easier. Another alternative is a link at the first
page. And, of course, the last alternative is teaching setuptools how to work
with code.google.com -- if it doesn't already know -- as it learnt how to work
with SourceForge and its "random" mirrors. I don't know how to write that
code, though.
Be seeing you,
--
Jorge Godoy <jg****@gmail.c om>

[Alex Martelli]

Jorge Godoy <jg****@gmail.c omwrote:
...

these subtleties... thanks for pointing out that there's a problem
btw!-)

Thanks for caring ;-)

Hey, I'd just love to make it as easy as possible to get gmpy -- that's
why I (shudder!-) even build and upload Windows installers...

It looks for several things: eggs (for the Python version it is being used),
zipfiles and tarballs (I dunno if it looks for more things).

If it finds, for example, gmpy-1.0.2-py2.4.egg it won't install here 'cause I
use Python 2.5 and then it will continue searching for gmpy-1.0.2-py2.5.egg or
an alternative format that can be used. The last resort is the tarball / zip
with the sources so that the package can be rebuilt.

OK, the .zip file IS there -- I don't know how to build .egg ones but of
course I could study up on it -- can you suggest a URL?

To be usable on Windows w/o effort, the packaged format must contain a
..pyd (and, on Mac, a .so, etc). Can a .egg deal w/that?

I need to find out w/certainty, because once I've uploaded a file w/a
certain name I can't change the name, nor the contents -- the URLs on
code.google.com are meant to be permanent...

Probably other people that are more experienced with it can help more. I'm
more an end user of it and I know the essential for my needs.

I just pointed out because setuptools helps a lot on obtaining a package and
installing it (even if there's some building needed before installing).

OK, but since most Windows users don't have a suitable C compiler, and
many Mac ones never bother installing the C compiler that comes with
their OS DVDs, if I'm to make things easy I definitely need to pack up
binaries. How do I pack binaries (for dynamic link libraries) that need
to be very different on Win, Mac, various Linux distros...?

Sorry for not being able to help more.
With regards to the hyperlink, I believe that if the link on Pypi was to the
URL above it would be easier. Another alternative is a link at the first
page. And, of course, the last alternative is teaching setuptools how to work
with code.google.com -- if it doesn't already know -- as it learnt how to work
with SourceForge and its "random" mirrors. I don't know how to write that
code, though.

Me neither, knowing near to nothing about setuptools (I'm not even a
user of it...). Let's hope some expert does speak up -- I can't just
freely experiment with uploads and the like...
Alex

[Mark Dickinson]

On Mar 11, 9:56 pm, [e-mail] (Alex Martelli) wrote:

That bug isn't formally closed yet, and the discussion's going on, we'll
see. Meanwhile can you try my patch 1678668 just to double check it
does fix everything? (It's agains the current HEAD of Python's svn).

It does, and all tests pass. (Still on OS X 10.4.8/PowerPC; I'll
test
it tomorrow on my Linux machine at work.)

Mark

[Paddy]

On Mar 11, 10:49 pm, "Paddy" <paddy3...@goog lemail.comwrote :

On Mar 11, 9:28 pm, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

Dennis Lee Bieber <[e-mail] com.comwrites:

Pardon? What is "the right thing with signed zeros"... In the last
30 years I've been on machines that normalize floating zero into a true
zero (all bits are zero: mantissa, exponent, and sign). This is the
first time I've even seen a variable output as a negative 0.0!

Most machines these days use IEEE 754 which supports negative zero.

http://en.wikipedia.org/wiki/Negative_zero

Isn't negative zero mathematically the same as zero? Isn't -0 just an
artefact of the representation of floating point numbers? Shouldn't
f(0) == f(-0) for all functions f?
I read the wikipedia article about meteorologists using -0 to denote a
negative number rounded to zero for the purposes of binning, i.e. if
you want to tally days with temperature above and below zero, but it
doesn't seem right. You should arrange for any temperature to be in
only one range and record temperatures to their determined accuracy. a
temperature of zero would only be in one bin and if a temperature is
read as -0.2 and th rounding says it should be taken as zero then it
should go in the same bin as any positive reading that is rounded to
zero.
Getting back to Python, shouldn't we strive to remove any distinction?
a zero is a zero regardless of sign and a function like atan returning
one of two different vaues for an argument of zero is actually
mathematically not a bad thing to do?

- Paddy.

A big thanks to Paul and Andre,
I think I have it now. The OP is investigating multivalued functions
where the function converges to different values when approached from
different directions. Floating point arithmetic being a best
compromise solution to the rational number system, distinguishes
between zero and minus zero as an important part of the compromise.
The OP wants to compute a function of zero and minus zero distinctly
and is hampered by Python not preserving the zero/minus zero
distinction in some cases - hence it being a bug.

Swell, Ta!

- Paddy.

Hey, I'm still learnin'. Sweet!

[Jorge Godoy]

al***@mac.com (Alex Martelli) writes:

Hey, I'd just love to make it as easy as possible to get gmpy -- that's
why I (shudder!-) even build and upload Windows installers...

Brave man! :-)

OK, the .zip file IS there -- I don't know how to build .egg ones but of
course I could study up on it -- can you suggest a URL?

The .egg is nice because it can be an already built binary.

http://peak.telecommunity.com/DevCenter/setuptools

The URL above contains examples and instructions on how to use setuptools.

To be usable on Windows w/o effort, the packaged format must contain a
.pyd (and, on Mac, a .so, etc). Can a .egg deal w/that?

Yes. I have a .egg that has a .so here, for rpy (http://rpy.sf.net/).

I need to find out w/certainty, because once I've uploaded a file w/a
certain name I can't change the name, nor the contents -- the URLs on
code.google.com are meant to be permanent...

Hmmm... I'd suggest you to build only locally then... I don't like this kind
of "permanent" things. They could have a flag "publish this" to make it
permanent and make the standard "unpublishe d". Here's a suggestion for you to
forward there inside Google... ;-)

OK, but since most Windows users don't have a suitable C compiler, and
many Mac ones never bother installing the C compiler that comes with
their OS DVDs, if I'm to make things easy I definitely need to pack up
binaries. How do I pack binaries (for dynamic link libraries) that need
to be very different on Win, Mac, various Linux distros...?

One build per platform would be my choice. Packing everything together would
make the package too big (specially if you start supporting other OSs).

Me neither, knowing near to nothing about setuptools (I'm not even a
user of it...). Let's hope some expert does speak up -- I can't just
freely experiment with uploads and the like...

Lets wait. ;-)

Thanks again,
--
Jorge Godoy <jg****@gmail.c om>

[Ben Finney]

al***@mac.com (Alex Martelli) writes:

This is not trivial to fix cleanly...:-(. compiler_add_o would have
to test "is the object I'm storing -0.0" (I don't even know how to
do that in portable C...) and then do some kludge -- e.g. use as the
key into the dict (-0.0, 0) instead of (-0.0, float) for this one
special case.

Another way, which avoids making this decision, is to always store the
sign *and* value of the number as part of the key. I don't know if
that tradeoff is the right one though.

--
\ "Our products just aren't engineered for security." -- Brian |
`\ Valentine, senior vice-president of Microsoft Windows |
_o__) development |
Ben Finney

[Hendrik van Rooyen]

"Paddy" <pa...y3***@goo glemail.comwrot e

>
Hey, I'm still learnin'. Sweet!

contrary to popular belief, the answer to life,
the universe, happiness and everything is
not 42, but the above.

- Hendrik