New xlns16_alt and xlns32_alt algorithms added; xlns16 now compiles on WIN32, macOS or Linux w/o mod

[markgarnold]

I have updated xlns16.cpp and xlns32.cpp to allow a user optionally to replace my 25-year old xlnsadd (which was very efficient back in the day on 80x86) with a new version which is more streamlined for modern architectures. So there are now four choices in both xlns16.cpp and xlns32.cpp:

ideal with original +
non-ideal with original +
ideal with alt +
non-ideal with alt +

These produce slightly different results in certain cases.

In particular, the alt+ does overflow checking so 1e37+3.4e38 produces the max value (close to 3.4e38) rather than wrapping around 1e-39.

If the user does not specify either alt or ideal, the results are the same as the previous 1999 version.

To use, define before the include, as in the example:

#define xlns16_alt #include "xlns16.cpp"

[markgarnold]

I have now added new options xlns16_altopt (for a less accurate variant of LPVIP); omitting xlns16_altopt when xlns16_alt is defined means the LPVIP method is the same as without xlns16_alt, which is the same as LPVIP in the xlns xlnsconf.lpvip_ufunc for Python.

I also added the xlns16_table option for direct lookup on float-to-LNS and LNS-to-float conversion; it also uses tables for addition when xlns16_alt is defined.

On my 2GHz i5 quad core running UBUNTU, default (no xlns16_table) fp-to-LNS conversion (based on fp log and pow) takes 14ns; LNS-to-fp takes 25ns; and add takes 35ns. With xlns16_table, these take 7ns, 3ns, and 14ns. These are still slower than if the computation is done in float (no conversion necessary; fp add takes only 3ns), but doing what is suggested in the LLM GSoC project will be no more than eight times slower than native hardware fp. These estimates were obtained from time16test.cpp. Of course, the speed on other hardware will be different.