This takes me back!

But it feels kinda wrong to have that mouse cursor and have it not move perfectly smooth.

> But it feels kinda wrong to have that mouse cursor and have it not move perfectly smooth.

So you get the full immersive experience. :)

The "immersive experience" would have that cursor move at a solid 60FPS and negligible latency. Amiga had hardware sprites, and even software-managed sprites had comparable performance.

You also need a CRT or at least some sort of strobing refresh display to eliminate smearing from persistence of vision.

This tracker seems to resemble a PC tracker such as Fast Tracker II. Did Amiga play 16bit 32 channel XM files? Hardware mouse cursors on PC were fast, software (custom graphics cursors) were much slower.

Wouldn't an ad like that attract the biggest egos, not necessarily the best coders, nor people you would ever want to be on a team with?

It would attract young coders who you can convince to work long hours for less pay.

The extension is somewhat of a misnomer. It's really a jif. JPEG Interchange Format. You can imagine the confusion if the jif extension caught on.

Don't see the point really.

Languages without tail recursion will perform worse. Memoization is borderline cheating, because it's a different implementation.

Fib is the poster boy for tail recursion but the reason for that is that recursion to implement fib is simply a bad choice. It's cute but that's about it. If the point is to measure function call overhead, then measure _that_?

> Fib is the poster boy for tail recursion

But recursive Fibonacci isn't tail recursive. The final function call is to `+` (addition), which means that the two recursive calls must each be put on the stack and later returned so the sum can be computed. Tail recursion requires that there is no final operation other than exactly a single recursive call.

some compilers can rearrange it to be tail recursive automatically

Pretend you're a compiler, what changes would you make to this to make it tail recursive:

  fib(0) -> 1;
  fib(1) -> 1;
  fib(N) -> fib(N-1) + fib(N-2).

Rules: Making a second function (fib_help) is permitted. Shouldn't use any more memory than this one uses.

Fun challenge.

https://paste.pound-python.org/show/m403qNkpS5I8dnYjJGJq/

I wanna see the compiler that gets that.

Which compilers can rearrange fib, with two recursive calls, into being tail recursive?

If it knows it's a pure function, it's possible. It'd have to be a very specific optimization pass though.

Any LLVM-based compiler. GCC.

But that doesn't make it "poster boy" material, in my opinion.

I called it that because I've seen fib be the go-to example of so many introductions to functional programming.

But I suppose it's more accurate to describe it as the poster boy example for changing an implementation to make it tail recurse.

It can be a gateway for learning interesting things about the mechanics of a language, its compilation, and in turn how to make similar cases in other languages faster/cleaner/more-secure. e.g. why is nim so fast in this case? Is it tail call optimisation, not doing overflow checks, static inlining, or something else? Nim compiles to c to it is especially odd.

Why would languages without tail recursion optimisation perform worse when all languages use the naive implementation? It's not tail recursive, so it shouldn't make a difference, right?

You're right that tail recursion doesn't help - the final operation is the addition, not a recursive call.

Just to underline the futility of this, if you are clever you can let the compiler do it.

https://everything2.com/title/C%252B%252B%253A+computing+Fib...

The benchmark includes a C++ constexpr version, at https://github.com/drujensen/fib/blob/master/fib-constexpr.c... , with timing numbers under the section "Optimized code that breaks the benchmark" and the comment "all benchmarks will have some caveat."

Somewhat off topic, but I love the fact that the first post regarding compile-time Fibonacci in C++ was submitted in 2000, another user expanded on the original in 2008, and now it's being usefully referenced in 2018.

I stumbled across Everything2 recently, but in many ways it strikes me as a tiny bit of the golden age of the internet, unexpectedly preserved.

I've got a 10 year old who's been making a lot of stuff in Scratch since he was 6. I've been trying to think of how to phase him over to less limited languages and wasn't aware of blocklike.js, so thank you for that idea.

Having a lot of projects that you don't finish is completely normal, so don't worry about that.

The move from CRT to LCD adds a few milliseconds depending on the screen. We're so used do it by now, that typing on old hardware is almost jarring. It feels almost TOO responsive.

Latency is not everything. Moving from CRT to LCD probably saved my eyesight from degrading 10 years too soon.

It's sure nice to not have your corneas constantly assaulted by charged dust particles.

i've got a 144hz lcd display. it's amazing. i feel almost like in the good old days.

Yes. Especially if it has an ULMB function that can strobe the backlight.

Theoretically, it should be possible to recompress the video back into the compressed file with no loss, provided the same codec is used, but it would be far more expensive computationally.

Aren't most image/video compression algorithms lossy? There would surely be more than one possible "decompression".

While interesting, it's comparing 5000+ Tensor Processing Units against 64 CPU threads. I suspect this isn't a fair comparison by watts spent.

No - 5000 TPUs were used for training, but the 100-game matches used just 4 TPUs (bottom of p4 in the paper)

from the paper:

> Training proceeded [...] using 5,000 first-generation TPUs

> We evaluated the fully trained instances of AlphaZero against Stockfish, Elmo and the previous version of AlphaGo Zero [...]. AlphaZero and the previous AlphaGo Zero used a single machine with 4 TPUs.

So the 5000 TPUs processing power or energy consumption should be compared with those spent in devising Stockfish, not running it.

People have done this of course, but you cannot convince a flat earther with GoPro footage because of the fisheye lens that will allow you to film the horizon curve either way, depending on the angle.

What you'd need is a wide angle rectilinear lens not normally found on light weight cameras.

He shouldn't expect much from 1800 feet tough in terms of seeing the curvature. It won't be pronounced. I think he just wants to fly.

Counterpoint: you can trivially correct for lens distortions by calibrating the camera on earth using far-away objects.

I agree that he's making claims in bad faith and just wants to fly.

It's square as it's 8x8 pixels, but the pixels themselves are not. There's a difference in aspect ratio between PAL and NTSC variants, and because the C64 was usually connected to a CRT, pretty much all bets are off.