Yeah piecewise functions are still only about 50% implemented. I wanted to make a piecewise_fold function that could be called to fold any outer arguments into the piecewise exprs, but got stuck a while back on the assumption system. Perhaps I should get that working again.
http://github.com/aterrel/sympy/commits/piecewise and issue 353 As far as the intermediate rep for other languages, I think just using the arg tree already given by the symbols is best. I've created an issue for the LowLevelCodePrinter (issue 1514) -- Andy On Fri, Jul 3, 2009 at 2:45 AM, Toon Verstraelen<toon.verstrae...@ugent.be> wrote: > 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 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 -~----------~----~----~----~------~----~------~--~---
