toString(3.7, digits()$Float)

[Grégory Vanuxem]

=>
(1) "4.30000000000000000000"

I wanted to use it, but apparently not now ;)

- Greg

[Grégory Vanuxem]

Maybe using 'floor' instead or 'round' line 164 of sf.spad?

[Waldek Hebisch]

Hmm, what do you want?

(17) -> toString(4.3)

(17) "4.3"
Type: String

(18) -> toString(4.3, 20)

(18) "4.30000000000000000001"
Type: String

Do you want 20 digits (or whatever you specified) or not?

--
Waldek Hebisch

[Grégory Vanuxem]

No. toString(3.7,20)

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZqURL1sqf06As1_Y%40fricas.org.

[Waldek Hebisch]

On Sat, Jul 27, 2024 at 05:25:52PM +0200, Grégory Vanuxem wrote:
> No. toString(3.7,20)

I see. Yes we need 'floor' but also a special case for negative
numbers. And there are nasty bordeline cases, for example when
number is smaller than the next integer but the difference is
smaller than resolution of the convertion. Arguably in such
case we should round up.

To say the truth we probably do not want separate implementation
of 'toString', issues are exactly the same as in printing code
and solution is likely to be the same.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZjJO%2BaUm4G4OnChy_gLmsA-fwipoBUpzarcYhBLJPAmA%40mail.gmail.com.

--
Waldek Hebisch

[Ralf Hemmecke]

On 7/27/24 19:23, Waldek Hebisch wrote:
> On Sat, Jul 27, 2024 at 05:25:52PM +0200, Grégory Vanuxem wrote:
>> No. toString(3.7,20)
>
> I see. Yes we need 'floor' but also a special case for negative
> numbers.

Isn't "truncate" what you are looking for?

> To say the truth we probably do not want separate implementation
> of 'toString', issues are exactly the same as in printing code
> and solution is likely to be the same.

Well, unfortunately, I haven't collected these cases, but there must be
bugs also in the printing of floats. I faintly remember that I set the
output to a fixed number of digits and it would often come out with
these number of digits, but for some numbers also less digits were
printed. I'll try to collect them next time.

Ralf

[Grégory Vanuxem]

Le sam. 27 juil. 2024 à 19:58, Ralf Hemmecke <hemm...@gmail.com> a écrit :
>
> On 7/27/24 19:23, Waldek Hebisch wrote:
> > On Sat, Jul 27, 2024 at 05:25:52PM +0200, Grégory Vanuxem wrote:
> >> No. toString(3.7,20)
> >
> > I see. Yes we need 'floor' but also a special case for negative
> > numbers.
>
> Isn't "truncate" what you are looking for?

Clearly yes! Thanks.

Greg

[Ralf Hemmecke]

> And there are nasty bordeline cases, for example when number is
> smaller than the next integer but the difference is smaller than
> resolution of the convertion. Arguably in such case we should round
> up.

Isn't that easy to solve by adding (or subtracting if the number is
negative) half of the precision (i.e. basically rounding the part after
the dot)?

In fact, "round" is probably correct, but it should be
round(10^n*x)/10^n and then do the splitting.

Ral

[Waldek Hebisch]

Well, that would work in exact artithmetic. But the code tries to
work in floating point and this is source of nasty troubles. Also
"normal" rounding mode for pinthing purpoose should be "round to nearest,
even", which is more complicated than simple 'round'.

--
Waldek Hebisch

[Grégory Vanuxem]

Hello,

Would you like I fill a GH issue for the remainder? With eventualIy a link to this discussion ? it would not be a problem.

Greg

--
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 fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZqYg-wZwDpwrywkM%40fricas.org.

[Grégory Vanuxem]

https://github.com/fricas/fricas/issues/179

[Waldek Hebisch]

On Sat, Jul 27, 2024 at 05:25:52PM +0200, Grégory Vanuxem wrote:

> No. toString(3.7,20)
>
> Le sam. 27 juil. 2024 à 17:24, Waldek Hebisch <de...@fricas.org> a écrit :
> >
> > On Sat, Jul 27, 2024 at 03:31:57PM +0200, Grégory Vanuxem wrote:
> > > =>
> > > (1) "4.30000000000000000000"
> > >
> > > I wanted to use it, but apparently not now ;)

AFAICS the attached patch fixes the problem for Float. To handle
DoubleFloat we probably should move floating point formatting to
a separate package and use approptiate routine from this package
also for DoubleFloat. In fact, I would prefer to do _all_
DoubleFloat formatting via such a package (so get rid of Lisp
formatting).

--
Waldek Hebisch

[Grégory Vanuxem]

+1

