[PROJ] Make push and pop FIFO?

[Javier Jimenez Shaw]

On Sat, 3 Feb 2024 at 21:17, Thomas Knudsen via PROJ <proj at lists.osgeo.org>
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
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240204/b927085a/attachment.htm>