Re: [lmi] bourn_cast version 1.0

[Greg Chicares]

On 2017-04-19 14:16, Vadim Zeitlin wrote:
> On Wed, 19 Apr 2017 13:59:55 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> But our official goal is to keep lmi running for the next forty years,
> 
>  Wait, have I missed another end-of-world event scheduled for 2058? If not,

"Forty years" is just a way of saying "forever", or at least for the lifetime
of the youngest person whose insurance policy requires an illustration (though
we're still issuing policies to twenty-year-olds today). The only way to make
code work for forty years is to write it to last forever anyway.

It would make sense to give a moment's thought now to what computers will
look like forty years hence. I think the registers will still be 64 bits wide
(otherwise, I'd have emulated a 128-bit integral type for bourn_cast testing;
but 2^64 is 16 exbibytes, and we won't have that amount of RAM by mid-century).
32-bit code will have only legacy support, so we'll want to build a 64-bit lmi.
I think GNU/Linux will still be widely used--either that, or BSD, so it would
not hurt if we paid some attention to BSD compatibility (which I guess would
affect only makefiles). With less certainty, I foresee that gcc and C++ will
still be in broad use. CPUs will run at about the same clock rate as today,
but they'll have many cores, so perhaps we should consider threading in lmi.

> I do hope it can continue running in 2058 and beyond... although I'm not
> sure if we're not going to have some problems at the half point between now
> and then (lmi doesn't use time_t much, but I'm not sure if wxWidgets, for
> example, is fully y2038-compliant).

If we leave the 32-bit world behind, and run 64-bit lmi on a 64-bit OS, then
won't that solve this problem automatically? (At least for *nix, because I
don't see msw surviving until Y2038.) By the time we need a 128-bit time_t,
we'll be in a galaxy that hasn't been born yet.

> GC> This is a good time to compare the performance of bourn_cast versus
> GC> boost::numeric_cast. Here are median-of-three timings with gcc-4.9 on
> GC> i686:
> 
>  I have some trouble reading this table as it has "boost" and "bourn"
> columns, but also "static" and "bourn" rows. What exactly is found at the
> intersection of the "bourn" row and "boost" column?

I should have edited that. The rows might have been labeled "bo.*cast" to
suggest either "bourn_cast" or "boost::numeric_cast", thus:

                      ---boost--- ---bourn--- -ratio-
  static_cast<U>(S):     319266      317606      99%
    bo.*_cast<U>(S):     317838      316214      99%

where "317838" is the number of nanoseconds for boost::numeric_cast to
convert an integer from signed to unsigned.

> GC> This work also gave me reason to study IEEE 754, which I had never read
> 
>  I admit that I haven't read it neither. You should leave your review of it
> at 
> http://www.worldcat.org/title/ieee-standard-for-floating-point-arithmetic/oclc/259731234
> as it doesn't seem to have any, for some reason -- maybe this will motivate
> me to do it.

Wow--that's like a curated search engine: DMOZ meets gopher in the 21st
century. Of course, their TOS are unacceptable:

https://www.worldcat.org/account/?page=register
| You agree to defend OCLC against claims or lawsuits related to your posting.

because frivolous lawsuits abound. If I were to review it nonetheless, then
in the spirit of the times I suppose I would say "IEEE 754 rocks my world,
and props to Kahan".