>
> (1) -> precision()
>
> (1) 68
> Type: PositiveInteg=
> er
> (2) -> precision(300)
>
> (2) 68
> Type: PositiveInteg=
> er
> (3) -> a :=3D sqrt(2.0);
>
> Type: Flo=
> at
> (4) -> precision(68) =20
>
> (4) 300
> Type: PositiveInteg=
> er
> (5) -> a
>
> (5)
> 1.4142135623_7309504880_1688724209_6980785696_7187537694_8073176679_73799=
> 0732
> 4_7846210703_885038753
> Type: Flo=
> at
>
> Is that really what one wants: I am implementing an algorithm, where I swit=
> ch internally to a higher precision to guarantee the result being correct i=
> n the working precision.=20
> So right now FriCAS is cheating - at least for such an algorithm
<snip>
> I think it would be a good rule to make output precision to working precisi=
> on, if a user wants to change this he has to explicitly change precision
AFAICS currently Float domain allows to use of numbers with different
precision. The precision setting only affect _new_ numbers, old
ones created with different precision are kept intact. And numbers
are printed with full available precision.
You argue that we should print numbers with current precision if it
is lower than precision of given number. This has some advantages.
However printing numbers with lower precision means that output
can be nice buit misleading, different numbers may print exactly
the same and this can be source of debugging troubles. My feeling
is that quick printouts should be mostly used for debugging and
then accuracy is essential. OTOH people who want nice output
can use for example 'outputGeneral' to limit number of needed
digits.
BTW: You can also use 'normalize' after lowering precision.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
