This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-18
Channels
- # aws (3)
- # beginners (18)
- # boot (3)
- # cider (47)
- # clara (54)
- # cljs-dev (62)
- # clojure (104)
- # clojure-berlin (1)
- # clojure-denver (1)
- # clojure-italy (1)
- # clojure-nl (22)
- # clojure-russia (30)
- # clojure-spec (28)
- # clojure-uk (95)
- # clojurescript (31)
- # cloverage (1)
- # cursive (1)
- # datomic (17)
- # duct (4)
- # emacs (27)
- # fulcro (36)
- # graphql (1)
- # hoplon (1)
- # jobs-discuss (1)
- # lein-figwheel (1)
- # lumo (2)
- # off-topic (44)
- # om-next (5)
- # onyx (29)
- # precept (1)
- # re-frame (8)
- # reagent (7)
- # ring (1)
- # ring-swagger (2)
- # schema (4)
- # shadow-cljs (185)
- # spacemacs (21)
- # specter (59)
- # tools-deps (7)
- # vim (15)
- # yada (1)
cljs.core/mod
can give different results from both clojure.core/mod
and javascript's %
, for integers less than but close to 2^53; is that considered a bug?
close meaning same order of magnitude; can be less than 2^52 in fact
(mod 4503601479059755 4503601479059764)
in particular
it's also inconsistent with the same calculation done using doubles in clj-jvm, and so I assume also doubles in java
the cause seems to be some tricks done in cljs.core/mod
to deal differently with negative numbers
so it seems workaroundable, at least in this case, by testing the size of the number
example of what? I gave (mod 4503601479059755 4503601479059764)
above
not in clojurescript
add a .0
to test doubles in clj
the first arg is smaller by a bit, so the correct answer is to return the first arg
everything gets that answer except cljs, which returns, I think, the first arg plus 1
due, I assume, to precision lost during the arithmetical tricks
I expect clj just defers to the jvm
okay so you agree it's a bug then
oh okay, I'm not familiar enough with %
then
(defn js-mod
"Modulus of num and div with original javascript behavior. i.e. bug for negative numbers"
[n d]
(cljs.core/js-mod n d))
(defn mod
"Modulus of num and div. Truncates toward negative infinity."
[n d]
(js-mod (+ (js-mod n d) d) d))
that's my theory
I hypothesized based on the reference to negatives in the docstring that those gymnastics shouldn't be necessary for positive numbers
Wonder how much a branch on positive / negative would impact it? Only need the addition if it's negative?
and you'd also have to worry about the very large negative numbers
I doubt it makes it to the bigdec branch of that code
based on the test here: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Numbers.java#L201
floating point numbers drive me nuts
which one exactly?
you've added an impressive amount from an iPhone already
okay, thanks for the pointers. I'm heading to bed
Putting in some ClojureScript time today let me know if there’s something you want me to look at
@mfikes https://dev.clojure.org/jira/browse/CLJS-2701, this one doesn’t apply because of CLJS-2751
Hah, CLJS-2751 and CLJS-2701 are the same defect, fixed in two different ways by me. My memory sucks. 🙂
Documentation list for next release: https://gist.github.com/mfikes/b457cb5d850af87d5047d1ac0c99c6d6