On Jun 25, 8:33 am, Toon Verstraelen <[email protected]>
wrote:
> Hi,
>
> I realized that it was probably not a good idea to ask the questions
> below in the issue tracker. Sorry for cross-posting.
> (http://code.google.com/p/sympy/issues/detail?id=1487)
>
> I have some questions/ideas about extending ccode (or fcode for
> Fortran). Any comments would be helpful to get some direction.
>
> * Should an exception be raised when ccode encounters a function that is
> not supported in standard C? We can introduce an optional argument,
> user_functions={}, for ccode. This dict contains function-name pairs for
> functions that are not part of standard C.
>
> A few examples:
>
> In [15]: ccode(integrate(sin(x)/x,x))
> Out[15]: Integral(sin(x)/x, x)
>
> This should always raise an exception. Such a thing is never ever going
> to be compilable.
We could use a library (maybe sepcified by the user) that can evaluate
Integrals numerically.
>
> In [22]: ccode(gamma(x))
> Out[22]: gamma(x)
>
> This should also raise an error since the gamma function is not part of
> the C standard. We can provide a way around the issue:
>
> In [23]: ccode(gamma(x), user_functions={gamma: 'gsl_sf_gamma'})
> Out[23]: gsl_sf_gamma(x)
>
> Is this acceptable? We can provide default dictionaries for a few
> popular libraries. (gsl, gnu's math.h, ...)
This would be nice to have.
>
> * What to do with sympy constants that are not part of the language? A
> typical example in Fortran is the constant pi. In a normal program, it
> has to be defined by the programmer in this style:
>
> REAL (KIND=dp), PARAMETER :: pi = 3.14159265358979323846264338_dp
>
> We can replace the constants by their numerical value in the printer,
> but this is a bit messy. How are we going to determine the precision to
> be used? We can probably think of more fancy solutions at the codegen
> level, but the printer on itself should also give an acceptable result.
I think ccode() could just .evalf(15) any sympy expression (assuming
'double' precision).
>
> * ccode has an implementation for Piecewise functions that does not
> return a single expression, but multiple statements. This is not
> compatible with the assumptions made by the codegen. We can replace this
> by a conditional operator.
> (http://en.wikipedia.org/wiki/Conditional_operator)
So this seems to be easy to solve.
Thanks,
Vinzent
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
