Leaderboard

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!

If you are using ICS created Let's Encrypt certificates in Windows IIS web server, you may find web sites no longer work correctly, giving a certificate error. This is because Let's Encrypt had discontinued it's OCSP service as a means of determining if certificates have been revoked. In each IIS site bindings, for each listener, you need to tick 'Disable OCSP Stapling', and the certificates should work again. Happened here after a reboot for patch Tuesday. I did not see any OCSP errors or warning in the IIS or Windows event logs, but knew about OCSP being abandoned. I've already added conditionals to the next ICS release to remove our OCSP code. Angus

Really?

Hi All I created a Delphi implementation of UUIDv7 - RFC 9562 UUIDv7 values are time-sortable, which means you can sort them in increasing order based on when they were generated. https://github.com/VSoftTechnologies/VSoft.UUIDv7 Should work with XE2=12.x Win32/Win64 and all platforms on 11.3 or later. Usage : var guid : TGuid; begin guid := TUUIDv7Helper.CreateV7; writeln(guid.ToString); end;

1. Debuggers, debuggers, debuggers - multithread handling is abysmal today 2. Make HighDPI actually works as intended - it is useless in a team as is - unless everyone runs the same scaling 3. Generics constraints for enumerated types to enable the use of conversion to/from ordinal values, use set operators, etc. 4. Native ARM64 compiler for Delphi for Windows (and Linux/Raspberry PI, but Windows has prio) 5. A 64-bit IDE that ensured that EMBT was dogfooding 64-bit VCL and RTL and raise the quality As for AI, I wouldn't mind an AI that could look at code and suggest improvements - perhaps as a part of the static code analysis, or one that could explain "what does this code do". I don't really need or want an AI to generate code. If it is a standard, a lib should already exist. If it doesn't and there is no standard that covers the need, I'd be happy to have an AI outline alternative approaches - but given that the wide scope of parameters that goes into a design, I think it is unrealistic to expect that it would come up with the ideal suggestion without us writing a huge requirement. The output of VLLM generators is extremely dependant on precise and accurate specification statements, and writing those are almost as hard as writing good code. As for AI and privacy - keep your secret credentials separated from your code. Other than that, I don't think that many of us write code that truly needs to be hidden for secrecy reasons, although it is obvious that it will be necessary to ensure that privacy permeates the use of AI.