Fork me on GitHub
#off-topic
<
2023-01-13
>
moe12:01:50

I've been using it for years, I think it's criminally overlooked

p-himik17:01:04

There's no interactive mode, is there?

moe17:01:08

There's another site with a JS implementation, but it seemed busted. But no.

moe17:01:28

I was thinking of maybe having a go at re-writing it.

moe17:01:49

If only by means of promoting it

p-himik17:01:04

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.

moe17:01:16

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

moe17:01:09

just smash some parens in there

moe17:01:14

the probabilistic thing is a big part of what makes it so cool

moe17:01:52

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.

jjttjj19:01:01

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!

moe19:01:52

Thanks! I really need to reinstate that blog. I did indeed write it for Sputter.

moe19:01:21

Yak shaving galore

jjttjj19:01:19

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

jjttjj19:01:23

(They're built on top of custom Bytes implementations and at least seems to have a much larger surface area than your library)

moe19:01:50

thanks, that's a good spot. i'd be interested in benchmarking them.

moe19:01:59

this looks pretty eccentric

jjttjj19:01:27

They're used in the besu ethereum execution client fwiw (which is a somewhat enterprisy thing I've been digging into )

moe19:01:29

I'll benchmark one of the operations just to get a feel for where it stands

🆒 2
moe05:01:30

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

moe07:01:20

I'm happy with this.

moe07:01:32

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)

jjttjj19:01:46

Looks good! Will read it this weekend