Performance riddle anyone?
(crit/quick-bench (NaN? 37.648145389078360M))
Execution time mean : 4.465326 ns
Execution time std-deviation : 0.015779 ns
(crit/quick-bench (NaN? 37.648145389078361M))
Execution time mean : 162.714021 ns
Execution time std-deviation : 2.788535 nsSomething to do with converting BigDecimal to double.
It has indeed, and yet so tricky if you only test with smaller bigdecimals thinking it is fine.
We need a new type SmallBigDecimal
bigLITTLEdecimal for that ARM compatibility
can bigdecimals be nan though? I guess not?
The docs say they can't be nan nor infinite
Here's where the difference comes from:
user=> (long (double 37648145389078360))
37648145389078360
user=> (long (double 37648145389078361))
37648145389078360
For values for which the roundtrip value is the same, a fast conversion path is used.Numeric types auto-cast is the issue, indeed. Quite annoying
It's not about auto-casting per se. A manual cast leads to the same exact behavior. Just calling (.doubleValue big-dec) is enough.
Hm, and I though it's autocast: NaN? -> Double/isNaN that accepts native double . So BigDecimal gets coerced to native double
Well, yes. But it's just a way to surface the issue, it's not the root cause itself.
The root cause is the implementation of BigDecimal.doubleValue. It can indeed be called by auto-casts, but it can also be called by something else.
I made a GitHub Community suggestion: “Rainbow parenthesis” for Clojure and Lisp dialects: https://github.com/orgs/community/discussions/178446
i find rainbow parens useful when writing code but not really when reading it
i dislike parinfer and don’t use it, it messes with the vim undo log
I thought I would love rainbow parentheses when I first learned of them, both due to making scope clearer and due to added playfulness of the colors 🤗 took me a little while to figure out that it really only distracted and confused me when I read code. So I would personally be sad if this became the default for GitHub. As an opt-in per-user setting, sure.
It helps a lot when indentation is done well, by lining up maps, vectors, function parameters, etc.
Use the latest version of: weavejester/cljfmt (https://github.com/weavejester/cljfmt) and the following highlighting options in .cljfmt.edn:
;; Requires `github:weavejester/cljfmt:0.15.2`
:align-form-columns? true
:align-map-columns? true
:align-associative? true
This was only possible within the last couple of weeks because he just released the features.I think people from other programming languages won't like it. Say in ruby and python, we intend the code so that the parenthesis align, so just by looking at the code we know which bracket matches which one. But ya, if GitHub can make this stuff exclusively for Clojure, it might be good 👍
ime rainbow parens just look too noisy
probably individual differences in color perception affect it as well, but I don't want to draw attention to parens, because I don't think about them, paredit keeps them "right".
I prefer to highlighting only relevant context like current symbol, strings/documentation, numbers, problems and "dangerous" commands. Everything else I have just turned off. For me it is calmer and more productive, so I very much agree with @reefersleep that this should be configurable.
I don't like rainbow parenthesis. But for GitHub I would find it cool. If you read code in a web page, I dont mind if it has colored parens. It looks nice. It makes Clojure more colorful, friendly and attractive for people who don't know it yet.
imagine all your sheet music was annotated to show where the beats were 1 e & a 2 e & a 3 ....