> On Sep 5, 2019, at 9:38 AM, ducasse <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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
>>>> <[email protected]
>>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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
>>>>
>>>
>>
>
