oldk1331 wrote:
>
> > However, this is wrong more or less the in the same way as
> > the x^(1/3) test that you try to make to work. So the change
> > does not look as improvement: we make one borderline case
> > work at expense of another borderline case...
>
> I don't think it fails in the same way as x^(1/3).
> S3 is a complex expression, although its value is always real,
> when computing in float number, there's a small imaginary
> part. The right thing to do is to give "draw" a real expression,
> such as "real(S3)", but there's no "real" for EXPR FLOAT
> (is that a bug?), convert it to EXPR FRAC INT first works:
>
> draw(real(S3::EXPR FRAC INT),t=0..100)
My point is that code tries to stretch definitions: S3 contains
square roots of negatve numbers which evaluated as complex
expressions give real result. This is not valid for _real_
functions but users seem to expect this (and complain if this
does not work). This is similar to your example, where
x^y is in general not defined for negative numbers, but
for 'y = 1/3' one can produce a value. Problem is that
those expectations are inconsistent. In principle we
could have bunch of switches so that users can choose
one of alternatives. But this fits badly with FriCAS
architecture. OK, for 'draw' adding switches probably
just would be work. But in other places switches
would be much worse.
--
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 https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
