Dear All,
Regarding the wording of the section on computational precision attribute, I
have reservations with respect to the direction it has taken and I suggest we
discuss the matter during our meting this afternoon.
It is essential to the value and usability of the of the _Lossy Compression by
Coordinate Sampling_ to reach a common understanding on this and get the
wording of the new section right.
Here are a couple of thoughts and comments for the further discussion.
@oceandatalab : You wrote:
> The "{...] using 64-bit floating-point arithmetic will reconstitute [...]" in
> the shorter version is misleading from my point of view because it eludes the
> software/hardware factor (though I agree it will not be an issue in most
> cases).
The full sentence
[here](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327*issuecomment-873017814__;Iw!!G2kpM7uM-TzIFchu!mVh75PtEay7PlpX00xbIr2k6SEGL1_Y74IoiSZ-UXj9poMrXgzOOnSnvj4a7nXM2TDZ9PKaVr0c$
) was:
> As an example, a computational_precision = "64" would provide the guidance to
> the data user that using 64-bit floating-point arithmetic will reconstitute
> the coordinates with **an accuracy comparable** to the accuracy intended by
> the data creator.
and I think that with the wording **an accuracy comparable** in the sentence is
reasonable as I wrote it.
@davidhassell: You wrote:
> The accuracy will also depend, however, on how the interpolation method is
> implemented
and
> There are no restrictions on the choice of interpolation method
> implementation, for neither the data creator nor the data user,
I am uncertain about the meaning of this. As I see it, most of what we have
written is aimed at accurately and completely describe both the process of
compressing coordinates and uncompressing coordinates, so what scope do you see
for variations in implementations that would have an effect on the numerical
results of the uncompression process?
If we look at one of the interpolation methods, say the Biquadratic
Interpolation of geographic coordinates method, it will never fully reproduce
the coordinates, unless the the original coordinates were located in a perfect
biquadratic manner, which is typically not the case. This is true even if we
disregard limitations of the floating point arithmetic and differences of the
computing platform. One can think of this as the mathematical performance of
the method, excluding any affects from floating point arithmetic and
differences of the computing platform.
In the VIIRS example we have looked at, this mathematical performance is in the
order of 0.5 m when using 16x16 point size of the interpolation subarea for
VIIRS M-Band.
If we look at the capability of floating-point numbers to represent a position
on a global scale (Earth radius of 6371) then we have that:
- 32-bit floating-point, having 7.22 significant decimal digits, can represent
a global position to a precision of 0.38 m.
- 64-bit 3 floating-point, having 15.95 significant decimal digits, can
represent a global position to a precision of 0.7 10-9 m or 0.7 nano-meter, a
distance comparable to the diameter of our largest atoms.
The floating-point arithmetic operation that constitutes the interpolation
method will contribute to degrading the precision of the reconstituted
coordinates, compared to the precision of the floating point precision itself.
If we say that this degradation of precision is one to two orders of magnitude,
then we have that:
- Applying 32-bit floating-point arithmetic to the VIIRS example, the error
introduced by the floating-point arithmetic operations will be **one to two
orders of magnitude larger** than the pure mathematical performance of the
biquadratic method.
- Applying 64-bit floating-point arithmetic to the VIIRS example, the error
introduced by the floating-point arithmetic operations will be **seven to eight
orders of magnitude smaller** than the pure mathematical performance of the
biquadratic method.
As it can be seen, in this example, applying 32-bit floating-point arithmetic
may noticeably impact results in a negative way, whereas applying 64-bit
floating-point arithmetic will not noticeably impact results, when compared to
the overall mathematical performance of the method.
As I understand it, computing platform variations in floating-point arithmetic
implementations will mainly have the effect of introducing errors/deviations in
the last significant bits of the floating-point numbers. So if the
computational precision is chosen to have sufficient margin with respect to the
mathematical performance (in the example above, this would be 64-bit
floating-point arithmetic) the effect of computing platform variations are
unlikely to be noticeable for a well implemented interpolation method.
Cheers
Anders
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/327*issuecomment-874683926__;Iw!!G2kpM7uM-TzIFchu!mVh75PtEay7PlpX00xbIr2k6SEGL1_Y74IoiSZ-UXj9poMrXgzOOnSnvj4a7nXM2TDZ9IrsMS84$
This list forwards relevant notifications from Github. It is distinct from
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.
