How do I assert a single ?

[Kas Ob. 138]

42 minutes ago, Rollo62 said:

All this might be true, but is very scientific.
Unless I cannot see a real benefit, I will stay with my decimal Epsilon, perhaps only in deeper Physics we would need different perspectives than 10^-3, ... 10^-15 or so.

That is personal point of view, i agree, but how many out there and here in this very forum knows that SameValue without Epsilon with return True for any value less than 1e-4=0.0001 even with 0, like comparing 0.000099 with zero will be True, also for bigger number should Epsilon go in decimal or will always be False, and how many knows how to estimate Epsilon the right way.

 

Machine Epsilon should be incorporated check approximation, that is a fact, and the lack of documentation is disturbing to say the least, the main point here isn't this the job of the library (or the function) to do that in right and correct way ?

 

Just food for thoughts.

 

And yes should renamed to be Delta there.

[Kas Ob. 138]

One last thing here, from the documentation 

Quote

If Epsilon = 0, then some reasonable default value is used implicitly. For example, the Double version of SameValue uses the default value:

Epsilon = Max(Min(Abs(A), Abs(B)) * 1E-12, 1E-12)

Although i hate to do the multiplication and see it to some extent as wrong instead of division of the delta on the biggest, why this is not in the library (Math unit) as function ? that is the question.

 

 

[David Heffernan 2444]

1 hour ago, Kas Ob. said:

And yes should renamed to be Delta there

I don't think that the parameter to SameValue should be named either epsilon or delta, it should be tol or tolerance. Or am I misunderstanding?

[David Heffernan 2444]

On 6/7/2025 at 9:22 AM, dummzeuch said:

OK, I bite: What's the problem with SameValue?

The principle of a function that compares real values for equality, up to a specified tolerance, is a valid thing to do in many cases. But there are lots of caveats. In practise, most developers (and far from just in the Delphi space) that I see recommending it are completely unaware of these caveats. Some of these caveats and issues:

1. How do you choose a tolerance? Does your tolerance account for the scale of the values, and indeed should it? Some use cases demand absolute tolerances, some demand relative tolerances.
2. If you are accounting for scale, how do you choose the scale? Is it based on the pair of values being compared, or should it be based from the total pool of values. For instance, you might have two series that you wish to compare. Shouldn't the scale be based on the series rather than individual samples? Or maybe it is individual samples.
3. It's easy to mistake this as an equality, but the resulting relationship implied by equality to tolerance is not transitive, so is not a mathematical equality. That is a R b and b R c does not imply a R c.

Looking more specifically at Delphi's SameValue, the tolerance used when the Epsilon parameter is zero (or omitted) is very odd. I definitely think puppies are dying left, right and centre when that code path is chosen.

 

One of the common misconceptions with floating point is that it is not exact. I think of it as exact, subject to the rules of the domain, but the key point is that not all values are representable. So if you have floating point values a and b, then they represent some precise real value. But when you do a * b, say, then the true value may not be representable. And so the result is the closest representable value. This is well defined, and reproducible. A lot of people think that there's just some random errors and fuzz in it all. That FuzzFactor constant in the RTL source seems to be a classic example of that sort of thinking. This famous question on SO is a useful resource: https://stackoverflow.com/questions/588004/is-floating-point-math-broken

 

One of my pet bug bears in Delphi is its inability to convert correctly between floating point and textual representations. In every other mainstream language (and most non-mainstream languages) this is possible. But in Delphi the code used to perform these conversions is home grown and broken. There are good algorithms for doing this, and it's a subject of active research, but Embarcadero don't seem to care about this. In my codebase I use correct algorithms. Which means that for all values I can convert from float to text and back and always get the same value. The inability to do this often leads to users calling SameValue.

 

My own codebase does call comparison function that compare for equality to tolerance. But there is a lot of care taken in how the tolerance is chosen and applied.

 

I guess that's the crux of what I am saying. So many people just say, this is hard, slap a tolerance onto the comparison that is good enough for the two values I have to hand, and surely that's fine for all other values! I'm a bit of a pedant in this area, I admit. But it's kind of my job to be. Sorry!

[Kas Ob. 138]

44 minutes ago, David Heffernan said:

I don't think that the parameter to SameValue should be named either epsilon or delta, it should be tol or tolerance. Or am I misunderstanding?

No, you understand it right, just not Epsilon, that is annoying.

Not sure about naming it Tolerance or tor though.. because somehow feels misleading too like epsilon,

 

The use of Delta mostly comes form the word Distance and used as such. also Delta in general associated with difference between two values, and it is de facto the standard distance between points or values ( like |x-x0| = Dx , or |x,y| =Dxy ....), vectors (in geometry) etc

 

May be Threshold, ComparisonThreshold,  AcceptedDistance , MaxDifference, AllowedError, AllowedDistance ...