David,
Chill. You will, if you're going camping. (-:
I wasn't advocating that the factoring had to be done as a priority, but
that it should be done in the move to CVS/autoconf, while we're on top
of it and aware of the various interrelations, and *where it's not a big
job*. It was a flag to remind us, just like my remark about the
miscellaneous documents.
> Classic stuff is "not being developed" any longer - so why is making
> CCDPACK stats routines more generally available an important issue? It
> works, and can be maintained, as it is.
Well Dave said that for some processing I could still write a KAPPA
application, if that was going to be the path of least resistance. We're
not creating Java versions of KAPPA etc. as originally envisaged in the
"Future Directions" document. If there is a gap, say needed for
ORAC-DR, some flexibility makes sense.
As ever in programming I'm trying to think of the next person who has to
look at the code. If the stats code could be made generic, it might be
advantageous to those in the community wanting to continue with Fortran.
As Tim pointed out people are still using Figaro where the KAPPA
alternative has been much superior for a decade. If there's a bug it
might only get fixed in one set of routines. David, you're making more
import of this than was intended. If it's a simple job, it's worth
doing. If it requires major surgery, it's best to leave it. I only
asked what the current state of the versions were.
> In fact grepping for "DSB" in kappa/ccdpack/*.f shows that 16 history
> changes, including for instance new routine arguments, and a new
> combination method.
Sorry I missed ccdpack/. I must have been looking for a tla/.
Malcolm
|