David Heffernan

It's almost as if posts from two completely different threads have somehow been interspersed with each other

Fair. I was just looking at a statement about Chr(11200) in isolation. My bad. Off topic aside follows below: Interestingly, if the process has UTF-8 as the active code page (ccchttps://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) then you can use AnsiString fine and be fully Unicode compliant. I discovered this by accident lately when my MATLAB mex file, which uses ANSI because MATLAB doesn't do UTF16, unexpectedly started handling Unicode with a recent MATLAB update! The update set this code page in its manifest.

What is the encoding of the input. Can you guarantee that it is ascii?

Thanks for the correction. The main point stands, namely that Chr(11200) is perfectly valid.

It depends on the encoding of the 8 bit data. For all we know, that data could be ASCII. The problem is that the question doesn't have any actionable information, and the asked is just hoping for some silver bullet. Asker needs to get some real information rather than hope that people here can guess what's up.

That's going to be a 16 bit Char with ordinal value 11200. It's KHOJKI LETTER A. See https://unicode-table.com/en/11200/ Nothing to see here

I was pushing back against the quoted response, which was deeply unhelpful. As for what you need to do, I doubt the issue is with the update. I'd look to debug your code.

You better hope you have two or more items in the collection when you execute that code. And as Stefan says, your code is nearly as bad a way to do this as possible. I think the only worse way is to call ToArray. There are plenty of ways to do this well, and it baffles me that you choose the poor solution when good solutions exist. Does quality not matter?

Nobody has any idea what the actual problem is, but yeah, let's just randomly through some AnsiStrings around. This approach to coding doesn't work. The monkeys still haven't typed Shakespeare yet..

You can look at the list of public methods and properties. Why do you need us to tell you that what you want isn't there? Didn't all the responses suggesting alternatives indicate that?

Push is Add. Pop is Extract(Count-1) and Peek is Items[Count-1] Contains won't help you because it checks the entire collection, not just the top two.

Adding push pop and peek to TList is incredibly simple. I thought you wanted access to them all because you talked about searching the collection for a specific item. Do you not need to do that?

Well, what's stopping you doing that? It's not a challenge. If you want random access to the entire collection, a stack isn't for you.

Make me yak

Seems like you want TList<T>

I think it's far more likely to be environment variables being inherited.

This sounds wrong. Messing with the system path and closing an ide tells me that you aren't creating and isolating your compile environments correctly. Note that Delphi is capable of building with any path and with any other ide open. You have solved nothing yet.

Not true. FValue, in your example, is available as soon as the instance has been allocated. Realistically the earliest you get to use it is inside the constructor.

No

Yikes!! Even leaving aside Stefan's point, functions that use a relative tolerance, relative to the comparands, mean that your comparisons depend on the path through the array. I think it very likely that inserting some extra values away from the target could lead to a different value being found. There certainly are situations where comparing to tolerance is useful. However they need to be considered in detail and the tolerance choice and surrounding algorithm must be carefully thought out. A one size fits all function like this is not useful in my experience. Furthermore, I would say that a lot of times I have seen tolerance checking, it comes from a misunderstanding of floating point representations. Tolerances get used when they aren't needed. Sometimes it's not entirely the programmer to blame. For instance delphi's string conversion functions are broken because you can't rely on a round trip from float to string and back to float. So if you save as json or YAML or ini, say, then you don't get back the original value when you load from text. This is intolerable for a serious floating point developer. And it often drives people to compare to tolerance. My solution is to use conversion libraries that work correctly. Emba know about the problem but unless I am mistaken still have not fixed the problem.

This certainly changes things!

Right. They do what they are meant to do. It's just that they aren't actually useful for anything.

Then you are going to need to work out what your problem really is. Because it hasn't been stated here. If you want to work with numbers that have a finite number of decimal digits, then use a decimal type. It is precisely why such things exist.

They are invariably used as "solutions" to problems caused by floating point representability issues, but usually are the wrong solution.

{$APPTYPE CONSOLE} uses SysUtils; procedure Main; var i: Integer; val: Double; begin val := 0; for i := 0 to 80 do begin Writeln(FloatToStr(val)); val := val + 0.1; end; end; begin try Main; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end. Output: 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.99999999999999 6.09999999999999 6.19999999999999 6.29999999999999 6.39999999999999 6.49999999999999 6.59999999999999 6.69999999999999 6.79999999999999 6.89999999999999 6.99999999999999 7.09999999999999 7.19999999999999 7.29999999999999 7.39999999999999 7.49999999999999 7.59999999999999 7.69999999999999 7.79999999999999 7.89999999999999 7.99999999999999 So yeah, not looking such a good idea now. Why not use integers. You just need to count how many tenths you have. That's the job of an integer. Once you recognise this, then you are 90% of the way to realising the right solution.