#11576: make it possible to generate sequences of variables easily
-------------------------------+--------------------------------------------
Reporter: kcrisman | Owner: burcin
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.6
Component: symbolics | Resolution:
Keywords: Cernay2012 | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by nbruin):
Replying to [comment:24 mjo]:
> Oh, right. As Burcin pointed out, there's no leak, it's just creating
symbols and they use up some memory. If you stick to the same symbols,
memory usage won't grow.
Indeed. The issue is that once you can create sequences of symbols
''easily'', people might start doing that more and hence memory footprint
might become more of an issue.
When creating arbitrary symbols, one cannot really avoid adding an entry
in a table somewhere. In principle, weak caching strategies should allow
reclaiming that at some point, but coordination across various interfaces
and libraries (specifically maxima) will make it ''very'' hard to estimate
the lifetime of a symbol properly. Hence, a permanent memory cost for the
creation of a new symbol is so hard to avoid that we should probably
consider it unavoidable.
It would be nice if the permanent cost of a symbol sequence is only for
the sequence, not for every member generated in it. Note that
{{{
for i in [1..10^8]:
print sin(i)
}}}
does ''not'' explode in memory, because the entry `sin` in the symbol
table gets combined with an ''argument'' `i` that varies. No further
permanent entries are made. I bet that `Ginac` does something similar for
its sequences of symbols (i.e., it probably stores a base symbol together
with an index. Essentially a function call, but labelled in such a way
that it gets handles as an atomic, free, entity. Implementation is really
easy in theory: any simplification/rewrite routine should simply ''not''
descend further into the tree)
Ideally, one would have to find a way of encoding such symbols for
`maxima` and `maxima_lib` as well, to avoid the (permanent) translation
tables there to blow up as well. I don't know how easy it is to create
structures capable of storing a serial number AND allowing differentiating
etc. against it. Perhaps just encoding as an (uninterned) symbol might
work. If you encode the string heavily enough you may be able to recognize
them on the way out. For `maxima_lib` you could also store a flag as an
attribute on the symbol and test for that in conversion back to sage
(maxima uses something like this for "dummy" variables somewhere).
However, if you can't figure out how to do this for maxima, at least you
may be able to avoid memory blow-up as long as these symbols don't touch
various interfaces.
I think that if you think this is worth doing, it's worth doing it well. I
think sage has now matured to the point where putting in features via
cheap hacks does more harm than good. (In fact the cheap hacks that were
necessary to get the project up and running originally are now hurting
further development.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11576#comment:25>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
