KPG1_AINBx
Not sure it was a problem in practice, but the change makes sense.
KPG1_ISCLx
> Yes. I thought that. But pragmatism may lead me to go the other way for the
> moment since KPG1_ISCLx is used in many places in KAPPA (and KAPRH) and uses
> the return values from KPG1_MXMNx (which is typed) in places, but ccdpack
> only uses it in one routine (ccd1_prndf) so it would be much less work to
> convert the double to type and back to double again (hoping that rounding
> errors don't bite). I assume I can just add NUM_DTO<T>(LOWVAL) in all the
> calls rather than creating new variables...
This was a routine for scaling for image display, so I don't think
rounding was an issue. Now it's in the public arena, then perhaps a
note could be added warning of the limitation.
Didn't follow the point about subtly different bug fix. The differences
I looked were mostly formatting plus the UPPER & LOWER arguments). I
don't see difference for Peter's 1993 February change. Perhaps I found
the bug and told Peter or vice versa. Don't seem to be to able to
access VMS mail.
KPG1_TDLIx
Whoops! The non-use of FLUX was deliberate initially. For a while time
FLUX was always 1.0D0, until I added the Jacobian calculations and was
confident of the numbers. So FLUX was a token for when it was ready.
Well I did write about 7000 lines of code that month when composing
TRANSFORMER.
Which error message disagrees? Do you mean comparing with KPG1_TRBOx?
KPG1_TRBO
Regarding the error message difference, the CCDPACK code is the same as
my 1995 vintage code. I later corrected the KAPLIBS code.
As to the extra initialisations, it looks like one of those compiler
optimisation warnings or valgrind type changes. I'm not convinced that
it's needed, since the the Kth value is assigned using the K-1th, where
K starts from 2.
Don't we now do transformations with AST anyway?
> All the others seem to be identical.
Remarkable!
Malcolm
|