Probably it's most important feature for applications like this is that the id's of elements in the equations are stable (meaning, if an X has an id of 123 and a transformation moves it to the other side of the equals sign, it still has id 123... this allows you animate between states if you wish).
There is a mobile game called DragonBox. It sort of tricks you into learning algebra by starting with very abstract manipulations of a puzzle that must follow rules... gradually the game teaches you more and more rules and also strips out the more abstract elements until on the last levels you are finally solving real equations. I loved it, it taught my kids algebra.... and it was just fun.
Over the years I often thought that there should be a calculator for Algebra that works this way... something where you can drag terms around and cancel & distribute with gestures, but most importantly enter your own problems. It should also do more kinds of problems than DragonBox allowed. So I finally decided to build it.
If you'd rather just play with it: there's a limited in-browser demo (real engine, a few example equations, no download) on the landing page — https://dicroce.github.io/wyrm/home.html.
I'd love feedback on the engine design — especially from anyone who's worked on CAS or proof-assistant-adjacent problems. And if you played DragonBox as a kid and wished it went further: this is for you.
Lego blocks are how I like to think about software components... They may not be the perfect shape you need but you can iterate fast. In fact my favorite software development model is just to iterate on your lego blocks until the app you need is some trivial combination of your blocks.
Ok, maybe someone here can clear this up for me. My understanding of B+tree's is that they are good for implementing indexes on disk because the fanout reduces disk seeks... what I don't understand is in memory b+trees... which most of the implementations I find are. What are the advantages of an in memory b+tree?