This one is trivial.

For testing my timezone code, I often need to recurse through all the directories where the Zoneinfo binary files are.  I got tired of rewriting the programs depending on whether I was testing on Linux or Windows, so I decided to write a little framework that would be portable to both operating systems.  It doesn’t solve all the problems (the two systems provide different information about directory entries), but at least I don’t have to completely restructure the main loops. 😎

There are no new ideas here:  how to loop through directories is really old news; and since it’s not particularly original on my part, all the code is in the public domain.

I’ve been rather lackadaisical about fixing my “big number” classes, but I’ve finally gotten up off the couch, and I have new versions available.

I’ve changed the names of the bigint and bigdec classes to integer and decimal, respectively, because I thought the “big…” names smelled of Java.  I also wrote a small Web page that ties the three classes together.

In a comment to a previous post, Andrew Dalke suggested some additional values I could test; and, sure enough, I found a bug (thanks).  (The bug was actually in what’s now called the integer class:  I hadn’t guarded against aliasing of the operands to expressions like x *= x.)

I think I remember someone suggesting that some users might prefer classes with “more features”.  What additional features did you have in mind?  Don’t suggest trig. functions and the like:  I’ve limited the <cmath>-like functions that take decimal and rational arguments to those that return exact values.  (You might be able to talk me into square root, but that would be successive approximation using Newton’s method which is what I know how to write.  I already have a version of the rational class that has quiet NaNs and infinities and a spaceship operator, but I’m not sure I like it.)

As I’ve said before, these classes are not intended for serious numerical work; and numerics experts probably already know where to find better implementations, or could write such themselves.

Update, 2024-02-05:  I woke up this morning having in my mind a way to make rational comparisons a bit quicker, so I made that change.  I also noticed that I had failed to remove an isinf() test of the accuracy argument to the conversion from floating point values.  (In the previous version, passing a NaN for the accuracy would trigger an exact conversion using std::frexp().  In the current version, any non-finite accuracy will do that.)

By the way, if anybody out there has access to a C++ implementation where FLT_RADIX != 2, I’d appreciate a test of the frexp() business.  I have access only to boxes where FLT_RADIX is 2.

Andrew Dalke did a few tests of my rational number library (thanks) and I thought it deserved a post of its own.

The first links to code in the function float_as_integer_ratio_impl(), which is the C implementation of the Python method as_integer_ratio() …

OK, I found it.  Yeah, I tried to use frexp(); but I tried to do some bit twidling to get the mastissa bits as an integer and that was a big mistake.  It’s easy once you know how to do it. 😎

I’ll add something like this to my rational class; but I’m not sure yet whether I want to make it only for FLT_RADIX == 2 and whether I want to allow the user to do something less than an exact conversion, falling back on the continued fractions routine if I need to.

I wrote a quick and dirty program to do the tests mentioned in the comment and compiled it:

– for Windows using an ancient Microsoft compiler which doesn’t conform even to C++11 (although it has rvalue references and type traits templates which is enough for it to get through my bignum stuff), and with a long double that’s just a double.

– for Linux using a somewhat more up-to-date GCC (C++14 at least), and with a bigger long double.

I got two different sets of results (Windows, Linux), possibly due to differences in the long double format.

– The Windows version had no trouble with either 0.0869406496067503 or 1.1100695288645402e-29, but it failed on 0.9999999999999999.

– The Linux version failed on both 0.0869406496067503 and 1.1100695288645402e-29, but it worked on 0.9999999999999999.

– Both failed on nextafter(1,0).

… 1.1100695288645402e-29 gives a “Can’t convert NaNs or infinities to bigint” because the
val0 = 1.0 / (val0 – static_cast(int0)); step results in an inf.

(That should be static_cast<long double>(int0)…either WordPress or the browser itself thought that the <long double> was an unrecognized HTML tag.)

My Linux version reports that as well.  That’s a bug in my code which I’ll have to figure out if I decide to keep the continued fractions around for support of either FLT_RADIX != 2 or inexact conversions.

I urge you to look towards an existing library if all you need is SQL interoperability.

Actually, what I need is to keep my mind active in my retirement. 😎

There are some third-party database access libraries out there; but they look to me like they were written by teenagers sitting in their basements going, “Cool!”; and I’m not sure that they scale up to real-world applications.  For example, there’s one called SOCI that actually tries to make database tables act like iostreams.

Also, I think I can make my library act like a Web service client as well, and maybe even access the cloud.  We’ll see…

I finally got up off the couch and finished testing the my rational number; and I decided to put that along with the unbounded integer and big decimal code into a single library.  If you’re interested, see https://www.cstdbill.com/bignum/bignum.html.