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 easil
That was the point I was trying to make: whether you use ^: ( %,
Fraction(Integer)) -> %
or ^: (%, %) -> % should at least be consistent within numerical precision
for Complex(DoubleFloat).
And I expect consistency betwen Float and DoubleFloat, so that one can swap
them and get the same
results
Not at all ;) It shows once more that DF ought to have no place in a CAS. DF is
a source of confusion on its own. I'd use Interval(Float) or Float, if need be
...
BTW 0.5 and 1/2 have different types. The interpreter is sometimes too
broadminded.
On 19.02.2021 01:17, Tobias Neumann wrote:
> May
Maybe this is most convincing:
(3) -> ((-1) :: Complex(DoubleFloat))^(0.5)
(3) 6.123233995736766e-17 - %i
Type:
Complex(DoubleFloat)
(4) -> ((-1) :: Complex(DoubleFloat))^(1/2)
(4) %i
T
> 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 Floa
On Thu, Feb 18, 2021 at 01:55:13PM -0800, Tobias Neumann wrote:
> Thank you. As it turns out, complex exponentiation (^ : % -> %) with a
> Complex(DoubleFloat) exponent is also broken:
>
> Good:
> (7) -> (-1.0 :: Complex(Float))^(0.5)
>
>(7) 0.2022266248_7959507324 E -20 + %i
>
> presumably you didn't notice the different sign for the imaginary part?
Oh, no no. I did see that. Why would that be a problem?
Yes, I agree, from the name Float and DoubleFloat one might think that
these two domains are somehow related. But when you consider them as
separate domains both resul
Hi Ralf,
presumably you didn't notice the different sign for the imaginary part?
It's just the same issue that was present for the fractional integer
exponent.
I think that this should be handled consistently so that the cut is along
the negative real axis,
i.e. sqrt(-x + %i*0) -> %i*sqrt(x)
Be
Being a bit nasty... ;-)
Why do you say it is broken?
Modulo an error bound of 10^(-15) it looks OK.
Do you expect exact values when you compute with floating point numbers?
Ralf
(7) -> a := (-1.0 :: Complex(Float))^(0.5)
(7) 0.2022266248_7959507324 E -20 + %i
Thank you. As it turns out, complex exponentiation (^ : % -> %) with a
Complex(DoubleFloat) exponent is also broken:
Good:
(7) -> (-1.0 :: Complex(Float))^(0.5)
(7) 0.2022266248_7959507324 E -20 + %i
Type:
Complex(Float)
Broken:
(6)
On Wed, Feb 17, 2021 at 10:26:55AM -0800, Tobias Neumann wrote:
> There seems to be a bug in Complex with domains Float or DoubleFloat:
>
> Working:
> (68) -> (-1 :: Complex(MachineFloat))^(3/2)
>
>(68) - %i
> Type:
> Expression(Complex(MachineFloat))
>
There seems to be a bug in Complex with domains Float or DoubleFloat:
Working:
(68) -> (-1 :: Complex(MachineFloat))^(3/2)
(68) - %i
Type:
Expression(Complex(MachineFloat))
But for Float it's not working as expected:
(65) -> (-1 :: Complex(Float))^(3/2)
12 matches
Mail list logo
