Comment #6 on issue 1487 by Toon.Verstraelen: fcode: print sympy expressions as Fortran code http://code.google.com/p/sympy/issues/detail?id=1487
It surely helps. For a single person, it is hard see all the different ways people want to use ccode and fcode. All comments are welcome. Most of the choices above are based on my codegen perspective (see: http://code.google.com/p/sympy/issues/detail?id=1463) The purpose of codegen is to generate compilable source code, or to raise an exception. fcode and ccode are used to write the individual lines. Manually changing the generated source afterwards is more or less a taboo. It is not feasible either when codegen spawns 10K lines of source code. I have to broaden my view on ccode and fccode. My original idea was that they should just print a single expression, but this has a few limitations since fortran is a real statement-oriented languages (http://books.google.com/books?id=TDEUert0ZgUC&pg=PA79&lpg=PA79&dq=conditional-operator+fortran&source=bl&ots=dfyyEC8r4M&sig=a9mZ8GWV9a0k5-9sn0T7mYkiMxM&hl=en&ei=nr5FSpDFHZq1sgaKkskZ&sa=X&oi=book_result&ct=result&resnum=2) * If we want to get splitting over multiple lines right, it would be nice to know what is in front of the expression. Something in this sense: In [5]: fcode(x*y, assignto="somevar") Out[5]: somevar = x*y * There is no conditional operator in Fortran, so there we have to use if-then-else-endif for piecewise functions. When the PieceWise function is top-level, i.e. not buried somewhere inside an expression, the assignto argument is sufficient to generate correct code. For example: In [6]: fcode(Piecewise((x,x<1),(x**2,True)), assignto="foo") Out[6]: if (x < 1) then foo = x else foo = x**2 end if However, when Piewise is not top-level, temporary variables have to be introduced to get valid code. Valid code is important, otherwise fcode is useless from the codegen perspective. fcode should then (optionally) return the names and assumptions of the tmp vars, e.g. is_integer, so that codegen can declare these temporary variables properly. All fine, but this is really going beyond 'just printing'. Is this OK? Should fcode for the copy-paste users just return a plain single string in all cases? For the codegen, I would prefer a nice data structure indicating all the 'side-effects' such as temporary variables. * Is the DATA statement in some sense preferable over the PARAMETER statement? I'm not a Fortran guru. What is the specific advantage? * The exception-raising-thing is indeed a can of worms, on purpose. :-) Again, the codegen and copy-paste paths are diverging here. I believe that the user_functions argument can fix most of the realistic problems, but some people will just prefer fixing things afterwards. Both should be possible. However, is it really necessary to generate Fortran code that has RootsOf, NegativeInfinity, ...? Fortran and C aren't symbolic languages, so it is normal that not every sympy object has a Fortran/C counterpart. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sympy-issues" group. To post to this group, send email to sympy-issues@googlegroups.com To unsubscribe from this group, send email to sympy-issues+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sympy-issues?hl=en -~----------~----~----~----~------~----~------~--~---