User talk:Chemoelectric

Filled shapes of any interest to you?

Hi there. As you've just posted a Bezier curve task, thought I'd be cheeky and ask whether filled shapes, as in complex polygons made from straight lines, arcs, and bezier curves, similar to Cubic_bezier_curves and ideally with anti-aliased edges thrown in, might perhaps pique your interest. If not no worries, but I believe it is quite a challenging little problem, and somewhere around #37 on my to-do/wanted list. --Petelomax (talk) 10:40, 7 June 2023 (UTC)

-- Being by my history a font design guy (half-baked maker of some of the fonts Google Fonts used to get started), most of my interest has been more on the analytic side than on the bitmap side, although I DID do ATS code for a whole bunch of the bitmap tasks, including the Xiaolin Wu task. I cannot stand aliased lines. Filling in, though, is something one DOES need to do for a graphical font editor, or for a renderer, so it COULD happen. If it is a piecewise bézier then the problem of whether it is clockwise or counterclockwise and the problem of what is its inside and what is its outside are related analytic problems, so perhaps could come first. :)

I have extremely little graphics programming in my life, oddly enough. I made fonts, and hacked on editors, but never on the graphical interface. And intersection, also strangely, is something I had programmed before only by the method used in the Maxima--but in C, for quadratics and cubics. It was a complicated adventure involving GNU Multiple Precision and the theory of polynomials. :) In Maxima it is trivial but that is because the interesting bits have already been done for us. --Chemoelectric (talk) 11:46, 7 June 2023 (UTC)

-- Heck, I did the Xiaolin Wu task in a handful of languages, it occurs to me. With little interactive programs for Icon dialects, and graphics sometimes involving some handsome projective geometry for others. Because otherwise boring. LOL.--Chemoelectric (talk) 11:53, 7 June 2023 (UTC)

-- Here is something related I HAVE done in the past that you might find interesting, if I or anyone ever make a task of it: Hobby's algorithm for inferring a piecewise cubic Bézier from on-curve points. As used in MetaFont, MetaPost, and presumably in Asymptote. (I did it with approximate solutions in degenerate cases but that was merely a matter of using IEEE arithmetic and the singular value decomposition, rather than making any effort to be "efficient".) --Chemoelectric (talk) 13:20, 7 June 2023 (UTC)

C23 and what we are likely to see

Today I read secondhand of someone complaining in an ACM trade magazine that C23 is going to continue to specify the comparison of pointers only if they point into the same block of memory. The complaint is that this means the computer can crash and burn.

From an outsider's view, I can guess what they're trying to say: If you have say image1 and image2 (ie any two independent blocks of memory being processed), then it makes perfect sense(/game over should it stop working) to compare two pointers into image1, but no sense whatsoever to compare a pointer into image1 with another into image2 (offsets yes, pointers no). Ideally a fatal compilation error message, but more likely to allow transparently shifting the two blocks about in memory, the result officially becomes "undefined". For sure, some disgustingly grubby code may implicitly rely on declaration order, but if they are upgrading the compiler to squidge a later 8-byte record into a bit of spare space left unused before an earlier defined 16 byte block, that is fair enough, and said junk code deserves to die horribly. --Petelomax (talk) 00:47, 8 June 2023 (UTC)

The standards say sensible things on the matter. I read them carefully, when writing my ATS template version of Timsort. (It takes forever to compile an instance. That is a complicated sort algorithm, which I implemented in a complicated way.) The only thing I can think of that I might like to see is being able to have a pointer to "one less than the start", the way you can have a pointer to "one past the end". But what I believe we are seeing is someone who wants to be able to take any two pointers and know which comes before which in memory. Which is a sensible and possibly useful thing to do -- on an IBM PC, for instance. So it is perfectly reasonable that Borland C for 8086 should let you do that. And it might be reasonable for whatever malloc/free you write for yourself. Suppose you malloc two arrays with this malloc/free of yours and subtract their base pointers from each other: a sensible thing to do, if you have a reason. But this fellow somehow thinks it is a problem that the standard lets ANYTHING happen, if you try the same thing with the system malloc. He complains that it lets the computer catch fire, but what really might happen is a signal interrupt that terminates your program, because you have misused the hardware. I mean, the guy is just wrong, if he thinks the standard should specify something. (BTW I remember when GCC handled #pragma statements by running Adventure. Later they came to their senses, though.) --Chemoelectric (talk) 12:58, 8 June 2023 (UTC)

It is really curious this was published in ACM publication, because that sort of thing is exactly what a computer might do, if you try such a thing. :) Oh, sure, it makes perfect sense to do if you are programming a TRS-80, but another architecture might come to a dead halt. Thus we can count on the C standardizers NEVER to specify comparison between pointers in general.

OTOH now every machine uses 2's complement so THAT can finally be standardized. (Though you could already do portable 2's complement in C -- by using unsigned integers.) Chemoelectric (talk) 20:33, 7 June 2023 (UTC)