Re: [lmi] Converting numbers in mortality tables to and from text

[Vadim Zeitlin]

On Fri, 18 Mar 2016 01:37:27 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-03-18 00:56, Vadim Zeitlin wrote:
GC> [...big snip...]
GC> >  Do you see some other way to avoid this problem that I'm missing?
GC> 
GC> No.
GC> 
GC> > Or are we ready to live with the current behaviour?
GC> 
GC> Yes.

 Great, thanks for confirming this!

GC> But I don't suppose any tables have a decimal-digits value of fifteen
GC> or more--they're probably no more than eight

 I mentioned it only in passing in the previous message, but I see a few
(6 to be precise) tables using 9 decimal digits, all in qx_ann database and
all for Chile mortality data (tables 845 to 850). But this is the (local)
maximum.


GC> IOW, we treat table data as fixed-point decimal values, because
GC> that's what they were in the original print publications.

 This makes me wonder if I should be actually using "double"s for their
internal representation at all. I originally did it without thinking much
about it just because this is how they're represented in the binary SOA
files, but now that I do think about it, it seems that representing them as
an integer would work better. If I used the (same sized as double) uint64_t
for this, we would have at least 19 significant digits and even accounting
for 2[*] of them before the decimal point, this would still give us more
than enough precision. I'm not sure if it's worth changing it now that the
code using doubles had been already written, but I think it is because it
would ensure that comparing two tables would work as expected, whereas now
I have to compare their textual forms because of this 1 ULP mismatch.

 So unless you see some big problem with doing it like this or tell me to
not spend time on it, I'll replace doubles with uint64_t in the final
version of the patch -- please let me know if I shouldn't.

 Thanks,
VZ

[*] There can't be any more because it would break the textual format
    representation then by making the columns run together. And in practice
    there only seems to ever be 1 anyhow.