(def *boom* 2.2250738585072012e-308)
(println *boom*)
This is not clojure fault, btw. In this article (thanks dvd, thanks C8E, thanks geekml it!) more on this issue. And I thought I could safely affirm that the above program was going to terminate...
The example over there is in clojure, because it is easier to write and test. However, the problem is with an algorithm buried deep in the JVM dealing with the conversion of strings to doubles. The algorithm fails to terminate with the above number. It happens both at compile time (if you place the number as a literal) or at runtime, if you feed it to Double/parseDouble). This is common to all languages on the JVM.
As variant of the algorithm are quite widespread, other languages may suffer from the problem as well (perhaps with different numbers). An example is PHP, which had a similar bug some time ago. However, "Perfumery languages"[0] seem to be immune.
Right now, the JVM bug should have been fixed. Does this make Java a perfumery language as well[0]?
(println *boom*)
This is not clojure fault, btw. In this article (thanks dvd, thanks C8E, thanks geekml it!) more on this issue. And I thought I could safely affirm that the above program was going to terminate...
The example over there is in clojure, because it is easier to write and test. However, the problem is with an algorithm buried deep in the JVM dealing with the conversion of strings to doubles. The algorithm fails to terminate with the above number. It happens both at compile time (if you place the number as a literal) or at runtime, if you feed it to Double/parseDouble). This is common to all languages on the JVM.
As variant of the algorithm are quite widespread, other languages may suffer from the problem as well (perhaps with different numbers). An example is PHP, which had a similar bug some time ago. However, "Perfumery languages"[0] seem to be immune
Right now, the JVM bug should have been fixed. Does this make Java a perfumery language as well[0]?
No comments:
Post a Comment