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)

I suffer from a severe case of obsessive-compulsive disorder and it keeps irritating me that I did not mention this, but I did reason out why one simply cannot have "what I might like to see" that I mentioned above. It is because then you would have at least these two problems: (1) the "one less than" pointer might be the NULL pointer, and (2) the "one less than" pointer might actually wrap around. Standards are very subtle things that many do not appreciate appropriately. (But Fortran standards are written in Martian. This is a problem IMO.) --Chemoelectric (talk) 13:01, 12 June 2023 (UTC)

"Bad" code I have seen on RC includes stuff that violates alignment rules. This is a habit programmers for Intel/AMD architectures get into, because the "implementation defined" behavior of a compiler is generally to just generate the code to do it, and on Intel/AMD you can store/fetch on unaligned boundaries. But on, say, PowerPC, you cannot. You will get a bus error. Standards simply should not specify "this must work." --Chemoelectric (talk) 13:06, 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)

A good language for expressing algorithms

I am trying to decide on a good procedural language for expressing algorithms in 2023. By that I certainly mean one of the Algol 60 derivatives, because no other line of languages has achieved such plain, utter readability. But Algol 60 itself (though in the 1970s it was given I/O) suffers from lack of some types, has call by name which is now obscure, has loop syntax that can be used plainly but also can be used strangely, etc. -- and has no actual code entry syntax at all! Algol W I do not know and perhaps is too obscure. I have no compiler for it, at least right now. Algol 68 is not Algol and has too many features to serve the purpose. Ada would be ideal except that it has too many features and too big a set of libraries for the role.

So I end up with Pascal, Modula-2, and Oberon-2. Modula-2 and Oberon-2 have weird uppercase-lowercase conventions that give me serious problems with hand disability, even though I am using a special device. Also the Oxford Oberon Compiler is non-spec, even in my tiny little experience. For me it did integer division with truncation towards zero, whereas the spec says floor division. (So somewhere on Rosetta Code I think I have Oberon routines to do integer division with never-negative remainder, which usually ends up the same as floor division.) Modula-2 has a plethora of different "standards" and libraries, even between different editions of Wirth's book. I end up using the ISO version, simply because it is the best documented; but it is also probably the least used! And Wirth calls an integer type "CARDINAL" that used primarily for ordinals! It is a categorical mistake to name an integer type for a usage rather than for its obvious properties.

So I end up with ISO Pascal, or even less than that, if possible. This has various advantages. It does not have a module system, for example, which means we do not have that distraction. Unlike Algol 60, it has a sensible way to add comments. It has call by reference, instead of call by name. Unfortunately it has an explicit way to write things that are referenced through pointers, rather than the more implicit way that Oberon has. So one has to explain why you are writing "^." instead of just "." But I cannot think of a better choice than Pascal. There is a good compiler for POSIX systems and for Windows systems I don't know what but you can pay for Delphi for all I care. :) I programmed in Borland Pascal for pay but that was 30 years ago. --Chemoelectric (talk) 13:43, 12 June 2023 (UTC)

Postscript: I did try ATS for the job and found it oddly good at it. It could get even better with a few #define statements, for instance maybe "#define variable var" and "#define value val", so the code ends up looking almost like English. But I fear ending up in situations where you have to do something ATS-ish -- because mutable variables are, by their very nature, linear types, and so (in ATS) must have local scope. --Chemoelectric (talk) 13:49, 12 June 2023 (UTC)

And you will certainly end up having to do type conversions, though one can introduce explicit conversions instead of using the usual obscure conversions that rely on type inference. --Chemoelectric (talk) 14:13, 12 June 2023 (UTC)