Reported by scgilardi, May 04, 2009
What (small set of) steps will reproduce the problem?
user=> (class 123.)
In contrast, Java reads such a number as a double.
% javac Foo.java
Foo.java:5: possible loss of precision
found : double
int a = 123.;
Another place this comes up is with a number formatted as 123.e4.
Currently that's an invalid number in Clojure:
user=> (class 123.e4)
java.lang.NumberFormatException: Invalid number: 123.e4
java.lang.Exception: Unmatched delimiter: )
Java reads it as 1230000.0
What version are you using?
Was this discussed on the group? If so, please provide a link to the
Please provide any additional information below.
I've enclosed a patch to LispReader.java that fixes the problem. The patch
contains two changes, one necessary, one optional:
necessary: change the regular expressions intPat and floatPat so that "1."
is not considered an "int" and "1.e3" is accepted as a legal float.
optional: change the handling of the "M" suffix in matchNumber to make the
float handling code use matcher groups like the int and bigint handling
code does rather than using string manipulations.
I recommend both changes.
Comment 1 by scgilardi, May 04, 2009
I've attached a patch to clojure-contrib/src/clojure/contrib/test_clojure/reader.clj
to provide additional tests for reading Doubles and BigDecimals that pass with the
fixed Clojure LispReader.