This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: kawa numerics unstable
thanks for the clarification. it's not a problem, was just
taken by surprise in places where i had assumed equalness
(i apparently need to watch the changelogs more closely).
the advantages you describe are worth the minor code
adaptations.
Per Bothner writes:
> On 11/12/2009 11:56 AM, thomas kirk wrote:
> >
> > not clear that this is a bug, but it's a change in behavior. before
> > your numerics changes, kawa would automatically convert java numeric
> > types to kawa numerics (in some situations, at least):
> >
> > #|kawa:34|# (invoke (invoke-static<java.lang.Integer> 'parseInt "1") 'getClass)
> > class gnu.math.IntNum
> > #|kawa:35|# (scheme-implementation-version)
> > 1.9.3 (revision 6275M)
> >
> >
> > in the latest revision, this conversion doesn't happen:
> > #|kawa:70|# (invoke (invoke-static<java.lang.Integer> 'parseInt "1") 'getClass)
> > class java.lang.Integer
> > #|kawa:71|# (scheme-implementation-version)
> > 1.9.90 (revision 6451M)
> >
> >
> > so, is the intention that code should now do this conversion explicitly?
> > or is it an unintended consequence?
>
> This is intentional. There are advantages and disadvantages, of course.
> One advantage of the change is that we're more "Java-compatible",
> in that 'int' and 'java.lang.Integer' are more equivalent. This
> matches both Java5 auto-boxing, and java.lang.reflect, so it seems
> desirable.
>
> (Slightly related: Kawa now uses Java5 varargs to implement
> its own varargs, and calling a Java varargs function "works".)
>
> To reduce some of the "surprise" Kawa now can handle arithmetic
> on java.lang.Integer - but that uses 32-bit arithmetic, rather than
> unlimited-precision IntNum arithmetic.
>
> Does this change cause problems? If so: is there something Kawa
> can do to ameliorate the problem?
> --
> --Per Bothner
> per@bothner.com http://per.bothner.com/