<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 3 Feb 2024 at 21:17, Thomas Knudsen via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">> stack swap, flip: sorry but my own imperfect brain of a<br>> programmer not having coded in Forth, I will have a very<br>> hard time to remember what they do exactly without<br>> referring to the doc :-)<br><br>But I believe you have programmed in assembly, which is<br>exactly the same.<br><br>"swap" swaps the top-of-stack with the second-of-stack,<br>"flip" was Jochen's invention of (essentially) doing a<br>swap, while behaving as if the operand is the top-of-stack.<br></div></blockquote><div><br></div><div>I do understand the flip command from Jochen (from his email on 14th Dec). But I do not get <span class="gmail-im">"proj=stack flip=3,1"</span></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>I do not necessarily find it a stellar idea, but in the use<br>case presented by Jochem, I acknowledge the elegance.<br><br>Otherwise, these instructions are fundamental computational<br>paraphernalia and come with the advantage of not having to<br>invent register names for something living transiently.<br><br>Named registers make sense for cases hand-written by people<br>with sufficiently deep insight to invent meaningful names<br>for the registers.<br><br>In the auto-generated case, on the other hand, we will have<br>to rely on e.g. UUIDs, which certainly does not provide a<br>nice reading/debugging experience (as you also point out<br>indirectly in your final comments).<br></div></blockquote><div> </div><div>I was thinking about that. How to ensure that an inner step will not use the same register name?</div><div>But, are those registers only for hand-written pipelines? Do you have in mind any automatic routine using them?</div><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Hence, nice use cases for both register and stack based<br>approaches. And as the stack based approach (although in an<br>unfortunate shape) is already part of PROJ, I assumed that<br>most PROJ users and developers would be familiar with that<br>way of thinking<br><br>> Why not having 2 separate operations, since (save,into)<br>> and (restore,from) are mutually exclusive parameters.<br><br>To reduce API sprawl (for a sufficiently abstract notion<br>of the concept "API"):<br><br>The major part of PROJ operators are simply implementations<br>of "something out of either Snyder's book or EPSG Guidance<br>Note 7-2", i.e. something that takes a coordinate as input,<br>and does some totally step-local thing with it.<br><br>Saving and storing (pushing and popping) operand elements,<br>on the other hand, are kind of modifiers, that do not do<br>anything particularly interesting by themselves, but they<br>modify the response of the next operation, by dragging<br>in context from potentially many steps away.<br><br>In other words, they break the locality/linear control flow<br>of the pipeline. So having a special set of top level<br>operators (proj=stack, proj=reg(ister)) is both a way of<br>flagging to the reader that "here be dragons", and a way of<br>encouraging a somewhat more comprehensive and cohesive way<br>of documenting the bastards, by making them fit under a<br>common conceptual headline.<br></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>You might argue that in that case, it would be preferable<br>to have just one top level operator for breaking the flow.<br>I would agree with that, but my imagination was not up to<br>inventing a sufficiently general concept, without steering<br>directly back in the mess I was trying to sketch a way out<br>of :-)<br><br>Finally, let me express my huge appreciation for you taking<br>time to discuss this. I find it fascinating to observe that<br>our notions of "what is natural and elegant", and "what is<br>bolted-on and kludgy" are so different (perhaps even close<br>to being orthogonal!). It probably mostly underlines the<br>fact that "communication is difficult", but maybe also that<br>both approaches may have their advantages<br></div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div></div>