You might be on the wrong track ...
x:Float:=%pi
does merely mean an approximation to %pi depending on precision. Note that
"Float" implements arbitrary precision floating point arithmetic. Since you
cannot represent "pi" exactly, it's up to you how exact it shall be.
digits(1000)
pi1000:=pi()$Float
digits(20)
pi1000-x
pi1000-pi1000
It works perfectly ;) Of course, you must know what you are doing in a
calculation.
If you like more precision then use interval arithmetics:
(7) -> pi()$Interval(Float)
(7) [3.1415926535_897932384, 3.1415926535_897932385]
Type: Interval(Float)
Also see
http://fricas.github.io/api/Float.html?highlight=float
On 04.06.2018 21:34, Riccardo GUIDA wrote:
> Hi, take these as mild suggestions...
>
> 1)
> I feel like if the current system of Float numbers as it is is quite
> user-unsafe
> (!) because it allows operations f(x,y) combining FloatS x,y with different
> number of digits resulting in the *highest* one (ie something like coerce a
> Float to higher precision). This is a convention that gives false sense of
> security to a user that plays with the global variable digits().
>
> Example:
>
> (1) -> x:Float:=%pi
>
> (1) 3.1415926535_897932385
> Type: Float
> -- all digits after 20-th will be set below to (?) zero but this is an
> arbitrary
> convention
> -- so they are "rubbish". Analog statement if the implementation is binary.
>
> (2) -> digits(50)
>
> (2) 20
> Type: PositiveInteger
> (3) -> x
>
> (3) 3.1415926535_897932385
> Type: Float
> (4) -> y:Float:=%pi
>
> (4) 3.1415926535_8979323846_2643383279_5028841971_693993751
> Type: Float
> (5) -> (y-x)/y
>
> (5) 0.1287414678_9751207735_7225992816_9904172693_1308680622 E -20
> Type: Float
> --- the 50 digits shown above are "rubbish", just convention dependent
>
>
> So my point is that ideally one should have domains no coercitions to higher
> precisions, maybe to lower ones, or user conversions. Say, domains
> Float(d:PositiveIntegers). I'm willingly not distinguishing here among
> absolute
> or relative precision, the problem being more general.
>
> Of course in the present state if a user does not mix precisions (the best
> choice which should be recommended) or knows that the error is influenced by
> the
> lowest precision number (s)he entered, everything will be fine.
>
>
> 2)
> Given that the precision of a Float x at runtime depends on its history and
> may
> be unrelated to the current value of digits(), it would be useful to have
> functions digits, precision of signature Float -> PositiveIntegers that
> estimate
> the corresponding quantities for a given x.
>
> Best
> ric
>
--
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.
