Signed zeros: is this a bug?

[Alex Martelli]

Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:

> En Sun, 11 Mar 2007 15:26:01 -0300, Alex Martelli <aleax at mac.com> escribió:
> 
> > Or maybe we should give up ever storing -0.0 in the tables
> > of constant and ALWAYS have "0.0, unary-minus" wherever it appears (that
> > would presumably require working on the AST-to-bytecode visitors that
> > currently work ever-so-slightly-differently for this specific
> > troublespot in the C-coded version vs the Python-coded one...).
> 
> I think that way is the less intrusive, doesn't rely on a particular FP
> implementation, and the more likely to be accepted.
> Looking at ast.c, the culprit is some optimization in ast_for_factor, line
> 1506
>      /* If the unary - operator is applied to a constant, don't generate
>         a UNARY_NEGATIVE opcode.  Just store the approriate value as a
>         constant.  The peephole optimizer already does something like
>         this but it doesn't handle the case where the constant is
>         (sys.maxint - 1).  In that case, we want a PyIntObject, not a
>         PyLongObject.
>      */
> 
> After the long "if", I would use parsenumber(STR(pnum)) and check the type
> and value of the resulting object; if it's a float and 0.0, skip the
> optimization and continue below as a normal case.
> Unfortunately I'm not able to compile and test the code right now, so I
> can't provide an actual patch. (At least, not until tuesday). But I hope
> this simple comment is useful anyway...

Yep, it sure might, if I can make time to act on it:-).


> (I cannot find peephole.c on the source distribution for Python 2.5, but
> you menctioned it on a previous message, and the comment above refers to
> the peephole optimizer... where is it?)

http://svn.python.org/view/python/trunk/Python/peephole.c?rev=54086&view
=auto

to browse the current version on the trunk.  Right under the Python
toplevel subdirectory in the sources, IOW.


Alex