Re: [Jscheme-user] 081 ?bug?

[Ken A. <kan...@bb...>]

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.

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>