[PROJ] Make push and pop FIFO?

[Even Rouault]

push & pop are still OK for my mental representation. Exch becomes more 
hard to comprehend. Even if end-of-sixties & seventies' style of 
computer science did work fine and was very compact, we can probably 
afford to spend a few more bytes nowadays and be explicit with naming, 
and offer separate branches for forward & reverse paths in cases like 
Jochem's where things get complicated.  The lookup by name for 
save/restore should only be needed in the instanciation phase of the 
pipeline, and ultimately the save/restore PJ* instance would just hold 
an integer index into an array of PROJ_COORD stored in the pipeline. 
During its execution (proj_trans()), it should thus be very fast.

Agreed that your '|' pipeline syntax is even better.

Le 17/12/2023 à 14:25, Thomas Knudsen a écrit :
> Contrary to you, Even, I find the push/pop duality clear,
> non-confusing, and totally in line with the overall
> design of PROJ operators. I would, however, for even more
> consistency, have preferred a single stack design
>
> Why do I find it so clear? Four reasons:
>
> 1. The opposite of "proj=utm" is "proj=utm inv"
> 2. When a pipeline is executed in reverse,
>     "proj=utm" maps to "proj=utm inv", and v.v.
> 3. The opposite of push is pop
> 4. When a pipeline is executed in reverse,
>     "proj=push" maps to "proj=push inv", i.e. "proj=pop",
>     and v.v.
>
> This is clear, systematical and symmetrical - nothing
> strange going on here.
>
> If we had a "proj=swap" operator, it would map to itself
> when executed in reverse. That may be slightly strange,
> but not any more strange than any other mathematical
> involutions (e.g. negation, reciprocation, and the identity
> operator)
>
> Using named registers, on the other hand, introduces a
> non-systematic element, and requires one to invent
> arbitrary names for each register.
>
> While these names may be "meaningful" for the pipeline
> implementer, they may very well be meaningless for
> anyone else.
>
> Also, these registers (=variables) will probably need
> to be stored in a dictionary (std::map or somesuch),
> and imply an extra lookup for each individual operand.
>
> In Rust Geodesy [1,2,3], I wouldn't care, since the operators
> operate on full arrays of operands, i.e. "coordinate sets",
> in ISO/OGC lingo, so the lookup is amortized over a large
> number of operands, but in PROJ, we actively execute each
> step in the pipeline for each individual operand.
>
> Anyway - the lookup may, in practice, be
> negligible, compared to all the other things we do
> behind the curtains, when executing a pipeline.
>
> But I believe we could clarify and streamline the push/pop
> pair by taking inspiration from "proj=axisswap order=...."
> in a new implementation or variation, using only one stack,
> such that:
>
> proj=pipeline step proj=push order=1,2,3,4 step proj=pop order=4,3,2,1
>
> would implement the no-op, while
>
> proj=pipeline step proj=push order=1,2 step proj=pop order=1,2
>
> would be equivalent to
>
> proj=axisswap order=2,1
>
> As the "order=..." option is disjoint to the set of flags,
> "v_1, v_2, v_3, v_4", the new "single-stack syntax" is
> easy to discern from the old "four stack syntax".
> Also, it would be trivial to implement the enqueue/dequeue
> functionality Jochem needs.
>
> As an aside, in Rust Geodesy (RG), I have been
> experimenting with a less verbose syntax, which does away
> with the "step" and the "proj=" qualifiers.
>
> "step" goes, because it really just signifies the
> equivalence of a Unix style pipe connection, which is
> expressed more compact and clearly with the vertical bar
> "|" syntax also used in Windows and Unix shell commands.
>
> "proj=" goes because it really is a rather misleading term:
> It made sense, back when PROJ was purely a projection library,
> but for now, where it may introduce any kind of operation,
> not just a proj=ection.
>
> Hence, the previous pipeline:
>
> proj=pipeline step proj=push order=1,2 step proj=pop order=1,2
>
> maps to
>
>      push order=1,2 | pop order=1,2
>
> which is significantly more clear and significantly less
> verbose, in my humble opinion. And it can be trivially
> transformed back to classic PROJ syntax by prefixing by
> "proj=pipeline step proj=" and substituting "|" with
> "step proj=".
>
> Also, it can live alongside the classic PROJ syntax, since
> if neither "proj=" nor "init=" is found in the operator
> descriptor, then it must be "RG syntax".
>
> I personally find this syntax handy. In a longer time
> perspective, I would like to add support for it in
> PROJ (just as I have added support for classic PROJ
> syntax in RG). So whatever happens to PROJ syntax, I
> would be sad to see it diverge too far and lose the
> trivial transformation to/from RG syntax: I truly
> believe that RG syntax is both easier to teach newbies,
> and easier to write for greybeards, so I think it has
> some potential, also outside of RG.
>
> [1] Rust Geodesy: https://github.com/busstoptaktik/geodesy
> [2] Overall architecture and philosophy,
> https://github.com/busstoptaktik/geodesy/blob/main/ruminations/000-rumination.md
> [3] Geodesy from a PROJ perspective,
> https://github.com/busstoptaktik/geodesy/blob/main/ruminations/008-rumination.md

-- 
http://www.spatialys.com
My software is free, but my time generally not.