And even the « documentation » is wrong (an old mail - the no formatted example is already formatted).

I will test it, thanks

--
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 fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZrAnAxhlBl_NEtZd%40fricas.org.

[Grégory Vanuxem]

Le lun. 5 août 2024 à 03:31, Grégory Vanuxem <g.va...@gmail.com> a écrit :

+1

And even the « documentation » is wrong (an old mail - the no formatted example is already formatted).

I mean: about DoubleFloat

[Grégory Vanuxem]

Hello,

Downloaded with Microsoft Edge (on Windows):
┌──(greg㉿ellipse)-[~/Git/jlfricas/src/algebra]
└─$ cat /mnt/c/Users/gregv/Downloads/FLOAT.diff |patch
(Stripping trailing CRs from patch; use --binary to disable.)
patching file FLOAT.spad

I guessed it has to be applied on the extracted FLOAT.spad file during
the build. It works fine thanks but is this expected:

Before and after

(1) -> toString(3.7,30)

(1) "3.700000000000000000002684354560"

Type: String

Time: 0.04 (OT) = 0.06 sec
(2) -> )lib FLOAT
Float is now explicitly exposed in frame frame1
Float will be automatically loaded when needed from
/home/greg/Git/jlfricas/FLOAT.NRLIB/FLOAT
(2) -> toString(3.7,30)

(2) "3.700000000000000000002710505431"

Type: String

Using 30 is of course not judicious since by default digits() = 20, I
wonder what can be returned with this argument.

- Greg

> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZrAnAxhlBl_NEtZd%40fricas.org.

[Hill Strong]

If I recall correctly, in Float, 3.7 should irrespective of the number of digits specified have only 0 as the following digits after 3.7.

DoubleFloat would be expected to have a rounding error in the last couple of digits.

Is this an indication that something else untoward is happening?

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2daL1pN4aRP%2BVQtG4TGo_7g8KRnh%3DRMu9%3D3Cw_gQtO7T%3Dw%40mail.gmail.com.

[Waldek Hebisch]

On Wed, Aug 07, 2024 at 04:14:45AM +0200, Grégory Vanuxem wrote:
>
> I guessed it has to be applied on the extracted FLOAT.spad file during
> the build.

Alternatively you can just apply it to float.spad and do

)compile float.spad

> It works fine thanks but is this expected:
>
> Before and after
>
> (1) -> toString(3.7,30)
>
> (1) "3.700000000000000000002684354560"
>
> Type: String
>
> Time: 0.04 (OT) = 0.06 sec
> (2) -> )lib FLOAT
> Float is now explicitly exposed in frame frame1
> Float will be automatically loaded when needed from
> /home/greg/Git/jlfricas/FLOAT.NRLIB/FLOAT
> (2) -> toString(3.7,30)
>
> (2) "3.700000000000000000002710505431"
>
> Type: String

AFAICS 3.700000000000000000002710505431 is correct. The other
result is due to rounding error:

(65) -> digits()

(65) 20
Type: PositiveInteger
(66) -> a := 3.7

(66) 3.7
Type: Float
(67) -> digits(30)

(67) 20
Type: PositiveInteger
(68) -> a - 3.700000000000000000002710505431

(68) 0.0
Type: Float
(69) -> a - 3.700000000000000000002684354560

(69) 0.261509 E -22
Type: Float

Code in FLOAT.spad in not perfect but is _much_ better than old
implementation of 'toString'.

--
Waldek Hebisch

[Ralf Hemmecke]

Greg, what do you expect? Internally it's a binary representation. By which power of 2 would you have to multiply 3.7 to get a natural number so that you can represent 3.7 exactly as an integer mantissa? When you convert 3.7 to Float (that has 20 digits) then you cannot expect to extract 30 correct digits from that 20-digits floating point number. Well, you can, but unfortunately, the number is internally (as a float) not exactly 3.7 anymore.

[Grégory Vanuxem]

Hello Ralf,

Le mer. 7 août 2024 à 13:38, Ralf Hemmecke <ra...@hemmecke.org> a écrit :
>
> Greg, what do you expect? Internally it's a binary representation. By which power of 2 would you have to multiply 3.7 to get a natural number so that you can represent 3.7 exactly as an integer mantissa? When you convert 3.7 to Float (that has 20 digits) then you cannot expect to extract 30 correct digits from that 20-digits floating point number. Well, you can, but unfortunately, the number is internally (as a float) not exactly 3.7 anymore.

