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 
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 alternatebase 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 :

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

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 radixbased 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 floatingpoint 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:
I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 214. It seems to me that the primary value of exponents on nondecimal (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

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 :

In reply to this post by jgfoster
Thanks for the explanation.
We should pick solution one:
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 [leadin 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 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). 
Free forum by Nabble  Edit this page 