--
Janus
Den 15/07/2008 kl. 12.16 skrev Martin Geisler:
Janus Dam Nielsen <[EMAIL PROTECTED]> writes:
Den 11/07/2008 kl. 22.02 skrev Martin Geisler:
Right, good point! We should do that. Maybe a smart compiler could
do the necessary deductions automatically? [...]
I am not aware of any of-the-shelf technique for this, but it would
be a fun problem to solve.
Define a cost function:
Gamma(+) = 5
Gamma(-) = 5
Gamma(*) = 10
I have no clue if these costs reflect the relative cost among the
operators, please correct me.
I have never really measured the speed of additions/subtractions, but
my guess is that they are a 100 or maybe a 1000 times faster than
multiplications.
And comparisons are about 500 times slower than multiplications.
Given the size of an expressions that naturally appear in programs I
think it is reasonable efficient to compute all permutations of the
expression under the distributive law and then pick any one of those
with the lowest cost under the Gamma cost function.
This is worstcase exponential, but given the size of expressions
programmers are inclined to write in a program, then I don't think
it will be a problem.
For single expression I guess not, but it should also work for chains
of expressions (when possible):
x = a * b
y = a * c
z = x + y
If x and y are not used, then z can be computed as a * (b + c). Was
that already part of what you planned?
Yes I have been thinking about this as well, but I currently this as
an extension we can pursue when we know how to deal with a single
expression.
Even in such cases as above I guess that the size of expressions will
be reasonable small. Lets see when we get some tests.
[...]
If you are working in a language where you can redefine the
semantics of operators like * in Python you have to take that into
account as well, but it does not need to change the analysis
performed by the interpreter.
Right, but I don't think we will want to give people that power?
No, you mentioned manipulating the Python AST and so I just wanted to
let you know that this can also be done in Python.
Depending on how much the SMCL compiler can do, it would be stupid
to throw it away. But on the other hand we might be able to
reimplement things quickly in Python from which we can work
directly with the Python AST. I guess we need more comments from
the Janus and Michael.
You should see my progress report to see what the SMCL language and
compiler can do for you.
I've printed the report and I hope I will have read it soon!
Nice, at least one more gets read my report :)
Have you ever put up the source (and repository) somewhere? The
nightly build linked from
http://www.daimi.au.dk/~fagidiot/simap/
seems broken (as does many of the links on the blog...).
They haven't been maintained for a year now...
I have an svn repository at daimi
/users/fagidiot/.SVNSMCL
I believe you can read from there.
--
Martin Geisler
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
_______________________________________________
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
