Gabriel Genellina <[EMAIL PROTECTED]> wrote: > En Sun, 11 Mar 2007 15:26:01 -0300, Alex Martelli <[EMAIL PROTECTED]> > 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 -- http://mail.python.org/mailman/listinfo/python-list
