Waldek Hebisch <[EMAIL PROTECTED]> writes:
> I wrote:
> >
> > Martin Rubey wrote:
> > >
> > > Waldek Hebisch <[EMAIL PROTECTED]> writes:
> > >
> > > > 301 -- this is due to InputForm lacking package call. Finding out
> > > > where this form is generated requires more work.
I looked at this again. First, to answer Bill's question: "why isn't
UnivariateTaylorSeriesODESolver exposed?" These are really internal
functions. I think as an intermediate measure, exposing makes sense. But
really, we should explicitely package call such things.
Now, where is the package call missing? In EXPRODE we have
opelt := operator("elt"::Symbol)$OP
--opex := operator("exquo"::Symbol)$OP
opex := operator("fixedPointExquo"::Symbol)$OP
opint := operator("integer"::Symbol)$OP
and later
div2exquo : F -> F
div2exquo f ==
-- one?(d := denom f) => f
((d := denom f) = 1) => f
opex(smp2exquo numer f, smp2exquo d)
(by the way, I think we should replace (* = 1) by one?(*) again)
the result of div2exquo is then compiled with compiledFunction$MKF. It relies
on the behaviour of compiledFunction$MKF to interpret "operators".
I don't know how to fix this. Would something like
opelt [opex, "UnivariateTaylorSeriesODESolver"]
work? We somehow need to have a "package call" operator in EXPR INT.
Actually, I think the approach to pass compiledFunction an Expression here is
flawed.
Martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" 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/fricas-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
