On Sat, 3 Feb 2024 at 21:17, Thomas Knudsen via PROJ <[email protected]> wrote:
> > stack swap, flip: sorry but my own imperfect brain of a > > programmer not having coded in Forth, I will have a very > > hard time to remember what they do exactly without > > referring to the doc :-) > > But I believe you have programmed in assembly, which is > exactly the same. > > "swap" swaps the top-of-stack with the second-of-stack, > "flip" was Jochen's invention of (essentially) doing a > swap, while behaving as if the operand is the top-of-stack. > I do understand the flip command from Jochen (from his email on 14th Dec). But I do not get "proj=stack flip=3,1" > I do not necessarily find it a stellar idea, but in the use > case presented by Jochem, I acknowledge the elegance. > > Otherwise, these instructions are fundamental computational > paraphernalia and come with the advantage of not having to > invent register names for something living transiently. > > Named registers make sense for cases hand-written by people > with sufficiently deep insight to invent meaningful names > for the registers. > > In the auto-generated case, on the other hand, we will have > to rely on e.g. UUIDs, which certainly does not provide a > nice reading/debugging experience (as you also point out > indirectly in your final comments). > I was thinking about that. How to ensure that an inner step will not use the same register name? But, are those registers only for hand-written pipelines? Do you have in mind any automatic routine using them? In case we go with the named register pattern, I was happy with Even's proposal save/restore into/from. It is easy to understand and clear to invert. > Hence, nice use cases for both register and stack based > approaches. And as the stack based approach (although in an > unfortunate shape) is already part of PROJ, I assumed that > most PROJ users and developers would be familiar with that > way of thinking > > > Why not having 2 separate operations, since (save,into) > > and (restore,from) are mutually exclusive parameters. > > To reduce API sprawl (for a sufficiently abstract notion > of the concept "API"): > > The major part of PROJ operators are simply implementations > of "something out of either Snyder's book or EPSG Guidance > Note 7-2", i.e. something that takes a coordinate as input, > and does some totally step-local thing with it. > > Saving and storing (pushing and popping) operand elements, > on the other hand, are kind of modifiers, that do not do > anything particularly interesting by themselves, but they > modify the response of the next operation, by dragging > in context from potentially many steps away. > > In other words, they break the locality/linear control flow > of the pipeline. So having a special set of top level > operators (proj=stack, proj=reg(ister)) is both a way of > flagging to the reader that "here be dragons", and a way of > encouraging a somewhat more comprehensive and cohesive way > of documenting the bastards, by making them fit under a > common conceptual headline. > Yes, "here be dragons", because there are. If I remember correctly, those push and pop are usually due to the vertical transformations, that could be independent from the horizontal transformation... but they relay on horizontal coordinates. That can be a mess. (I still see some people mixing ellipsoidal height from Polkovo with orthometric heights with an geoid model over GRS80 in a way that seems wrong to me, or at least a big mess. But this another topic). If I understood correctly, you also want to move things from one dimension to the other (from v1 to v3) Does it make sense to exchange X coordinate with Z coordinate? (in the scope of proj inner pipelines, where everything is easting-northing-elev) > You might argue that in that case, it would be preferable > to have just one top level operator for breaking the flow. > I would agree with that, but my imagination was not up to > inventing a sufficiently general concept, without steering > directly back in the mess I was trying to sketch a way out > of :-) > > Finally, let me express my huge appreciation for you taking > time to discuss this. I find it fascinating to observe that > our notions of "what is natural and elegant", and "what is > bolted-on and kludgy" are so different (perhaps even close > to being orthogonal!). It probably mostly underlines the > fact that "communication is difficult", but maybe also that > both approaches may have their advantages > _______________________________________________ > PROJ mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/proj >
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
