You don't need to tun the whole game at a fixed framerate, only the physics. That's actually common practice.

The bigger problem is that floating point math isn't deterministic. So replays need to save key frames to avoid drift.

Quake used fixed point math.

Quake needs a FPU; if that was true it would run on a 486 SX.

You're right, I must have gotten that mixed up. Sorry.

I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

One of the hardest determinism bugs I had to solve on the PlayStation three was that the PPU and the SPU actually used a different instruction set and had a different internal floating point register size. We had a multi threaded physics simulation, and during instant replay, we had to ensure that the job scheduler sent the exact same work to the correct cores or we got back subtly different floating point values, which of course, immediately caused major divergences.

> I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

Nope, they are not. Part of the problem is that "mostly deterministic" is a synonym for "non-deterministic".

Floating-point non-determinism issues usually come from one of these sources:

- Inconsistent use of floating-point precision, which can arise surprisingly easily if e.g. you had optional hardware acceleration support, but didn't truncate the intermediate results after every operation to match the smaller precision of the software version and other platforms.

- Treating floating-point arithmetic as associative, whether at the compiler level, the network level, or even the code level. Common violations here include: changing compiler optimization flags between versions (or similar effects from compiler bugs/changes), not annotating network messages or individual events with strictly consistent sequence numbers, and assuming it's safe to "batch" or "accumulate" deltas before applying them.

- Relying on hardware-accelerated trigonometric etc. functions, which are implemented slightly differently from FPU to FPU, since these, unlike basic arithmetic, are not strictly specified by IEEE. There are many reasons for them to vary, too, like: which argument ranges should be closest to correct, should a lookup table be used to save time or avoided to save space, after how many approximation iterations should the computation stop, etc.

Nim compiles to C, and it has a compiler iotion that does this.

The CPP does that as well, because once the compiler is invoked, the original source code file is already gone.

Both of those flavors are based on the CommonMark spec. There's just some extra features and some forbidden html.

Choosing names like `App`, `ok` or `get` in a language without namespaces is a bold choice.

JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).

Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).

But they will never change any of that because it would break JavaScript compatibility.

I think the problems with big network were diminishing gradients, which is why we now use the ReLU activation function, and training stability, which were solved with residual connections.

Overfitting is the problem of having too little training data for your network size.

There's a German Wikipedia page: https://de.m.wikipedia.org/wiki/Coinhive

It does work on mobile,but the instructions are cut off.

And it doesn't play like normal solitaire. You can move any card, no matter what's on top of it. That makes it much easier.

I find json5 much better than json, but it has still many of the same annoyances.

- instead of trailing commas, how about making them completely optional? It's not like they are needed in the first place.

- curly braces for top-level objects could be optional too.

- For a data exchange format, there should really be a standard size for numbers, like i32 for integers and f64 for floats.

- parsing an object with duplicate keys is still undefined behavior.

At the very least, division by zero should not be undefined for floats.