Re: [Jscheme-user] 081 ?bug?

[Robert J. B. <ru...@bb...>]

Tim,
I would certainly vote for this solution. To me it seems strange to 
think that the presence of a leading 0 changes the interpretation of a 
string as a number.
--Rusty


Timothy J Hickey wrote:

>
> On Nov 18, 2004, at 7:52 PM, Ken Anderson wrote:
>
>> Yes.
>>
>>> (string->number "077")
>>
>> 77
>> However, because he is a JScheme user, he  has several alternatives 
>> to choose from:
>>
>>> (string->expr "077")
>>
>> 63
>> a JScheme built in, which uses the JScheme reader.
>>
>>> (Integer. "077")
>>
>> 77
>> that uses a Java reflector.
>
>
> True....
> It seems that there is plenty of room for confusion...
> We can always use Javadot to convert from different bases...
>
>> > (Integer.parseInt "77" 8)
>> 63
>> > (Integer.parseInt "FF77" 16)
>> 65399
>> > (Long.parseLong "FF77" 16)
>> 65399L
>
>
> I suppose we could jettison the octal and hex notation for integers 
> and longs and require
> users to go to javadot if they want to use octal/hex numbers....
>
> ---Tim---
>
>
>>
>> What i'd propose now it to change the error message to be 
>> informative, something like
>> 081 is an invalid octal number.
>>
>> What really worried Rusty and i is that we need to read
>> "0770304" as 77 degrees 3 minutes and 4 seconds. to specify a 
>> latitude or longitude.  We compute these lat/lons for our customers.  
>> We do it correctly, but getting it wrong could be life threatiing.
>>
>> If nothing else we need to change the error and update the JScheme 
>> spec (where ever it is).
>>
>> Though bases other than 10 are pretty strange for our customers and 
>> users, so backing a Java thing that probably goes back to a C thing 
>> for writing device drivers, might be wrong.  There has been plenty of 
>> discussion of this feature of JScheme,  maybe it should be removed.
>>
>> k
>>
>>
>> At 07:23 PM 11/18/2004 -0500, Timothy J Hickey wrote:
>>
>>> This brings us back to an early thread from June of 2004 ...
>>> in which we decided to disallow Java octal notation in 
>>> (string->number x)
>>> invocations, but to allow it in JScheme code to ease the interaction
>>> with Java ...
>>>
>>> On Nov 18, 2004, at 6:25 PM, Robert J. Bobrow wrote:
>>>
>>>> This lef to my trying the following test:
>>>>
>>>>> (- 0777 777)
>>>>
>>>> -266
>>>
>>>
>>>> (- (string->number "0777") 777)
>>>
>>>  0
>>>
>>>> (.getClass (read))
>>>
>>> 081
>>> class jsint.Symbol
>>>
>>>> Is it required that numbers starting with 0 be treated as octal?
>>>> --Rusty
>>>>
>>>>
>>>>
>>> .
>>>
>>> The idea was that JScheme literals should be the same as Java literals
>>> whenever possible to enhance the transparency of the javadot interface.
>>> In standard Scheme code, octal is not very important because you rarely
>>> deal with 32 or 64 bit integers.  Java is a different story, e.g. 
>>> converting from
>>> long bits to double its nice to have a hex representation of 
>>> integers....
>>>
>>> ---Tim---
>>>
>>>
>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: Ken Anderson <kan...@bb...>
>>>>> Date: June 7, 2004 10:24:02 AM EDT
>>>>> To: Timothy John Hickey <tim...@ma...>
>>>>> Cc: JScheme Developers <jsc...@li...>
>>>>> Subject: Re: [Jscheme-devel] string->number
>>>>>
>>>>> So the remaining issue is what should (string->number "08") 
>>>>> return. It currently returns #f. i was hoping it would return 8.
>>>>>
>>>>> At 07:27 PM 6/6/2004 -0400, Timothy John Hickey wrote:
>>>>>
>>>>>> I've modified string->number so that in the base 10 case it 
>>>>>> allows leading zeroes...
>>>>>> The following Unit tests all pass in the current version of 
>>>>>> JScheme...
>>>>>>
>>>>>> "06/06/2004" ;; literal syntax, TJH
>>>>>>
>>>>>> ;; Default literal syntax is for Java literals,
>>>>>>
>>>>>> ;; but string->number will treat leading zeroes as decimal if 
>>>>>> base 10 is specified
>>>>>>
>>>>>> (equal? (.getClass '081) jsint.Symbol.class)
>>>>>>
>>>>>> (equal? (.getClass '0123Dig) jsint.Symbol.class)
>>>>>>
>>>>>> (equal? (.getClass '0123) java.lang.Integer.class)
>>>>>>
>>>>>> (equal? (string->number "081" 10) 81)
>>>>>>
>>>>>> (equal? (string->number "010") 10)
>>>>>>
>>>>>> (equal? (string->number "010" 8) 8)
>>>>>>
>>>>>> (equal? (tryCatch (string->number "081" 8) (lambda(e) 'error)) 
>>>>>> 'error)
>>>>>>
>>>>>> (equal? (string->number "08") #f)
>>>>>>
>>>>>> (equal? (string->number "08" 10) 8)
>>>>>>
>>>>>> (equal? (string->number "10") 8)
>>>>>>
>>>>>> (equal? (string->number "10" 10) 10)
>>>>>>
>>>>>> The implementation of string->number in the base 10 case is
>>>>>>
>>>>>>> public static Object schemeStringToNumber(String tok, int rdx) {
>>>>>>>   try { return U.toNum(Long.parseLong(tok, rdx)); }
>>>>>>>    catch (NumberFormatException e) {
>>>>>>>        try {
>>>>>>>            if (rdx!=10)
>>>>>>>                return U.FALSE;
>>>>>>>            else return new Double(tok); }
>>>>>>>        catch (NumberFormatException e2)
>>>>>>>            { return U.FALSE; }
>>>>>>>    }
>>>>>>> }
>>>>>>
>>>>>>
>>>>>> ---Tim---
>>>>>>
>>>>>>
>>>
>>>
>>> </blockquote></x-html>
>>
>>
>
>