Homographic strategy overflows

[coolparadox]

When representing a ratio between two Numbers where they differ by a small additive term, in some cases the homographic strategy does not egest until the input exhausts.

This crashes the homographic engine due to overflows if the input contains enough state. A typical example is x/(x+1) when x is a very small positive Number -- say, 1/N where N is the largest available integer.

[coolparadox]

The combine strategy is likely affected by this bug as well.

[coolparadox]

Some investigation about this bug follows. In the following photo, the 2x2 matrixes represent homographic transformations and the parenthesis is the input (where and N is the largest available system unsigned integer value):

Unit tests have been written for the homographic strategy representing these cases, where the failing ones are being #[ignore]'d.

[coolparadox]

The root cause of the state accumulation is the continued logarithm protocol itself. Not much to be done in this area; even if we try to be smart and shift the decision threshold far from the (0, 0.5, 1) range in order to egest sooner, the problem would reallocate in other homographic configurations instead of vanishing.

A more simple and sound approach IMO is to employ big integers to hold the required homographic state, and hope that for the majority of uses the computational impact is acceptable.

[coolparadox]

For the record, I started developing the uintz crate that intends to offer zero-cost abstractions for arbitrary depth unsigned integers.