This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Numbers in Kawa
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