Signed zeros: is this a bug?
aleax at mac.com
Mon Mar 12 02:17:48 CET 2007
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
> /* 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
> 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?)
to browse the current version on the trunk. Right under the Python
toplevel subdirectory in the sources, IOW.
More information about the Python-list