Closed kbevers closed 6 years ago
Excellent idea wrt getting better test coverage, and yes - the hacky-but-not-kludgy way you suggest could definitely work.
Related, but in a totally other direction, I would like to start a progression toward more clean 4D code, where it makes sense, by making pj_fwd/inv, pj_fwd3d/inv3d aware of the promote/fallback possibilities built into pj_fwd4d/inv4d, and made available through proj_trans(). Ideally, this could reduce the need for 3D and 2D versions of material that generalizes trivially to 4D.
At the moment
gie
always uses the 4D forward and inverse operations if they are available. In many cases that leaves a big chunk of the code untested, for instancePJ_deformation.c
where the tests only touch the initialization and the 4D functions.I would like
gie
to use the 4D functions only when 4D-coordinates are given. Similarly for the 3D and 2D cases. One way of doing that, and still only using the 4D-API, is to nullify the unwantedfwd*
andinv*
pointers of thePJ
struct, which would force the use of a specific mode.