still, controversial indeed.
Weirdly, the book itself says:
> Q: May I print this book / use it for teaching? > A: Of course! That’s why the book is licensed under the Creative Commons license (CC BY-SA 4.0)
So it would be legal for anyone else to host this.
I remember a similar "heureka" moment when I derived a line-drawing algorithm that respected "subpixel" starting and ending points. That is, don't assume a line starts/ends in the middle of a pixel (like most algos do), but rather at an arbitrary point.
I forgot why I needed this (something to do with near-axis-aligned polygon slopes not looking right on a highly rasterized problem). But I do remember the elation when I finally got it to work :-) Also early 1990s, no internet and no English for extra fun.
There happens to be a Wikipedia page on "Midpoint circle algorithm": https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
The page claims, "Bresenham's circle algorithm is derived from the midpoint circle algorithm."
The author of this blog post even made it clear, at the end of their article, that... "many explanations of midpoint algorithm use the final, optimized version. But I added several unoptimized steps."
I think there's a lot of value in a blogpost that demonstrates how someone could re-derive a widely-used algorithm from scratch.
I guess I shouldn't be surprised, after all, I've met a lot of people.
y += 1; // y == 1
err += 2*y + 1; // err == 3
x -= 1; // x == radius-1
err -= 2*x + 1; // err == 2-(2*(radius-1))
And you don't need calculus to come up with the algorithm, just simple high school algebra: (x+1)² - x² = 2x + 1.
Does any of this mean anything in JS, where AFAIK there are no real ints? 2x is an fpu operation under the hood, and not a bit shift.
For bitwise operations, JavaScript will first convert the number to a 32-bit two's complement signed integer.
Will JS, at runtime, realize that X is an int and optimize 2 * X into a bit shift operation?
Will JS recognize that Y and Z are perfectly represented integers stored in floats and so use integer instructions when adding Y + Z? Would such a thing even save time with all the casting back and forth to fp?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
WebAssembly has i32 and i64.
2017 https://mirrors.ocf.berkeley.edu/parrot/misc/openbooks/progr...
2018 http://ebook.pldworld.com/_eBook/Reverse%20Engineering%20for...
In addition, some foreign languages still seem to be available:
French https://beginners.re/RE4B-FR.pdf
German https://beginners.re/RE4B-DE.pdf
Italian https://beginners.re/RE4B-IT.pdf
Japanese https://beginners.re/RE4B-JA.pdf
As for interpreted JS, a binary operator returns a 32-bit integer value, but it would be still stored as a Number (float). (Meaning, a | 0 => int, b = a | 0 => float stored in b, there is no other primitive numeric type. – Instead of optimizing for speed, you would be adding implicit type conversions.)
Nowadays the semantics if what happens are still the same, but things happen a bit more optimized by usually avoiding the round-trip to double when not necessary.
(I think, this had been originally introduced by Mozilla and propagated to other browsers to varying extent. This optimization allowed a significant speed up for things like EMScripten before WASM.)
I think that may also have been a problem with asm.js. While the code would work as is because it's just JS, you won't get any performance guarantees because the runtime could just do its own thing instead of doing ahead-of-time compilation to optimized code.