Johannes Grabmeier wrote:
>
> another problem with numeric evaluations for computing the normal
> distribution using the error function.
> To my opinion, numeric NV(0.7) directly should return 0.7580363478
>
>
>
> Type:
> Float
> (52) -> NV(x) == (1+erf(x/sqrt(2)))/2
> Compiled code for NV has been cleared.
> 1 old definition(s) deleted for function or rule NV
> Type:
> Void
> (53) -> numeric NV(0.7)
> Compiling function NV with type Float -> Expression(Float)
>
> >> Error detected within library code:
> Can only compute the numerical value of a constant, real-valued
> Expression
First I agree this is a problem which should be fixed. However,
there is a design problem. Compare:
(1) -> sx := sin(x)::Expression(Float)
(1) sin(x)
Type: Expression(Float)
(2) -> opsin := operator(kernels(sx).1)
(2) sin
Type: BasicOperator
(3) -> opsin(0.7)
(3) 0.6442176872_3769105367
Type: Expression(Float)
(4) -> ex := erf(x)::Expression(Float)
(4) erf(x)
Type: Expression(Float)
(5) -> operf := operator(kernels(ex).1)
(5) erf
Type: BasicOperator
(6) -> operf(0.7)
(6) erf(0.7)
Type: Expression(Float)
The difference is that elementary functions applied to floating
point arguments immediately evaluate their arguments, while
'erf' remains in symbolic form. Current 'numeric' depends on
this. More precisely, merely converting an expression to
'Expression(Float)' causes numerical evaluation. This behaviour
is debatable. First, it limits possibility for purely
symbolic computation. If it were limited to 'Expression(Float)',
then it would not too bad. But this is done genericaly,
for 'Expression(R)' whenever there is 'sin' in 'R'. IME several
bugs in Axiom were due to fact that algorithm like Gruntz
algorithm or Risch algorithm need very precise control on
form of expressions and automatic evaluation can change
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. Second, there is actually
quite a lot of code implementing this automatic evaluation:
each function has its own code. While this kind of
boilerplate code it potential for bugs.
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 apropriate evaluation
function. Then numeric could be implemented as a tree
walker over expressions, in the style of 'eval'.
--
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.
