in reply to Re^4: what did I just see..?
in thread what did I just see..?

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.

Replies are listed 'Best First'.
Re^6: what did I just see..?
by syphilis (Bishop) on Mar 25, 2021 at 01:01 UTC
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

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
... 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

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

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

No, they each have a separate power of two in their canonical floating-hex (%a) representation

Yes, that was careless thinking ("thoughtless thinking" might be a better term) on my part.

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

Agreed.
However, there were a couple of things in your last post that I couldn't quite follow.
I'll mention them here, and you can respond if you like - but I think we both understand what we're doing, so please feel free to not respond at all. (I think you've probably already put more effort into this thread than you would have been expecting.)

IIUC, in respect to the value 0.3, you wrote "whereas the ULP is 3.5e-18", yet I believe it's actually 5.551115123125783e-17.

You also wrote "I have to subtract 23 ULP from the canonical 1.03 representation before it doesn't round up to 1.03 displayed".
I take it that was in relation to the difference between 1.03000000000000003e+00 and 1.02999999999999980e+00 .
Firstly, I think you should have been looking at the "%.16e" or "%.17g" (not "%.17e") formatting of the values.
Secondly, by my way of thinking, the difference between 0x1.07ae147ae147bp+0 and 0x1.07ae147ae147ap+0 is 1 ULP, irrespective of what the chosen decimal formatting shows.

Anyway, thanks for the time you've taken in clarifying and correcting.

Cheers,
Rob