Geometry for Programmers. A book

It's a book. I'm writing it. It's currently in the Manning Early Access Program: there are four chapters published as of today and eight more to go.

It is exactly what it says in the title. It's geometry explained for programmers. It covers topics starting from jargon and definitions to the most popular parts of computational geometry. It's not particularly deep, it's mostly focused on applications.

There are other books like mine but they all serve a different purpose. They try to turn a reader into a geometer. This one doesn't. It's supposed to make a reader a better programmer with a pragmatic minimum of geometrical education. Let me elaborate on that.

A few months ago I was involved in a really innovative project with all the right keywords. There was a cloud, there was GPGPU, micro-services, C++20, massive-parallel computation, you name it. There was also a bug.

There was a picture of a certain simulation result, and the picture became scrambled every time the simulation had unequal dimensions. If it's square - everything's fine, if it's not - it isn't.

I was eager to take a look and what I found inside was a simple nested loop that reinterpreted the numbers into colors and added them one by one as the picture's pixels. The outer loop had an index name "j" and the inner - "x".

Um. Nothing wrong with one-letter indices. But there are conventions for that. If you work within a screen space, "x" and "y" are fine. If you work within a matrix, we usually use "i" and "j". The "x" and "j" then indicate a column of a bitmap and "y" and "i" - a row. It's all fine as soon as you follow one of the conventions.

The author preferred to follow both of them at the same time. And in a contradicting manner too.

"You probably have your indices messed up." I proposed. "How can you know that?" "I don't, it's just that the loop has a smell. Can we try swapping them out?" "I'd rather not but if you insist…"

And we did. And it worked. The picture wasn't scrambled anymore.
Except that now it appeared rotated 90 degrees clockwise.

"Ah! Then it's not the indices, it's the dimensions that were messed up! Let's try swapping the dimensions instead of indices then." "No-no, let's not risk it. Let's just rotate the picture."

Risk? Where's the risk in swapping two numbers? But I didn't object. That one extra rotation didn't cost us any considerable run time so it was kind of ok. Perhaps, I could have convinced my colleague to go the other way, but I was already thinking about something else.

It's not really a question of "how do I rotate a picture", there are indeed ready-made methods to do this. The real question is how come the most brilliant people, smart and knowledgeable, capable of designing and implementing a high-performant ultra-modern software system, are still reluctant to swap picture dimensions and see what happens?

It's cheap, fast, simple, and it results in a better code.

The only explanation I have found so far, sometimes programmers just don't trust geometry. Not because geometry is inherently hard to understand but simply because the programmers haven't had a chance to know it better.

And that's what I am trying to fix with my book. It's not about learning formulas. It's not about proving theorems. It's not about "doing math" at all, in fact, all the symbolic computations in the book are delegated to SymPy. It's all about understanding. It's about building trust and confidence.

You don't have to remember how to build a cubic spline by heart. Or how to both rotate and scale a triangle mesh in one go. It's all googleable. But you can't google confidence. You can't google that feeling of power, that certainty of the positive outcome. These things only come from getting to know the subject.

Of course, the best way to learn math is to pick an array of university courses and follow them meticulously one after another. A single introductory book is a poor substitute, we all realize that. However, this way of learning is more realistic. No stress, no exams, just relax, pick your pace, and read one page after another until you're done. The understanding is sure to come, and soon after the confidence will follow.

And with this confidence, you're certain to use your tools in the most effective way possible. No messed-up indices, no extra rotations, no hacks and tweaks. You will not become a star mathematician, but you will become a better programmer.

So, if you want to learn a bit of geometry the easy way, buy my book. It's available from the manning site: https://www.manning.com/books/geometry-for-programmers. There is a discount code mlkaleniuk. It's a limited offer, 50% off.

Another bonus is, the book is still in making, so you can even steer the way it goes. There is a discussion forum: https://livebook.manning.com/book/geometry-for-programmers/welcome/v-1/

I will appreciate any comments and propositions.