Closed oscbyspro closed 17 hours ago
Hm. I kind of want a Fibonacci.Lossy
view to play around with Fallible<Self>
results. All of its algorithms are mul-add-sub based, so it should be well-behaved. It could be fun. Alternatively, I could perhaps expose it as static functions. I'm not sure yet.
The thing is that addition and subtraction are consuming operations and using Fallible<T>
lets you resolve errors by performing the inverse operation instead of defensively copying big integers. It would be lame to hide that capability. At the same time, it must be hidden to some extent because lossy results are not part of the sequence.
Having said that, the above is only relevant for mutating methods that must form a valid state after failure. I could, perhaps, drop those. I doubt a dedicated iterator would use them.
The a + b
and a - b
method really are troublesome, although they are simple enough in the standard sequence. I might drop them in favor of arbitrary starting points, however. We'll see.
Hm. I don't have to track the index either. A sequence pair is enough.
I've been tinkering with an underlying lossy model, since it offers more powerful error-handling and since the proper sequence is easily derived from it. I wonder if removing the index and the parameterized addition is enough to make the layering obsolete? That would be nice. I'll investigate it tomorrow. Zzz.
Hm. I suppose the doubled()
algorithm only works for standard fibonacci sequence pairs, since the growth factor (or whatever you want to call it) comes from the standard sequence. That reduces the arbitrary starting point idea to x + 1
and x - 1
.
I'll take a moment to enjoy the silly things.
Fibonacci<T>
is one of the earliest models, but this library has evolved a lot since its introduction. As a result, I want to rework it in the following ways:8
consuming
andmethodsmutating
throws
withOptional<Self> & Bool
BinaryInteger.fibonacci(_:)
functionsThe 1st point makes it so there's only one way to fail, hence the 3rd. The 2nd point makes it easier to use, and the 3rd point essentially turns it into an iterator without actually turning it into an iterator. The 4th point lets you create an instance from a trusted source, which makes some testing strategies more viable. The the 5th point is partially to ignore errors when only the other element overflows, and partially for discoverability.