Numbers in Kawa

[Jamison Hope]

On Apr 29, 2012, at 3:40 AM, Helmut Eller wrote:

> * Jamison Hope [2012-04-27 21:05] writes:
>
>>> I'd expect a compile time warning and an error at runtime.   
>>> Automagic
>>> coercion from float to int surprises me.  E.g. (string-ref "abc"  
>>> 0.6)
>>> should be an error instead of returning #\a or #\b.
>>
>> That does seem erroneous. I feel like (string-ref "abc" 1.0) should
>> work, though [with a warning], so perhaps it should be an error iff
>> the float isn't already integer-valued?
>
> Floats are tricky, so I think the programmer should state conversions
> from floats to int explicitly.  Coercing int to floats seems less
> problematic and could probably done automatically.

If that's the consensus, then it's fine with me. My rationale for
permitting implicit fp->integer conversion *only when the float
represents an exact integer* was to allow something like
(string-ref s (f i))
where f may be a function that returns a real, but the programmer
is already making sure to only call it with arguments which will
return integral values. For example:
(string-ref "abcdef" (sqrt 16))

It's not something I feel terribly strongly about, but I like the
idea that any number object with an integral value, regardless of
underlying type, can be used in an integer context. Especially
since that's consistent with Kawa's integer? (which matches the
R6 specification).

But at the very least, "(and (integer? x) (as integer x))"
should always return #f or an integer, it should never throw
a WrongTypeException (which it currently does on integral
DFloNums).

>> Perhaps if DFloNum (or a superclass?) had a method like:
>>
>>> public boolean isInexactInteger()
>>> {
>>>  return (0.0 == Math.IEEEremainder(doubleValue(), 1.0));
>>> }
>
> I don't know much about floating-point stuff, but looking at the
> exponent with (Math.getExponent(somefloat) == 0) might be better.

Perhaps; I was merely duplicating the test performed by integer?
in numbers.scm. Using Math#getExponent() would break Java 1.5
compatibility, though.

Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com