*unchecked-math* is a compiler flag.
On Tue, Dec 6, 2011 at 7:00 AM, Cedric Greevey <cgree...@gmail.com> wrote:
> user=> (binding [*unchecked-math* true] (map int [33 77 0xffffffff]))
> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out
> of range for int: 4294967295>
>
> The cause of this:
>
> (defn int
> "Coerce to int"
> {
> :inline (fn [x] `(. clojure.lang.RT (~(if *unchecked-math*
> 'uncheckedIntCast 'intCast) ~x)))
> :added "1.0"}
> [x] (. clojure.lang.RT (intCast x)))
>
> The inline and non-inline version don't coincide -- the non-inline version
> lacks the check for *unchecked-math*.
>
> On top of that, the inline version sort-of doesn't work anyway --
> specifically, it doesn't work if you do "the obvious":
>
> user=> (binding [*unchecked-math* true] (int 0xffffffff))
> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out
> of range for int: 4294967295>
> user=> (defn foo [] (binding [*unchecked-math* true] (int 0xffffffff)))
> #'user/foo
> user=> (foo)
> #<IllegalArgumentException java.lang.IllegalArgumentException: Value out
> of range for int: 4294967295>
>
> The problem there is apparently that it checks *unchecked-math* at
> macroexpansion time, and of course binding it at runtime to do some
> unchecked math therefore binds it too late to influence the int function.
>
> If this is intentional, to avoid expensive runtime checks of dynamic Vars,
> then there are two additional problems.
>
> First, there's the apparent lack of an unchecked-int function, or similar,
> that either is unchecked or checks *unchecked-math* at runtime, for those
> who want dynamic behavior even if there's a cost.
>
> Without this, there's no way to get unchecked int casts in map and other
> HOFs short of ugly hacks like #(int %) or
> #(clojure.lang.RT/uncheckedIntCast %).
>
> Another use case would be when using ints not for speed but because you
> want a 32-bit wraparound integer for some other purpose, such as talking to
> I/O devices or legacy file formats that want such things, or to implement
> certain algorithms that rely heavily on wraparound and bit arithmetic in a
> relatively speed-insensitive context, likely where I/O is the bottleneck.
>
> Furthermore, though (do (set! *unchecked-math* true) (println (int
> 0xffffffff)) (set! *unchecked-math* false)) works, it is ugly as sin and
> set! is (usually) evil.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
