Le lun. 26 juin 2023 à 22:00, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> a écrit :

Hi Christoph,

Le lun. 26 juin 2023 à 20:42, <christoph.thiede@student.hpi.uni-potsdam.de> a écrit :

Hi all,

this is a rather loose collection of some observations and questions that came to my mind while exploring floats and scaled decimals. Comments and patches appreciated.

1. Exponential notation in radix floats
13r0.1e2 --> 13.0
14r0.1e2 --> 14.0
15r0.1e2 --> 0.12948148148148148
"How can I specify the exponent for bases where e is treated a digit? Should this be possible in literal syntax?"

This used to work in the past, because once upon a time, only uppercase ABCDEF were accepted as hexadecimal digits (and up to Z in base 36).

But when we extended hexadecimals to lowercase, we broke it.

I think that this was http://source.squeak.org/trunk/Multilingual-ar.87.diff

Since this is a rarely used feature, and since this would probably require a change in literal syntax, we did not restore the feature, leaving it half broken...

What syntax would you propose for it?

 

2. Exponent letters
"Answer to myself re 1:"
15r0.1q2 --> 15.0
"Wow! Why is this supported in SqNumberParser>>#exponentLetters? I have seen this nowhere else. And just to uphold my question from above, think about this:"
26r0.1q2 --> 26.0
27r0.1q2 --> 0.0728039424884418

If I remember, q is in ANSI standard, you'll have to check...

e = exponent

d = exponent for double precision

q = exponent for quadruple precision

The dialect is free to implement whatever precision.

In Squeak, we currently support only double precision Float, but still interpret the ANSI syntax and round to (nearest I hope) Float.

Some dialects support the 3 kinds of Float (LimitedPrecisionReal)

Note that long float of C is not necessarily quadruple precision, it's often the 96 bits float of legacy intel math proc (with 80 bits significand).

If I remember, ANSI Smalltalk made no provision for distinguishing this kind from quadruple thru the exponent letter.

Hem, must be drunk, I mean the 80 bit long float with 64 bits significan, sorry.

 

Also note that the exponent part is always a decimal

2r0.1e10 is 512, not 2

And we cannot write 2r0.1e2r10.

 

3. Limited precision in scaled decimals
SpaceTally new spaceForInstance: 0.10s2 depth: 2. --> 48
SpaceTally new spaceForInstance: 0.1010101010101010101010101010101010101010101010101010101010101010s2 depth: 2. --> 128
"If not here, when is precision lost at all? Should the number parser truncate this? How can I compact my existing scaled decimal instances based on their scale?"

Currently ScaledDecimals don't truncate.

They are just Fraction in disguise (Fractions that print differently, and approximately)

 

4. Scale in radix notation
"Follow-up question for 3., so I could not really test this:"
2r0.10101s1 --> 0.6s1
2r0.10101s2 --> 0.65s2
"I would rather have expected 0.5s1 and 0.5s1 here. So, the current behavior seems to be that the scale always refers to the decimal representation of the number even though the literal is written in a different base? Does this actually make any sense or should we disallow this combination of radix and scale? Or can we translate the scale to between the numeral systems, i.e., (sourceBase ** sourceScale - 1 log: targetBase) ceiling?"

I think it's all in the name, ScaledDecimals print in decimal form (which means base 10).

So it's not unsurprising that the scale inst.var. specifies the number of decimal places, rather than the number of places after fraction separator in whatever base.

Maybe you would like some form of FixedPointNumber of the form numerator / (base raisedTo: scale), of maybe with an absolutely arbitrary scale numerator / scale, where numerator is an Integer, and with rounding rules like round to nearest, tie to even ?

 

5. Printing scaled decimals in base
1s printStringBase: 2 --> error: SubclassResponsibility: My ScaledDecimal subclass should have overridden printOn:base:
"Seems to be missing yet..."

Yes.

But how many digits are going to be printed after the fraction separator ?

What are the requirements ? Enough digits so that the re-interpreted string prints as the original ?

 

6. Beyond base 36
"This is clear:"
35 printStringBase: 36 --> 'Z'
36rZ --> 35

IMO, we should better signal an Error at this stage

 

"But then..."
36 printStringBase: 37 --> '['
37r[ --> syntax error: a digit between 0 and [ expected ->[
"D'oh! And the error message does not really make it clearer. :) Should we disallow radix base 37 and larger? Or can we just make it so that 44r~^é evaluates to 77263?"

Best,
Christoph

---
Sent from Squeak Inbox Talk