< up >
2025-10-09

explore Float::INFINITY

I was looking for an approach letting a client endlessly reconnect. The reconnect option just accepts numbers >=0. The naive idea was to set it to an arbitrarily high number, but how many reconnects are enough?

Ruby has a concept for that: Float::INFINITY. The client doesn’t need to know this concept in order to work with it. The attempt count just got compared to the given value and any number is lower than infinity. In fact, adding and subtracting is also implemented.

Some further experiments:

irb(main):001> ∞ = Float::INFINITY
=> Infinity
irb(main):002> ∞ - ∞
=> NaN
irb(main):003> ∞ + ∞
=> Infinity
irb(main):004> ∞ * ∞
=> Infinity
irb(main):005> ∞ / ∞
=> NaN
irb(main):006> ∞ * 0
=> NaN
irb(main):007> ∞ / 0
=> Infinity
irb(main):008> 0 / ∞
=> 0.0

to_i issue

If ruby clients like redis apply to_i onto the given value, our approach raises an exception as infinity is not a valid integer…

As I’ve lost my idealism over the past years to get more practical, we just can use the maximal possible positive integer 4611686018427387903¹. The calculation from this SO answer goes like this:

.- every binary digit can have (as the word binary implies) two states: 0 and 1. base ** digits is the general formula to calculate
|  the maximal possible decimal number with a defined base (10,2,8,16, you name it) and digits. Note that the digits is the count of
|  the digits within the base.
|
|     .- the maximum bitwidth of the local architecture, mostly 64-bit nowadays
|     |       
|     |          .- one signed bit (as usual for signed ints) and one internal bit so ruby knows its either a pointer or object 
|     |          |
|     |          |    .- '0' itself belongs to count of possible numbers, so the highest number must be 1 less
|     |          |    |
v     v          v    v
2 ** (bitwidth - 2) - 1 =
2 ** (bytewidth * 8 - 2) - 1 =
2 ** (0.size * 8 - 2) -1 =
4_611_686_018_427_387_903

why this approach is bad in general

Assuming numbers should be last resort as they age badly. E.g. if the timeouts gets set to zero and the future CPU has the power, then that amount of retries might be reached faster than you thought in the first place.

My advice is to add a // TODO comment to tell your future self why you did this. You’ll thank me debugging the next major outage that leads you to some magical numbers (those are basically the definition of assumed numbers).

+hf