#17808: Preparse integers as strings
-------------------------------------+-------------------------------------
Reporter: jdemeyer | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.6
Component: misc | Resolution:
Keywords: | Merged in:
Authors: Jeroen Demeyer | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jdemeyer/ticket/17808 | 533af4ce9ae65f71d38177052fccb28cc69234e7
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:6 jdemeyer]:
> Replying to [comment:5 nbruin]:
> > The whole idea of preparsing `100` as `Integer(100)` is that in the
AST and the generated byte code, the constant `100` is already stored as a
numerical one
> Is that really important? The "timeit" example is of course a bit
artificial.
I think so. Storing the numerical constant as a string forces the decimal-
to-binary conversion to happen at runtime. If you just write it as a
python integer, the conversion happens at parsing, so by the time it's an
ast and the compiler looks at it, you're already dealing with an integer.
Unfortunately, python doesn't permit compile-time macros (perhaps if we're
ever going to rewrite our preparser to properly parse, we can combine it
with [https://pypi.python.org/pypi/MacroPy MacroPy] and then we can have
`Integer` object creation at compile time)
I am fairly certain that nearly all code that gets run with sage has TONS
of small integer literals in it. Probably for many applications, people
would get better performance writing `100r`, but of course nobody will.
This ticket would deteriorate the much more common situation in favour of
a small gain in the extremely rare situation that someone wants to include
an incredibly large integer literal in their code (talk about artificial--
I don't think having a (small) numerical literal in an inner loop is
artificial at all!). And the extremely rare situation can be solved by
writing quotes already (and by the time you're writing such a long string
you might as well convert it to hex anyway, in which case Python and GMP
are (at least asymptotically) comparable.
If you use `preparse_file` instead of `preparse`, you'll see that
numerical constants get pushed outside (which has its own set of problems,
see #11542), which mitigates the string-conversion-in-inner-loop.
--
Ticket URL: <http://trac.sagemath.org/ticket/17808#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
