Re: [Jscheme-user] 081 ?bug?

[Timothy J H. <tjh...@br...>]

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