Yes, I know how a floating point number is represented for hardware
computations and 3.7 was chosen because internally it will be an
approximation, even if it can exactly be represented by a rational. If
I take care of string conversion it is because when you mix (coerce in
the panAxiom sense) different implementations, using string is usually
the preferred way, It leaves it to the implementation to convert them
in the way that suits it best. You know this I think. Moreover since I
am also coding a small interface to Mathematica, depending on the
number of numbers given in a string format it will be coerced
differently.

That's all.

- Greg

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/a690a18f-0aa0-4cd4-9d1e-ecab9d2deb09n%40googlegroups.com.

[Waldek Hebisch]

I am looking more into output convertion for floats and current
implementation looks somewhat irregular. We have:

- "fixed" convertion which actually has two different behaviours.
With given precision it outputs given number of digits (possibly
0) after dot. With "default" setting (no precision specified)
it first produces up to 'd' significant digits where 'd' is current
precision expressed in digits, but then trims trailing zeros. In
particular, in default setting number of digit printed after dot
is variable,
- "floating" convertion is simplest one, with only irregularity
due to printing or not printing spaces around "E",
- "general" convertion prints either floating form or kind of fixed form.
The fixed form uses different rules than "fixed" convertion and
choice between floating and fixed form is somewhat irregular.


I think about following changes:
- make slightly different rule in "general" convertion: use fixed
form when there are at most 5 leading zeros before most significant
digit (this is current rule) or there are at most 2 trailing
zeros before the dot (this is change compared to current rule),
- with specified precision print given number of digits in
"general" convertion (this is change, current code may skip trailing
zeros in such case)
- with default precision (that is taken from floating point precision)
trim trailng zeros (this is mostly current behaviour, but I would
like to eliminate exceptions).

Note: currently floating point zero is normally printed as "0.0",
and only fixed format with specified number of digits prints
trailing zeros. I think that we should keep this even when it
contradicts literal reading of rules above. Simply, zero is
very special. But I would prefer to get rid of other exceptions.

--
Waldek Hebisch

[Grégory Vanuxem]

I like your opinion.

--
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 fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZrzAb1najE4ldF4A%40fricas.org.

[Waldek Hebisch]

On Wed, Aug 14, 2024 at 04:34:23PM +0200, Waldek Hebisch wrote:
> I am looking more into output convertion for floats and current
> implementation looks somewhat irregular.

I have a little correction to what I wrote above: default output
precision is determined by bit length of mantissa. This means
that there will be some discrepancy converting this to number
of digits. As implemented, number of digits may be smaller.
Usiually this is OK, because value is rounded which leads to
simpler output. But numbers with exponent 0 are in fact
exact integers, so we want to print them in full accuracy.
So special case for exponent 0 is justified.

> I think about following changes:
> - make slightly different rule in "general" convertion: use fixed
> form when there are at most 5 leading zeros before most significant
> digit (this is current rule) or there are at most 2 trailing
> zeros before the dot (this is change compared to current rule),
> - with specified precision print given number of digits in
> "general" convertion (this is change, current code may skip trailing
> zeros in such case)
> - with default precision (that is taken from floating point precision)
> trim trailng zeros (this is mostly current behaviour, but I would
> like to eliminate exceptions).

Attached is my current code, it implements changed rule for general
output. Changes in test result are quite small. As you can see
code is quite different than the current one. To use 'fixed_mr'
in FloatingPointSystem I had to export it. I did not want to
export it from Float (which is exposed), so it had to go to
a separate new package. 'fixed_mr' needs several support routines,
so they had to go to the new package. To avoid fiddling with
global variables all needed information is passed via parameters.
In particular there is a new package exporting operations which
beside normal arguments also take requested precision as an
extra argument. Once I was doing that I also implemented some
my ideas for improvements to elementary functions, in particular
logarithm is computed solving equation 'x = exp(y)' (it is currently
called 'log_newton' and 'log_newton2', I probably need a better
name as this is different than Newton method).

Anyway, there is new file containg new routines. Currently changes
in behaviour are small, but it is easy to add new fields to mode
record to allow more variation. AFAICS possibly controlable
behaviour includes:
- suppressing (or not) trailing digits
- putting spaces (or not) around "E" in exponential notation
- we could easily make separator configurable

We could probably add option for different "floating" notation,
so that dot goes after first significant digit. In principle
we could also put dot in other positions, but I am not sure
if that would be good idea (I suspect that exponential notation
with dot in different place than befor or after first significant
digit are less readable).

--
Waldek Hebisch

[Grégory Vanuxem]

Hello Walked,

That's good I think, thanks.

Successfully patched, built, and "tested" on my personal branch.

I also like the possibility of adding new output variations, I
encounter some of them but, as of now, I need sometimes to regex
replace some artefact notation marks (from a Julia package).

Some other notions are beyond my knowledge.

Greg