Andy Ray Terrel wrote:
> * The implicit_functions dict should only rename functions if
> necessary. As it is this makes the code bloated.
It is also used to check if a function is an implicit function. We can split up
the dictionary into a set and a dictionary in this style:
implicit_functions = set([sin, cos, tan, asin, acos, atan, atan2, sinh, cosh,
tanh, sqrt, log, exp, abs, sign])
# The following are also considered to be implicit functions, but with a
# different fortran name:
translate_functions = {conjugate: "conjg"}
> * Can you do piecewise functions the same way as ccode does where you
> have the _print_Piecewise function. Probably could go into
> LowLevelCodePrinter as well.
This is indeed a fly in our soup. The approach in ccode is not workable when
there are non-top-level piecewise functions.
>>> ccode(Piecewise((x, x<1),(1/x,True))**2)
'pow(if (x < 1) {\nx\n}\nelse {\n1.0/x\n},2)'
One can easily see that a 'buried' Piecewise can only be handled by
_print_Piecewise if the target language supports a conditional operator.
Fortran
does not have one, C does but is not used in ccode. Other solutions are not
compatible with the Printer approach: introducing temporary variables, or only
allowing a top-level Piecewise.
If we want to translate buried Piecewise functions, we will have to do this
outside the printer. The above expression should be split in multiple
expressions before it can be fed to a printer:
>>> print fcode(Piecewise((x, x<1),(1/x,True)), assign_to="x1")
if (x < 1) then
x1 = x
else
x1 = 1.0/x
end if
>>> print fcode(x1**2, assign_to="x2")
x2 = x1**2
Any suggestions for a more elegant approach are highly welcome. :) The
splitting
is very similar to common subexpression elimination, which I would like to
include in codegen.py. Therefore, it might be a good idea to treat both
problems
in codegen.py with a generalized cse algorithm.
> * the line wrapping produces bad code (unreadable). There needs to be
> work to take care of cases where operators will be split. For
> example:
>
> In [12]: e = [x**i for i in range(11)]
>
> In [13]: print fcode(Add(*e))
> -------> print(fcode(Add(*e)))
> 1 + x + x**2 + x**3 + x**4 + x**5 + x**6 + x**7 + x**8 + x**9 + x*
> @ *10
Will be fixed. Thanks for the nice example.
> * fcode function should move to something like the following signature
> (expr, *args, **kws) and look up the keywords, it gets too many
> optional keywords as is.
ok
> * Something that might be nice, instead of an exception being thrown
> just have a list of functions that are in the expression but not
> implemented in the core language. That way a code generator can look
> at what needs to be implemented and prompt the user appropriately
> instead of just halting.
That is indeed a better approach. It is a user friendly alternative to the
exceptions. Thanks for the suggestion.
> * One test failed for me:
>
> __________________________ sympy.printing.fcode.fcode
> __________________________
> File "/Users/aterrel/workspace/sympy/sympy/printing/fcode.py", line
> 252, in sympy.printing.fcode.fcode
> Failed example:
> fcode((2*tau)**Rational(7,2))
> Expected:
> ' 8*2**(1.0/2.0)*tau**(7.0/2.0)'
> Got:
> ' 8*sqrt(2)*tau**(7.0/2.0)'
oops.
> The tests and docs look good. We should probably take some time and
> make ccode this good as well.
As soon as fcode is 'in', ccode will be brought to the same level, and both
will
be based on a low-level code printer. I'll first introduce all your
suggestions.
Thanks for reviewing.
cheers,
Toon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sympy" 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/sympy?hl=en
-~----------~----~----~----~------~----~------~--~---
begin:vcard
fn:Toon Verstraelen
n:Verstraelen;Toon
org:Ghent University;Center for Molecular Modeling
adr:;;Proeftuinstraat 86;Ghent;;9000;Belgium
email;internet:[email protected]
title:ir.
tel;work:+32 (0) 9 264 65 56
tel;home:+32 (0) 9 351 56 05
x-mozilla-html:FALSE
url:http://molmod.ugent.be
version:2.1
end:vcard
