This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-13
Channels
- # announcements (13)
- # beginners (52)
- # bitcoin (2)
- # calva (2)
- # cider (7)
- # clara (1)
- # clj-commons (11)
- # clj-kondo (6)
- # cljdoc (14)
- # clojure (68)
- # clojure-belgium (1)
- # clojure-denmark (6)
- # clojure-europe (57)
- # clojure-nl (2)
- # clojure-norway (10)
- # clojure-uk (3)
- # clojurescript (7)
- # code-reviews (17)
- # conjure (1)
- # cursive (5)
- # dev-tooling (11)
- # emacs (9)
- # fulcro (12)
- # hugsql (20)
- # introduce-yourself (6)
- # joyride (2)
- # leiningen (1)
- # lsp (61)
- # malli (30)
- # missionary (11)
- # nbb (6)
- # off-topic (26)
- # portal (5)
- # practicalli (5)
- # re-frame (8)
- # releases (8)
- # sci (21)
- # shadow-cljs (3)
- # sql (17)
- # squint (1)
- # xtdb (3)
My wife uses vvvv, and it's quite a joy to see a render evolve right in front of your eyes. Alas, it's not really open source and Windows-only. Have been thinking of maybe trying to create something in Clojure that would be similar in concept but simplistic, just as a POC.
Sounds like a great idea. I think CFDG is pretty simple, it's basically just drawing SVG shapes & paths down to some vanishing point. some of the features (like direct path support) don't really get used much and could be dropped
I wrote this guy 5 years ago, and it did pretty good against OpenJDK 8 & 9's BigInteger across ~170 microbenchmarks https://github.com/nervous-systems/java-unsigned-integers — note that the biggest wins are in methods which are not dependent on the assumption that the number is of fixed width. I re-ran the benchmarks today, expecting to get trounced, but did alright. Not "broken y-axis" levels of alright, but still worth a write-up of how to speed up BigInteger with a couple genuinely trivial optimisations. Note that the defeats in multiply and pow are due to multiplyToLen
being intrinsic.
A bit of a stretch to relate it to this, but coincidently I recently found/read all the articles you wrote related to the EVM (which are now only live on http://archive.org i believe, for example https://web.archive.org/web/20171018230231/https://nervous.io/clojure/crypto/2017/10/18/clojure-evm-ii/), and your clojure implementation Sputter, which might have motivated you to make that uint library, and found them to be excellent. It probably would have taken me 10x longer to understand those things if it weren't for those articles and your code. So thanks for writing those! And if you're suggesting possibly writing more stuff regarding the BigIntegers, I would certainly read it!
Good stuff. Not really sure how these compare to yours but on the off chance this is interesting there are also these java uint implementations for similar use cases here: https://github.com/apache/incubator-tuweni/tree/main/units/src/main/java/org/apache/tuweni/units/bigints
(They're built on top of custom Bytes implementations and at least seems to have a much larger surface area than your library)
They're used in the besu ethereum execution client fwiw (which is a somewhat enterprisy thing I've been digging into )
Irritatingly enough it's not cut and dried, it does well on some of the XOR benchmarks, and horrifically on some of the others, like BigInteger, so i'm probably going to have to do a full benchmark
their speedups are due to keeping leading zeroes in the integer array, and having trivially unrollable loops by using an INT_SIZE constant, whereas my implementation of, say, XOR, or anything else, is designed to work on arrays of arbitrary size (so you could very easily write a UInt512 or UInt1024, etc. — there's no math in the class itself)
@U064UGEUQ here is that article https://nervous-systems.github.io/java-unsigned-integers/