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 <smallt...@jgfoster.net> 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 <steph...@netcourrier.com
>> <mailto:steph...@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.n...@gmail.com
>>> <mailto:nicolas.cellier.aka.n...@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 <smallt...@jgfoster.net
>>> <mailto:smallt...@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
>>>
>>
>
