David Heffernan

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.

Before reaching this conclusion, does there exist a clear diagnosis of the problem. That hasn't been shown here yet, so I'd want to understand the problem before trying to solve it.

This is incorrect. Changing font properties in an event handler is fine.

It has nothing to do with assignment. It's pretty rare for absolute to be useful. Pretend it doesn't exists, and you'll get a long way.

It will never find invalid pointers, but that's not why Assigned exists

I think the use of string here is to allow encoding of indeterminate masses for elements with no stable isotopes, or something along those lines. Look at the items with mass surrounded by parens.