oldk1331 wrote:
>
> (1) -> acosh(0.3::Complex Float)
>
> (1) 0.67762635780344027125E-20 + 1.2661036727794991113 %i
> Type: Complex(Float)
>
> The real part should be 0. My question is, this error, which is
> 2*2^-68 (68 is bits()$Float), is it too big? (It should be 2^-68,
> I think.)
First, _relative_ error is more important. In this case relative
error is 1.58*2^-68 so is somwhat big.
>
> The definition of acosh of Complex Float is in trigcat.spad:
> acosh x == 2*log(sqrt((x+1)/2::%) + sqrt((x-1)/2::%))
>
> The "2" double the error. I'm still looking at various parts,
> especially sqrt$Float. I want to know your opinion.
Actually, the '2*' factor does not affect relative error. If
we insist on error being smaller than prescribed bound we need
to have some extra margin of precision. Like:
acosh x ==
obits := bits()
res : Complex(Float)
try
bits(obits + 10)
res := 2*log(sqrt((x+1)/2::%) + sqrt((x-1)/2::%))
finally
bits(obits)
res
The 'try' and 'finally' part is needed to reliably restore
precision. As you can see the routine no longer is generic:
we need to specify type of 'res'. 10 bits may be too much,
but at least 3 extra bits are need to compensate possible
accumulation of error.
I admit that I would prefer _not_ to use such code for every
floating point routine. I think we should rather accept fact
that error is sometimes slightly higher than what one would
naively expect form 'bit()' setting.
--
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.
