David Heffernan

Probably the biggest problem is the inability to be precise in the statement of your issue

OK, given that this was posted in General Help, I just assumed you were looking for help, rather than sharing something humorous.

Why do you care about the warnings? We know that D7 gets them wrong. Just ignore them.

If you think there's a bug, submit a bug report. What do you think we can do? And when you do, include a complete program in which you verify the defective behaviour. Obviously not your actual program. A minimal reproduction. Then you'll probably find out the real issue, which will likely be your expectations being incorrect.

MechaHitler surely

It could also be TForm and everything assembled at runtime. @Anders Melander already ended all debate in this thread.

You can see your project, we cannot.

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

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?

Yes, my fault. Sorry.

I mean you didn't say any of this in your original post. Clearly you knew what your requirements were, but we can't read your kind!

var Counter: UInt64;

My advice is to understand a problem before looking for a solution. At the moment it's clear that the problem still eludes you. Concentrate on that first.

Every time someone calls SameValue a puppy dies

It depends a bit on what your goals are. But if you want to test equality then you need to put the expected value into a single. That's hard to do in a compiler because delphi literal syntax doesn't allow to specify the type of a floating point literal. You could declare a typed constant of single type and compare against that.