Bill Page wrote:
>
> What specifically implements the numeric evaluation in the example of
>
> NV(x:Float):Float == ... erf(...) ?
One anwer is: interpreter via typechecking. Anpother is that
numeric 'erf' is implemented in FloatLiouvilianFunctions.
More precisely, Johannes asks for connection between symbolic
function and the numeric one. Of course a precondtion to
this is existence of both numeric and symbolic version.
Once both are available at the command line typechecker will
resolve overloading and choose one of them. If you really
need 'numeric' ust now you could do:
However, we
do not want to implement 'numeric' via trip to interpreter
(after all we already have everything type-correct and
do not want to guess types). OK if you really need 'numeric'
just now you could do:
my_numeric(ie : Expression(Integer)) : Float ==
fe := ie::Expression(Float)
fval := interpret(fe::InputForm)$InputFormFunctions1(Float)
(12) -> nv := erf(7/10)
7
(12) erf(--)
10
Type: Expression(Integer)
(13) -> my_numeric(nv)
Compiling function my_numeric with type Expression(Integer) -> Float
(13) 0.6778011938_3741847297
Type: Float
However, I am noy sure if we want to implement 'numeric' via
trip to interpreter. After all we already have everything
type-correct and do not want to guess types.
> On 2015-10-22 6:26 PM, "Waldek Hebisch" <[email protected]> wrote:
> >
> > expressions in undesirable way. So I would like to limit
> > automatic evaluation only to few cases when it is clear
> > that it will cause no problems.
>
> Do you mean all automatic evaluations, only those involving retractions to
> the coefficient domain, or only those that result in "numeric
> approximations"?
All automatic evaluation.
> > OK, above I gave reasons while I am not eager to follow Axiom
> > there. So what I intend to do? My current plan is to add
> > new property to operators, giving appropriate evaluation
> > function. Then numeric could be implemented as a tree
> > walker over expressions, in the style of 'eval'.
> >
>
> Should there be one evaluation function for each possible numeric domain or
> something more generic? Evaluation functions for many operators already
> exist. Either way this sounds awkward to me.
I mean 'Complex(Float)' as numeric doman. We would get 'Float'
via retraction. IIRC no other numeric domian is supported
by 'numeric'.
> It seems to make fairly good sense to me that one should avoid coefficient
> domains for Expression that export functions that implement otherwise
> symbolic operators if one does not want such automatic simplifications.
> This is the essential difference between Expression Float and Expression
> Integer.
Interpreter forbids 'Expression(Expression(Integer))' but it actually
makes sense and is used in integrator. Generic evaluation would
push things into lower 'Expression' potentially destroying
structure. Currently the only use is when lower 'Expression'
represents constants and applying function to a constant still
gives a constant so there are no problem. But with more use
we could hit a problem. We already have problems because of
automatic simplification of roots.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
