Smalltalk › Pharo › Pharo Smalltalk Developers

Floating-point numbers with radix (non-decimal)?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

jgfoster

Floating-point numbers with radix (non-decimal)?

14r1.2e1 "16.0"

15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

Nicolas Cellier

Re: Floating-point numbers with radix (non-decimal)?

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...

and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...

Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)

Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :

14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

ducasse

Re: Floating-point numbers with radix (non-decimal)?

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?

why 15r1.2e1 is not equals to 15r1.2E1?

why would we need a new syntax?

Stef

On 5 Sep 2019, at 00:19, Nicolas Cellier <[hidden email]> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :
14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

jgfoster

Re: Floating-point numbers with radix (non-decimal)?

Hi Stef,

The question is “How should it work?” How do we distinguish whether the character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is a representation for “what follows is an exponent”? For example, it is easy to recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in GemStone).

For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the same as ‘2r1111’ or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it a hexadecimal digit or is it an exponent identifier?

I believe that there are the following alternatives:

Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or
Develop a new syntax to introduce exponents.

I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14.

It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, I’d assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above).

James

On Sep 4, 2019, at 10:36 PM, ducasse <[hidden email]> wrote:

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?
why 15r1.2e1 is not equals to 15r1.2E1?
why would we need a new syntax?

Stef
On 5 Sep 2019, at 00:19, Nicolas Cellier <[hidden email]> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :
14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

Nicolas Cellier

Re: Floating-point numbers with radix (non-decimal)?

Though base 16 is what is used elsewhere (for example %a of C/C++ printf).

It marries both compactness and exactness which is good for interchange format.

Le jeu. 5 sept. 2019 à 15:06, James Foster <[hidden email]> a écrit :

Hi Stef,

The question is “How should it work?” How do we distinguish whether the character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is a representation for “what follows is an exponent”? For example, it is easy to recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in GemStone).

For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the same as ‘2r1111’ or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it a hexadecimal digit or is it an exponent identifier?

I believe that there are the following alternatives:
Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or
Develop a new syntax to introduce exponents.
I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14.

It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, I’d assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above).

James

On Sep 4, 2019, at 10:36 PM, ducasse <[hidden email]> wrote:

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?
why 15r1.2e1 is not equals to 15r1.2E1?
why would we need a new syntax?

Stef
On 5 Sep 2019, at 00:19, Nicolas Cellier <[hidden email]> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :
14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

ducasse

Re: Floating-point numbers with radix (non-decimal)?

In reply to this post by jgfoster

Thanks for the explanation.

We should pick solution one:

Enforce a uppercase and lowercase distinction (digit and exponent respectively);

Why would we need to have HEX in lowercase for exponent?

Is there any adavantage.

I found 2r1.111eef quite unreadable 2r1.111eEF

On 5 Sep 2019, at 15:05, James Foster <[hidden email]> wrote:

Hi Stef,

The question is “How should it work?” How do we distinguish whether the character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is a representation for “what follows is an exponent”? For example, it is easy to recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in GemStone).

For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the same as ‘2r1111’ or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it a hexadecimal digit or is it an exponent identifier?

I believe that there are the following alternatives:
Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or
Develop a new syntax to introduce exponents.
I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14.

It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, I’d assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above).

James

On Sep 4, 2019, at 10:36 PM, ducasse <[hidden email]> wrote:

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?
why 15r1.2e1 is not equals to 15r1.2E1?
why would we need a new syntax?

Stef
On 5 Sep 2019, at 00:19, Nicolas Cellier <[hidden email]> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :
14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

jgfoster

Re: Floating-point numbers with radix (non-decimal)?

On Sep 5, 2019, at 9:38 AM, ducasse <[hidden email]> wrote:

Thanks for the explanation.
We should pick solution one:

Enforce a uppercase and lowercase distinction (digit and exponent respectively);

Why would we need to have HEX in lowercase for exponent?
Is there any adavantage.
I found 2r1.111eef quite unreadable 2r1.111eEF

I should have said

1. Enforce an uppercase and lower case distinction (digit and exponent [lead-in token] respectively)

So for option 1, ‘e’ is always a token indicating that an exponent follows, while ‘E’ is always the value fourteen (a ‘digit’). This would mean that ‘16rff’ would be illegal (since lowercase is not allowed for a hex digit).

I believe exponents are always base ten, even if the primary part of the number is a different base. So, in ‘2r1e10’ the exponent is four, so there are ten zeros (’10’ is decimal) after the 1, not two zeros (binary). There would never be a hex exponent (‘eEF’ would be illegal, not 239 zeros!).

James

On 5 Sep 2019, at 15:05, James Foster <[hidden email]> wrote:

Hi Stef,

The question is “How should it work?” How do we distinguish whether the character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is a representation for “what follows is an exponent”? For example, it is easy to recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in GemStone).

For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the same as ‘2r1111’ or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it a hexadecimal digit or is it an exponent identifier?

I believe that there are the following alternatives:
Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or
Develop a new syntax to introduce exponents.
I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14.

It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, I’d assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above).

James

On Sep 4, 2019, at 10:36 PM, ducasse <[hidden email]> wrote:

Hi nicolas

let us fix this :)

why 15r1.2e1 is not working?
why 15r1.2e1 is not equals to 15r1.2E1?
why would we need a new syntax?

Stef
On 5 Sep 2019, at 00:19, Nicolas Cellier <[hidden email]> wrote:

Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float

Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E

Then it was considered better to understand hexadecimal numbers with lowercase too...
and alternate-base Float became ambiguous and were never fixed :(

This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ...
Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;)
Maybe because it's too easy :)

Le jeu. 5 sept. 2019 à 00:04, James Foster <[hidden email]> a écrit :
14r1.2e1 "16.0"
15r1.2e1 “1.195851851851852"

Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone.

James

jgfoster

Re: Floating-point numbers with radix (non-decimal)?

> On Sep 5, 2019, at 12:40 PM, James Foster <[hidden email]> wrote:
>
> So, in ‘2r1e10’ the exponent is four,
ten [I edited the example but missed this place]
> so there are ten zeros (’10’ is decimal) after the 1, not two zeros (binary).