a1k0n

CORDIC is more accurate, but takes as many iterations as you have bits of precision in your angle. Another demo called Warp in this contest used pipelined CORDIC to do atan2 on every pixel to create a tunnel, which is super impressive.

https://www.youtube.com/watch?v=K9mu3getxhU&t=780s

Yeah, it is exact in this specific circumstance. But yes, it's exactly the same trick; I also enjoyed that video in my Youtube recommender feed last week!

And this thread shows all of them on real hardware: https://x.com/i/status/1992802154370011595

Ah that's what I get for self hosting. What browser?

https://youtu.be/7xPS-0nydms

lmao! that was so cringe I unlisted it from the main index. who is "we"?

part 3 is to find the secp256k1 private key for satoshi's bitcoins

Yes, it has to in fact. If you have zero context to attend to in a transformer, and you try to predict the first token, you effectively are multiplying a zero-vector by the attention head, making all tokens equally likely in the final softmax (unless the lm_head has a bias, but at least in GPT it does not).

So the <|beginning of text|> token, with no context before it, learns to predict the first-token-in-a-document distribution. That's not quite the same as predicting nothing at all.

For finding interesting Ethereum addresses on the GPU (uses SHA3 instead of MD5) there's a tool called profanity.

Amusingly the tool was archived by the author years ago, and just last year a stupid bug in the random initialization code was found (32 bytes of state initialized with ~31 bits of entropy), leading to ~millions of $ in stolen ETH by exploiters.

> If anyone has an idea why the TIA’s designers used LFSRs for this stuff, I’d love to hear about it.

I'm guessing because a counter would have ripple carry (i.e. five extra gate delays when rolling over from 111111 to 000000) or need extra gates for carry lookahead and an LFSR is constant-delay.

https://github.com/a1k0n/asciitracing sort of combines those things also

I have to admit I stole the idea from this 256-byte demo (after it wiped the floor with the one I made at a demo party): http://www.pouet.net/prod.php?which=5327

I tweeted a screenshot of the Jupyter Notebook session I used to create the code at the bottom: https://twitter.com/a1k0n/status/1301261285800030208

Oh, yeah. I had to do that for the RISC-V port, too. I'll update the post, thanks.

Yeah, that one wasn't too hard but it's nice to have it to check your work. I didn't go into it in the post, but the real power of SymPy is its cse() function, which I used to do all the common subexpression elimination for the integer math version at the bottom.

Huh, it has 15 registers? AX, BX, CX, DX, SI, DI, BP, SP; CS, DS, ES, SS, IP, flags. What am I missing?

i mv'd config to config~, then made a copy of it as config. the old file, now renamed to config~, is still read-only.

yes yes, it is owned by me. i edited my username in the "screenshot".

after updating to Catalina I was suddenly unable to edit my own ~/.ssh/config. I still can't figure out why not. I could rename it and make a copy, though, and the old one shows this:

-rw-r--r--@ 1 aaaaaaa staff 2571 Sep 15 2017 config~

com.apple.finder.copy.source.checksum#N 4

com.apple.metadata:_kTimeMachineNewestSnapshot 50

com.apple.metadata:_kTimeMachineOldestSnapshot 50

that file remains read-only to me. what is going on?

I love @foone's content, but I had to unfollow him because his output is so prodigious my entire Twitter feed became just @foone.

On second thought, having seen the rest of what Twitter has to offer, that's not such a bad thing...

Maybe it's filtering by mod/xm and he only released S3Ms?

Heh, you can just click on it to see the result if you don't want to actually compile it.

I'm aware of one paper which tries to fit a local polynomial model to the lateral dynamics, and they have a different model for different positions on the track (it requires really good localization to work): https://arxiv.org/abs/1610.06534

I had some of the vehicle parameters as part of my EKF for a while, but it led to some instabilities in the control.

The main problem is that it's really hard to know what the car's instantaneous lateral velocity is. I think the best you can do is check the difference of velocity*gyro yaw rate and lateral accelerometer measurement to get a noisy lateral acceleration measurement, and that can tell you how well your tires are hooking up. I might try fitting a least-squares model on the fly with something like that.

Nice! Are you doing probabilistic roll-outs, iLQR, or SQP, or what? What does your model look like? I've been struggling with this -- not sure how complex the tire dynamics model needs to be, for instance; do you need the whole Pacejka magic formula or is tanh() good enough?

Yes, that's the current state of the car. It's constantly fighting for traction; there are some lower-level control systems trying to maintain yaw rate (which automatically does things like counter-steering in a drift). I'll get to that in a future post.

The canvases are just some javascript code which draw to the 2d context after a requestAnimationFrame(): https://www.a1k0n.net/js/steering.js

Sure, that sounds good!

Yeah, come check it out, it's pretty fun! https://www.meetup.com/DIYRobocars/