And how do I calculate the value of this "epsilon" that is being mentioned

As sectokia's first post indicated, Machine::Epsilon provides machine_epsilon(). It is dependent on the $Config{doublesize}, but for 64-bit, the value that sectokia quoted is the value. It is the maximum error, relative to the appropriate power of two.

The value of that is the same as ulp(1) (from my Data::IEEE754::Tools), where ulp is the Unit in the last place. But really, ulp(value) is the easier way to figure out the exact ULP size for a given value, and you know that the "real" value is somewhere between +/- 1 ULP (actually, I think +/- 0.5 ULP, really) from the value stored in the 64-bit double float.

and you know that the "real" value is somewhere between +/- 1 ULP (actually, I think +/- 0.5 ULP, really) from the value stored in the 64-bit double float

Thanks for elaborating.
If these considerations are relevant to the post that started this thread, I'm genuinely curious to know just what that relevance is ... because I'm not really seeing it, and I'd hate to be missing out on something ;-)
(If they're not relevant, then that's OK. I always find thinking about and fiddling with such considerations to be fun, anyway.)

The doubles 0.5, 0.3, and 0.1 all have ULPs of the same value (2 ** -53) - yet they all differ from their respective rational representations (5/10, 3/10, 1/10) by different amounts.
It seems to me that the (details of the) behaviour reported by the OP has more to do with the size of the rounding error, than with the value of the ULP.

I'll check out Machine::Epsilon and Data::IEEE754::Tools.

Cheers,
Rob

If these considerations are relevant to the post that started this thread

As far as I can tell, they are tangential. My reasoning is expanded in the rest of my reply.

The doubles 0.5, 0.3, and 0.1 all have ULPs of the same value (2 ** -53)

No, they each have a separate power of two in their canonical floating-hex (%a) representation, and since the ULP is just the value of the lowest fractional bit, they each have a separate ULP:

perl -MData::IEEE754::Tools=ulp -le "printf qq{ULP(%s = %22.13a) = %.1
+7e = %22.13a\n}, $_, $_, ulp($_), ulp($_) for 0.5,0.3,0.1"
ULP(0.5 =   0x1.0000000000000p-1) = 1.11022302462515654e-16 =  0x1.000
+0000000000p-53
ULP(0.3 =   0x1.3333333333333p-2) = 5.55111512312578270e-17 =  0x1.000
+0000000000p-54
ULP(0.1 =   0x1.999999999999ap-4) = 1.38777878078144568e-17 =  0x1.000
+0000000000p-56
[download]

yet they all differ from their respective rational representations (5/10, 3/10, 1/10) by different amounts.

Yes, the canonical double-float representation differs from the exact rational representation by different amounts, but each is bounded by their ULP.

It seems to me that the (details of the) behaviour reported by the OP has more to do with the size of the rounding error, than with the value of the ULP.

I agree with that assessment. When the machine epsilon was brought into the conversation, I was trying (poorly, perhaps) to explain why I thought the epsilon wasn't relevant -- or at least, not the right fix --, and I used the ULP to show that even the stored error changes with magnitude, and applying the epsilon as an absolute value when the values being used were changing their power-of-two-magnitude was inaccurate.

Going back to the example of 0.03:

perl -MData::IEEE754::Tools=ulp -le "printf qq(%.17e = %22.13a => %s\n
+), $_, $_, $_ for 0.03, 2.99999999999999989e-02, 2.99999999999999503e
+-02, 2.99999999999999468e-02, ulp(0.03)"
2.99999999999999989e-02 =   0x1.eb851eb851eb8p-6 => 0.03
2.99999999999999989e-02 =   0x1.eb851eb851eb8p-6 => 0.03
2.99999999999999503e-02 =   0x1.eb851eb851eaap-6 => 0.03
2.99999999999999468e-02 =   0x1.eb851eb851ea9p-6 => 0.0299999999999999
3.46944695195361419e-18 =  0x1.0000000000000p-58 => 3.46944695195361e-
+18
[download]

... in that example, it rounds up at 5.03e-17 and rounds down at 4.68e-17, so it appears to be rounding to the nearest 1e-16; whereas the ULP id 3.5e-18, so the rounding is more than one ULP.

So even if 1ULP was the same as epsilon, which is only true for 1.0 up-to-but-not-including 2.0, the rounding is different. For example, I have to subtract 23 ULP from the canonical 1.03 representation before it doesn't round up to 1.03 displayed:

perl -MData::IEEE754::Tools=ulp -le "printf qq(%.17e = %22.13a => %s\n
+), $_, $_, $_ for ulp(1.03), map 1.03-$_*ulp(1.03), 0..5,22,23"
2.22044604925031308e-16 =  0x1.0000000000000p-52 => 2.22044604925031e-
+16
1.03000000000000003e+00 =   0x1.07ae147ae147bp+0 => 1.03
1.02999999999999980e+00 =   0x1.07ae147ae147ap+0 => 1.03
1.02999999999999958e+00 =   0x1.07ae147ae1479p+0 => 1.03
1.02999999999999936e+00 =   0x1.07ae147ae1478p+0 => 1.03
1.02999999999999914e+00 =   0x1.07ae147ae1477p+0 => 1.03
1.02999999999999892e+00 =   0x1.07ae147ae1476p+0 => 1.03
1.02999999999999514e+00 =   0x1.07ae147ae1465p+0 => 1.03
1.02999999999999492e+00 =   0x1.07ae147ae1464p+0 => 1.02999999999999
[download]

So yes, we've probably gone far enough on this tangent.

(NB: using windows cmd.exe-style command-line quoting throughout)