Really starting to learn that OpenCascade should simply not have had reversible topology as a thing. If the user wants stuff reversed, they can damn well reverse the numbers, because everything seemingly forgets to check if the orientation requires inverting your entire use of the API.
hahaha FML I just fixed trimming to preserve orientation, but the arrow constructor also uses edge trimming as part of its thing.
So, that means that now that the arrow shaft edge is preserving its topological orientation properly, something else is behaving surprisingly because the code wasn't thinking with topologies
How tf did it end up mirrored across the axis though... Oh well, problem for tomorrow dave
To be clear, I am comically unequipped to do anything about this paper, I'm missing a large chunk of a different undergrad education first, at least. But I am enjoying having thoughts like "hmm, this algorithm is annoying because it's discretizing these curves and then trying to make the best of things... But I hear the point of BReps is you can math the shit out of them, I wonder..." and boom, papers. Recent ones even!
Huh, curious. After much fucking around computing a bunch of relative vectors and randomly averaging points about the place... I seem to have arrived at a formula which can compute the exact right answer for the problem, using only fucky approximate sadness as a starting point. Now I need to figure out if I've rediscovered some standard undergrad formula for Voronoi diagrams, or if I just did an AI and just gradient-descended into an extremely brittle solution...
After more pondering I'm pretty sure I've just reinvented iterative root finding of an unknown linear equation, though I'd have to think more about which method this is. Probably a bad one.
Okay one of my clever fixes turns out to not help at all. Yay for tests and proving that changes make a difference!
All my fancy "compare floats properly" stuff results in a change in an intermediate value... that is below the level of precision the CAD kernel considers meaningful.
How much below, you may wonder: the error metric improved by about 1% of one proton's diameter.
Oh wait did I say improved? I meant degraded. I moved the solution 0.01 protons away from the theoretical idea.
Anyway, test your proposed improvement, kids. Tests: they make you feel stupid, and sometimes that's good!
And it did prompt me to reexamine that bit of code again, and find that there is another quick improvement that actually finds the numerically perfect solution in some cases. So that's nice.
Okay much as I'm not enjoying digging through this very extra C++ codebase, every time a function parameter is Standard_True I giggle a little because it implies the existence of Nonstandard_True, and I'm fascinated to find the code that deals with those at some point.
Two reasons common lisp would be great for a cad kernel, actually:
CLOS multimethods are the perfect mechanism to deal with the many cases of "you need a different algorithm for certain pairs of geometry types"
Using dynamic variables and the lack of anything sacred, I can forbid use of floating point equality and ordering unless the dynamic scope has explicitly specified an epsilon appropriate for the operation in progress, and if it has make all operations work in reference to said epsilon.
You could also do cursed shit with the data<>code equivalence, like additional compilation passes to translate readable operations into cursed SIMD, instead of these C++ kernels where the source code for humans has to be the cursed SIMD-friendly structures all of the time, leading to things like having to redefine a separate bool.
Also nobody would use it, which would really cut down on all those pesky users pointing out that the geometry kernel does math wrong.
Me: "Ah, time to enjoy some simple CodeCAD, where if you take care, everything is reasonable"
CAD: "You have found today's Algorithm Surprise API! This object will henceforth have its coordinate system rotated by 180 degrees, but only 50% of the times you click render! Hopefully all your followup operations are rotationally symmetrical!"
Given the shape of the operation, I suspect it's doing an iterative approximation in there somewhere with randomly selected starting conditions, and that perturbs things just enough that at some point the algorithm goes "you know what, this would be much easier if the object were the other way around", and here we are.
hahaha oh no this isn't an operation defined in the CAD library, it's a composite operation defined in the wrapper. I can just taste that I'm going to find a +0.0 vs. -0.0 in there somewhere that makes a later operation engage Australia mode
Based on the "feedback" so far, my next blog post should clearly be titled "POSIX came from Mammon, and did not have a clever reason for that weird thing"
@jahughes Not just narrow screens! Some time in the last few years I learned that justified text is just harder to read in general, because we naturally use the jagged edge of the text to stay aligned correctly when moving from one line to the next. Justified text feels jarring on anything but narrow column print, because the brain is struggling to stay locked onto the correct vertical position!
@danderson What a fabulous blog post! It both dusted off old memories and taught me many new things. Thank you.
Not a correction, but a small addition: if you include Xenix, you don't have to go back quite as far as Unix V5 for process swapping, rather than paging, to be the norm. There were a great many installs of that across industry into the early 90s running on pre 80386 hardware.
Still ancient history, 30 years ago rather than 40.
Wow, meanwhile hugo seems to have defeated Go's fanatical commitment to compatibility. I cannot build the version I was using, because one of the dependencies tries to use cgo, and afaict was using it in one of the ways that was UB and became forbidden at some point. Sigh.
I have written a blog post, something I rarely do.
Unfortunately, since the last time I wrote one, Hugo has apparently become a "framework", the entire config has changed shape, everything throws deprecation errors, and my blog renders as a blank page.
@danderson What I did when I started using Hugo for my site (which is also never updated except once every 3 years), I checked in the hugo binary with it. I can provide a v0.82.0-9D960784 if needed :p
But overall, I've not been impressed by Hugo either - it was surprisingly complex for something which targets, well, simplicity & low tech it seemed.
@danderson
I tell everybody who wants to start a blog to just use a hosted version.
Writing is hard enough, you don't want to deal with some random software every time you publish. @skolima