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
-~----------~----~----~----~------~----~------~--~---

Reply via email to