On Thu, Feb 18, 2021 at 04:11:04PM -0800, Tobias Neumann wrote:
> > That is consequence of IEEE rules about signed zero and precedence rules:
>
> Now that is a subtle and interesting phenomenon.
>
> >From that point of view everything is consistent indeed. But in practice
> I think that one easily runs into this issue. I would argue that you want
> to be
> able to swap Float and DoubleFloat in applications, and this prevents it
> without
> writing a wrapper for the exponentiation that always enforces a positive
> sign for a zero imaginary part.
> Also virtually every CAS out there gives you +%i for (-1.0)^(0.5) for
> floating point numbers.
Well, DoubleFloat is hardware float and modern hardware follows IEEE
rules. And there is vocal group insiting that library functions
should follow IEEE rules, even if done in software. Practicaly,
FriCAS uses Lisp complex 'log' and it gives us IEEE behaviour.
I am not sure how big problem this is for you: if imaginary
part comes from computations, then you have bigger problem.
If imaginary part is constant, then 'complex(x, 0)' gives
you positve sign for imaginary part, so there is easy
workaround. If you are really determined you can create
a wrapper domain inheriting most from Complex(DoubleFloat),
but overriding a few funcions that you do not like. However,
I do not think that turning Complex(DoubleFloat) into such
wrapper domain is good idea: I can not satisfy everyone.
And adding a wrapper is more flexible than fighting with
unwanted wrapper.
Concerning case when exponent is from Fraction(Integer):
this is generic code. We may add a special case for
DoubleFloat so that it behaves like DoubleFloat exponent.
OTOH different domains show different behaviour: purely
symbolic domains are subtly different in their handling
of branches compared to numeric domains. So users who
care about branches must be careful.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20210219021657.GB12316%40math.uni.wroc.pl.