This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-13
Channels
- # babashka (7)
- # babashka-sci-dev (3)
- # beginners (29)
- # biff (16)
- # calva (2)
- # clojars (1)
- # clojure (50)
- # clojure-austin (5)
- # clojure-europe (29)
- # clojure-france (8)
- # clojure-nl (3)
- # clojure-uk (3)
- # clojured (10)
- # clojurescript (19)
- # code-reviews (3)
- # core-async (22)
- # cursive (5)
- # data-science (11)
- # datalevin (1)
- # datomic (10)
- # eastwood (4)
- # helix (4)
- # introduce-yourself (2)
- # jobs (1)
- # jobs-discuss (1)
- # joyride (6)
- # leiningen (4)
- # london-clojurians (2)
- # lsp (82)
- # malli (7)
- # meander (12)
- # minecraft (3)
- # nbb (14)
- # off-topic (52)
- # podcasts-discuss (3)
- # portal (3)
- # re-frame (32)
- # reagent (9)
- # releases (2)
- # shadow-cljs (95)
- # tools-deps (14)
That's pretty artistic :thinking_face:
I think Clojure messed it up and suggested it's green+blue. I'll try to remove clojure 😄 bottom-left looks promising 😄
You can host it on your computer. But... something is not right 😕 I can't generate clojure logos anymore 😕 That's a bummer 😕
git clone
docker-compose up
And then fix the issues with Nvidia and docker integration. I installed nvidia-docker
and nvidia-container-toolkit
. I'm on Manjaro (arch linux).Oh right -- you'll also need to restart docker once you install those packages. systemctl restart docker
. And one of the images weighs 1.3GB.
It kind of gets the green and blue but nothing else :thinking_face: No abstractness, no minimalism... I guess I'll need to add these as words 😄
Signed a contract today for a new job. So happy, current place has been far too stressful, miserable work, geetting moaned at if my timesheets is missing more than 5 minutes entries for the day. No dev processes, everything broken all the time. Going to a place that sounds great, up to date tech stack (.NET Core / net6.0), they are going to train me up on Angular too. A lot better money, private healthcare, more holidays, more bonus. NO TIMESHEETS! I told my boss a while back that I wasn't happy with salary and was looking to leave, they basically ambushed me in a meeting shortly after and tried to talk down to me, tell me I'm useless and they'd rather I just leave. I have no value to them, and definitely not getting a payrise... Then I hand in my notice today and my boss basically said "I never saw this coming... "... WAT, how could you not have seen this coming...
Congrats! Hope you'll be happier there 💚
Sounds like you're walking away from an awful place, congrats! Hopefully you have enough time between jobs to decompress
Congrats, no timesheets is liberating.
Watched this Lamport talk over the weekend and found it had a lot of overlap with Hammock driven dev (Write it down!) https://www.youtube.com/watch?v=-4Yp3j_jk8Q and wanted to recommend for other curious clojurians. Separately: is there a channel for sharing talks/videos/articles?
wasn't sure - b/c it seems more related to clojure instead of problem solving/programming in general
:man-shrugging: I think it’s fine, worst case someone will tell you not to. There’s also #videos but it doesn’t seem to get a lot of traffic :paw_prints:
I was surprised to learn that (max 0.0 -0.0)
always returns 0.0
, irrelevant of the order of the args. Likewise about (min 0.0 -0.0)
and -0.0
.
It doesn't look too odd until you remember that both zeroes are supposed to be numerically equivalent. Of course (< -0.0 0.0)
is false.
Those functions are respectively calling Math/max
and Math/min
so this isn't really a Clojure design choice.
I was wondering if someone had some information about that. In case of numerical equivalence, you could expect the first (or last) arg to be systemically returned instead of making it look like 0.0
is somehow greater than -0.0
.
Should (min 0 5)
randomly return -0
?
Well I'd say that (min -0.0 0.0)
could return -0.0
while (min 0.0 -0.0)
could return 0.0
for instance.
But then also (< -0 0)
should return true, and >
should return false?
Why not wrap it into your own number implementation and try to use it. Who knows how bad it can be.
* Compares two {@code Double} objects numerically. There
* are two ways in which comparisons performed by this method
* differ from those performed by the Java language numerical
* comparison operators ({@code <, <=, ==, >=, >})
* when applied to primitive {@code double} values:
* <ul><li>
* <li>
* {@code 0.0d} is considered by this method to be greater
* than {@code -0.0d}.
* </ul>
What should be returned by this in your model?
(sign (max -0 0))
+1 or -1?
Are signs suddenly equivalent?
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/Double.java#l959
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/Double.java#l786
As a new Clojure dev but an old dev, I would expect the hardcoded value -0.0
to lose its sign once tokenized and represent the same value as 0.0
with the implied (though ineffective) positive sign. To me, the fact that (println -0.0)
prints -0.0
is the surprise.
@U11BV7MTK Thanks for the pointers! At least this behavior is super consistent.
@U028ART884X Well (sign (max -0.0 0.0))
would return -1
if we apply such a rule that the first arg is returned in case of numerical equivalence. Not saying it's inherently better than the current state of affair.
If you would have (+ (- 5) 5)
return -0
and (- 5 5)
return 0
you would get some pretty nasty bugs to solve. Because then sign
would return -1
and 1
based on the order of your calculations. And if you would use sign
later then you would get undefined behavior :thinking_face:
this might just be weirdness for floats. I think there's two ways to represent zero because the sign is stored as a bit, and you can have the rest be zero. So - since the sign can be positive or negative, you can (by accident) represent 0 and -0, which should be the same. But when you do comparisons, perhaps you compare the sign first? Not sure.
Right, I can see how not having an ordering might be problematic in the grander scheme of things.
#sicmutils doesn't seem to produce -0:
(ns toad.polywrath
(:require [sicmutils.env]))
(clojure.core/* 0.0 -3)
;; => -0.0
(sicmutils.env/* 0.0 -3)
;; => 0
I believe that some of the Java method behavior is probably recommended and/or mandated by IEEE floating point standards.
As in, there are probably numerical libraries out there that depend upon exactly iEEE floating point behavior, and will break if you change those. That doesn't mandate the behavior for Clojure functions, of course, but for efficiency it is certainly more efficient for Clojure's implementation if it does not change the behavior of underlying Java methods.
I believe there is a great amount more than the existence and differences between +0.0 and -0.0 that people find surprising about floating point numerics on computers, hence this article: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html. I noticed today that it has a section titled "Signed zero"
I suspect that when IEEE floats and the results of their operations were designed, if there were multiple designers involved, there were probably interesting arguments involved in that process.