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 <Smalltalk@jgfoster.net> 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:
1. Enforce a uppercase and lowercase distinction (digit and exponent respectively); 2. Allow exponents on decimal (base ten) numbers only; 3. Interpret âeâ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or 4. 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 <stepharo@netcourrier.com> 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 < nicolas.cellier.aka.nice@gmail.com> 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 <Smalltalk@jgfoster.net> 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