Am 20.03.2012 18:35, schrieb Andy Ray Terrel:
Well I was thinking more of taking a piece of c code, but it could be
take a python function, grab the code object and manipulate that.
What I really want is to play around with symbolic code optimizations
and since we have quite a few tools to go from symbolics to code, it
seems easy to do simple things in the other directions.
Real (non-toy) code contains extra stuff for handling error conditions,
optimizing memory usage, etc.
Extracting the real logic from all that sounds like it would be really,
really hard.
The other question is: what do you want to optimize for?
Space? Time? Code size?
What's your execution model - number of subroutine calls? Number of
operator calls? How do you estimate the number of rounds spent in a loop
(or the depth of a recursive call)? How do you estimate the size of data
structures created? How do you determine how long some data structure
will live?
Not all of the questions are relevant for all optimization goals.
This is going to be a good GSoC project if a goal is found that does not
require answers to the ultra-hard questions. So the project should not
be "optimize C functions" (that's a task for multiple lifetimes), but
something more specific. With an implementation strategy, and an eye
towards why this isn't going to require solving the halting problem or
similarly hard things.
> I realize
this isn't super well formed but after seeing a number of these
symbolic executor papers, I think it is probably a good way to go.
I haven't seen these papers. If they pick specific things that don't
require doing hard stuff, this could be fun.
Extra points if it is going to make SymPy more useful.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
