David Heffernan

WinProcs? Why are you working with code from the 1990s? Where did that code come from?

Is this a minimal do nothing program? Or is your actual application logic there?

Likely a defect in your code. You'll need to start debugging.

There will be other calculations where that isn't the case

Floating point can be tested for exactness too. Your idea of doing floating point calcs and then rounding to 4dp before equality testing is still subject to issues. If there are differences after the floating point calc, then the round to 4dp could fall on different sides of the rounding boundary. Always in these discussions there needs to be more specifics of the calcs involved.

Why would you be calling power and then truncating to 4dp and comparing for exactness?

Seems like bad advice. Why would you do this?

Generics in 2010 were super bugged but generics is irrelevant for a port. Trying to find versions of all libraries that work with 2010 could be tricky. I see no reason in doing multiple ports here.

This is the part I didn't watch, but yeah, that makes so much more sense now!

He's probably using UTF-8

It's a sign from above

Perfect hash only works if you can restrict your input domain, or am I wrong?

The thing is, how are you going to get to the stage where you have got a token that you know is a valid keyword? Perfect hashes are cool and all, but I wonder if this is the best example.

What seems missing to me is how to restrict the input data to be just valid typescript keywords.

I use option sets. They are in my repo and if I want to change the all my projects pick them up.

Nah, I'd go all the way to the latest. Multiple stepping stones is just adding extra complexity. The big change is Unicode. Everything else is simple.

The Delphi RTL can do this in multiple ways, as discussed here, and elsewhere, by me, ad nauseum.

Not strictly true. It depends on where they are coming from. It's much more complex than this blanket advice which I always regard as poor advice.

It's exactly as @Stefan Glienke said. The 32 and 64 bit hardware is different. On 32 bit there are 80 bit floating point registers used for intemediate values. On 64 bit there are not and all FP registers are 64 bit. Did you read the link I gave you? If you have not read that yet then this conversation is rather pointless? You first of all have to appreciate that these values cannot be represented exactly in binary floating point format. Perhaps your real problem is that you are using the wrong data types. Maybe you should be using a decimal data type so that you can represent these values exactly? What are these values? Sometimes floating point is correct, sometimes decimal is correct. Without context we can't know. Or perhaps you already know about floating point representability issues. Do you?

Here's some Python output that should help: >>> from decimal import Decimal >>> Decimal.from_float(1.015) Decimal('1.0149999999999999023003738329862244427204132080078125') >>> Decimal.from_float(3.015) Decimal('3.015000000000000124344978758017532527446746826171875') >>> Decimal.from_float(1.015*100) Decimal('101.4999999999999857891452847979962825775146484375') >>> Decimal.from_float(3.015*100) Decimal('301.5') And @Stefan Glienke explained why results differ on 32 bit because that uses an intermediate 80 bit extended register that will have different values for the closest representable value.

You are going to lose your mind when you learn that 1.015 is not representable, and when you write 1.015 in your delphi source code, the compiler turns it into the closest representable number which happens to be 1.0149999999999999023003738329862244427204132080078125 You might want to take a look at this famous question on SO: https://stackoverflow.com/questions/588004/is-floating-point-math-broken

Why should we do this?

You'd have the answer by now if you'd started stripping stuff out

What does the debugger tell you

There's also this technique