I have some references from when I researched a similiar problem in 310575 . I think the main realisation is any non integer maths in computers, not just Perl is represented as binary fractions. This will cause some imprecision to even basic decimals. I would suggest if this is actual code and not a test case scenario to use 55 for 5.5 and 1 for your increament and when it comes to print it out convert it to a floating point.

This text below is paraphrased from 310615 :
The Perl Man Page says:
Scalars aren't necessarily one thing or another. There's no place to declare a scalar variable to be of type "string", type "number", type "reference", or anything else. Because of the automatic conversion of scalars, operations that return scalars don't need to care (and in fact, cannot care) whether their caller is looking for a string, a number, or a reference.
The int function.
The question is are all numbers floating points and int just changes what is supplied as output? It seems that the number is a floating point as it is passed through out memory into different memory space, it characteristics come with it.
Floating point math
Native Numbers in Perl
Man on Modlib
These are good documents. From Native Numbers in Perl: . Forcing a numeric value to a particular format does not change the number stored in the value. So if any of the decimal values can not be stored as a binary fraction nothing using int will strip that value away and you get the repeating .999999 which when moving between int and float gives you the error.

And there are modules to help, so the game of using maths to do this doesn't work without external help. So there is no bug outside of the limitation of computers as is, which I think we felt when doing this, but it is funny how this conversion under the hood can introduce errors in simple programming.