okaleniuk

I was considered bad at maths a long time ago, barely passed calculus in college. 20 years later, I wrote Geometry for Programmers.

Maths is a lot of things. Meticulous symbol crunching is one of them. I'm not good at that specific part, I'm constantly ending up with the wrong sign or losing variables doing even the simplest algebra. Luckily, maths is the other things too. For one, I get kicks from inventing things, and maths gives plenty of opportunity for that. I enjoy solving problems, I like experimenting, and there is a lot of that in maths too.

As for the symbolic computations, I acknowledge that there are people who enjoy them too, I'm just not one of these people, so I use a computer-aided algebra system. Makes math fun again: https://wordsandbuttons.online/sympy_makes_math_fun_again.ht...

Be patient... but not it the way you think of.

I started putting things on GitHub in 2012, and as of today, I have 55 repositories there. About 10 of them have releases. Exactly two of these releases are actually used by other people. The other 53 are experiments never has been or never meant to be finished.

However! This year I finished a book called Geometry for Programmers (and I'm proud of it so here's the link: https://www.manning.com/books/geometry-for-programmers). The game my brother and I started in 2009 was a failure sales-wise, but a pair of algorithms from it became a nice addition to chapter 8. The unfinished app that flattens curvy photos I made for my father back in 2013 became chapter 7. The thing that undoes projection I wrote for myself in 2012 - chapter 4.

Patience and persistence required to finish things come with age whether you want it or not. You're probably still at this magical phase of your life where you are allowed and expected to try new things with no tangible gain in sight, and that's great! Enjoy it! It's like planting lots of random seeds not expecting all of them to grow or bear fruit. Don't worry, the time to gather the harvest will come.

Since you want to find the color for every pixel of a flat page, you actually need your mapping the other way around - from a flat page to the photo. Which could be a combination of two: from the flat page to the standard cube, and then - from the standard cube to the photo.

Don't let the word "cube" confuse you, a 2D-cube is just a square.

I have the full explanation right here if you're interested: https://wordsandbuttons.online/biwhatever_transformations.ht...

Calculus on Manifolds by Michael Spivak. http://www.strangebeautiful.com/other-texts/spivak-calc-mani...

For me, the eye opening thing was that any n-dimensional body is a transformation of the n-dimensional standard cube. This brings some mathematical consequences I don't understand, but what's important for me is that equations get much easier for the standard cube transformations because your corners are just ones and zeros.

E. g. I wrote an app that "unbends" a book page from a photo so it looks flat. It can be done with a single but rather large transformation, or with a pair of transformations: to and from the standard cube, and each transformation is then much simpler than their composition. 15 years after I learned that trick and 10 years after I wrote an app, I wrote a book called Geometry for Programmers.

If not for Spivak, I would have drowned in equations, never written the app and would have had nothing to write a book about.

This makes sense. They are different entities and you have to have a way to acknowledge that they are. Breaking strict equality seems a fitting way to do so.

In Geometry for Programmers, I reference a case when an automated test system caught a "zero-not-zero" bug, and I couldn't reproduce it with a unit test until I finally realized that the test system was comparing XMLs not numbers. In print, "-0." and "0." are, of course, different, although in runtime they pretend to be the same.

How about interactive books? Like Immersive Linear Algebra by J. Ström, K. Åström and T. Akenine-Möller; or http://immersivemath.com/ila/index.html or Interactive Linear Algebra by Dan Margalit and Joseph Rabinoff https://textbooks.math.gatech.edu/ila/index.html

I suppose they should work well for self-study, but I never tried learning by one myself.

It's unnecessary complicated for historical reasons. And as history goes further, it only gets more complicated. E.g., due to its promotion rules stemming from the 60s PDP-7, the expression arguments are getting cast into signed type during the operation, 50000 * 50000 == -1794967296. But only on MSVC because, for compatibility reasons, MSVC still keeps its `int` type 32-bit while, for instance, clang doesn't, so on clang, the same expression will give you the correct 2500000000. Imagine writing the code, running all the tests and only discovering the issue on one of the CI build machines with no proper way to debug it. Yeah...

And this is totally by the book, the size of 'int' is allowed to deviate from compiler to compiler by design. This comes from the 70s C that was suppose to become "portable assembly" and back then, apparently, portability meant compiling without errors. So C++ addresses this issue and proposes types with fixed length. You can now write your types explicitly. Like this: uint64_t(uint16_t(50000) * uint16_t(50000))

And get 18446744071914584320. Because, nevertheless the new fancy types, the promotion rules from PDP-7 still apply. Your expression is getting cast to the next signed standard type that can accommodate `uint16_t` and this is still `int`. So you get -1794967296 and only then convert it to unsigned `uint64_t` number.

Fiddly bits and surprises will keep on coming.

I've been writing in C++ for, what, 17 years now?, just yesterday I was rewriting a unit test with floating point data into integers. It was something like this: "1.234, 0.123, 5.678" and I wanted "1234, 123, 5678". So I just removed the decimal points and let the heading zero in 0123 hang. 0ops! In C++, heading zero marks octal notation, and 0123 actually means 83.

But the thing responsible for the most rants is C++ static polymorphism. Since you don't have Rust-like type traits, the only way to ensure that one piece of code will work with another is to compile them both together. This means that for every minor change in an underlying library, you have to recompile all the dependies to see if their tests still work and this gives you enough time to write a rant or two.

I agree on yes and no. If notation mattered little, there would not be that many different notations. Leibniz and Lagrange notations for derivatives, Einstein abbreviation for sums, Iverson notation for tensors that later became APL, or any language for any computer algebra system ever. If notation mattered little, inventing your own notation would matter little too.

But if notation mattered a lot then... there would not be that many different notations either. There would be one and only notation that works and no one would dare to divert from it.

Math notation is a cultural artifact with its own significance pretty much like SQL or x86 assembly language indeed.

I thought so too. When I started Geometry for Programmers, I was going to write all the formulas as SymPy snippets. I thought that was a brilliant idea because, yes, normally programmers are much more comfortable with code rather than with math notation, and math is not about notation anyway. Case in point, you can turn any SymPy expression into LaTeX with the `latex()` function. It doesn't make the expression any more mathematical, so the other way should apply just as well, right?

But the very first review shown that I was wrong. Very few people saw this as a good idea. Most wanted both formulas and code. Apparently, there is a certain "comfortable" level of math language in a math book readers do not wish to give up.

I stepped in as a project manager for my R&D group when the war started. I wasn't going to but we had nobody else at the moment so here I am. One of the perks of this arrangement is that I basically can do whatever I want. Worse case scenario - I'm back to my engineering job I wasn't going to leave to begin with.

So the first thing I did when I stepped in is I made estimations paid. As a business partner, you can request an estimation for a feature, but an estimation itself then becomes a project. Alternatively, you can just tell me your deadline and we'll manage things on our side to fit your date. Do you know how many times did we do the "estimation as a project"? Once. And their project got cancelled anyway so we didn't even have to do the actual work and nobody knows if our estimate was accurate.

I've heard many times that business needs estimations. As it turns out, it doesn't. In times of inherent unpredictability, the real priorities show. All that business needs is to be better than competitors. It needs to create marketable value. It needs ideas, it needs analysis, it needs expertise and hard work. Estimations don't help create value. They only create more work. As soon as you make this work visible, poof - nobody wants estimations anymore!

Sorry, I should have been more clear. Independent validation and verification is a thing: https://csrc.nist.gov/glossary/term/independent_verification.... We still use it in, for instance, NPP automation, avionics, and defense. Which not only makes sense but usually required by law. Interestingly, outside these few domains, we usually omit it as too costly as if doing the first and only independent validation with our own users is not.

Literally independent validation and verification. https://csrc.nist.gov/glossary/term/independent_verification...

In some domains, doing IV&V to see how well your software really works is required by regulations, in others... we just guess.

What baffles me is that everyone talks about software quality but very little organization actually measure their software quality. Not just some made up metrics but exactly how well the software meets its requirements.

And not that we don't know how. For any ML model, we have a validation data set and it is imperative that we measure how well a model performs on this data set and not the training data set. We know that without a validation, a machine will overfit its model into the data it has. Programmers... do the same thing. We're very good at passing tests and, unless we have a separate independent validation and verification process, we convince ourselves that green tests = quality. So our tests are always green but our backlogs are always red. And nobody seems to notice the contradiction.

My father was an amateur historian. He used to work with a lot of pictures often of poor quality. I guess his worst was a photo of a road sign printed in a book sometime in the 70s, and then recently not even scanned but taken from a book page with a phone. So I made a tool for him that allows to undo unwanted bending and also helps with the dirt: https://github.com/akalenuk/unpager

Ah yes, but the whole point of the project is to go away from this:

    ldstr "Hello!"
    call void [mscorlib]System.Console::Write (string)

And come to that:

    ((write: "Hello!"))

So `ldstr` does indeed feature in the example but only as a "before" picture.

But you're right, it is about adding syntactic features to the existing language.

I added a note saying that if you pick one of the answers an explanation will appear. Thanks for the feedback!

Fixed! Every expandable text can now be toggled back. Thanks for bringing this up!

Done! All the expandables have background colors now. https://github.com/akalenuk/wordsandbuttons/commit/22ef6295c... Thanks for the idea!

Yes. But you will have to disassembly the AI to see if it does this correctly :-P

I tried to make a readable assembly once: https://github.com/akalenuk/milasm

But apparently, this is not a win-win, but a lose-lose since this notation is hated by both assembly programmers and not assembly programmers :-D

Good point! I'll think what I can do.

Yes, I did the foldable thingies in https://wordsandbuttons.online/programmers_guide_to_polynomi... and https://wordsandbuttons.online/if_i_were_to_invent_a_program...

But not on this page. I thought that the arrows are a bit noisy. I can still add this "toggle back" feature here if you want.

Background colors are a great idea, I'll do that!

Very indirectly. My https://wordsandbuttons.online/ helped me cement a publishing deal with Manning, and the book I wrote for them (https://www.manning.com/books/geometry-for-programmers) works as a hourly rate magnifier in contract work negotiations.

Oh, and I have a free explanation too: https://wordsandbuttons.online/sympy_makes_math_fun_again.ht...

This is a fascinating topic indeed. And the math behind polynomial approximation is not that deep or unapproachable. You just haven't found an explanation that works for you. Some time ago I tried to make one with a sine as an example: https://wordsandbuttons.online/sympy_makes_math_fun_again.ht...

It doesn't mention Taylor series anywhere but if you only make your system out of N differential equations, you'll get N members of the power series.

I love these things! Approximation is art.

I have a similar example in my book Geometry for Programmers (https://www.manning.com/books/geometry-for-programmers). There I make a polynomial approximation for sine that is: 1) odd (meaning antisymmetric); 2) precise at 0 and Pi/2 (and -Pi/2 automatically); 3) have precise derivatives and 0 and Pi/2 (and -Pi/2); 4) have better overall precision than the equivalent approximation with Taylor series; and it only consists of 4 members! Adding more members makes it impractical in the modern world since we have hardware implementations for sine on CPUs and GPUs.

Spoiler alert, the secret sauce is the integral equation ;-)

Also, there is a faster Python which is also Python. And the author considered it as well (both PyPy and Numba), it's just in this particular scenario they were not the best way to go.

Good for you! You did everything right: measure always, fix the bottleneck if possible, rewrite if necessary.

A little tip, you don't have to compare actual distances, you can compare squared distances just as well. Then in `norm < max_dist`, you don't have to do a `sqrt()` for every `norm`. Saves a few CPU ticks as well.

I once rewrote a GDI+ point transformation routine in pure C# and got 200x speedup just because the routine was riddled with needless virtual constructors, copying type conversions, and something called CreateInstanceSlow. Ten years after, I gathered a few of these anecdotes and wrote the Geometry for Programmers book (https://www.manning.com/books/geometry-for-programmers) with its main message: when you know geometry behind your tools, you can either use them efficiently, or rewrite them completely.

For young people, I would recommend learning languages they would probably never use in production. APL, Forth, Prolog, Scheme, and one or few variants of Assembly. Unlike modern mainstream languages, these really expand your thinking vocabulary.

And the practical reason why I'd recommend learning these now: you'll never have time to play with them when you're not young anymore. The whole domain of knowledge they represent will forever remain a missed opportunity.

In my book Geometry for Programmers (https://www.manning.com/books/geometry-for-programmers), I also advocate investing in mathematical education and a computer algebra system. Any system. I propose SymPy but it's only because it's free and ridiculously simple to get started with.

The reason for this is also simple. Mathematical knowledge is non-perishable. ChatGPT can write boilerplate for you, and it any language too. But to solve a real-world problem with math, you need a computer algebra system to solve your equations, and your own head to compose these equations. That's something beyond the reach of LLMs.