@Danilo: I appreciate your input (even if it is leaning towards being condescending

). My observations are meant to show that despite what has been said there isn't a simple tried-and-true way to do this. All of the ways involve limitations because they don't work for every situation.
Danilo wrote:
Using the common standards, it is correct as long as you stay within the limits of the data types involved. Using PB's own mathematics,
it is almost always wrong or depends on coincidence, like what data types stay on the left and right side of a comparison.
It is good you brought up common standards. What are the common standards for PureBasic?
The only description I found in an official reference was in the help manual:
Help file under 'General Rules' wrote:
Expressions
An expression is something which can be evaluated. An expression can mix any variables, constants, or functions, of the same type. When you use numbers in an expression, you can add the Keyword $ sign in front of it to mean a hexadecimal number, or a Keyword % sign to mean a binary number. Without either of those, the number will be treated as decimal. Strings must be enclosed by inverted commas.
That seems to say that comparisons of different types is already inviting trouble. An easy solution to this is to convert the types to a common type. Suggestions to do this have included using the function Int() or Round(), instigating automatic conversion by adding 0.0, and using assembly to invoke the FPU.
Danilo wrote:
What's better in your world?
I'm using PureBasic too. There is information regarding observations about how PureBasic works through an expression with mixed types (i.e. blueznl's
PureBasic Survival Guide). These and the help file's advice to not mix types should guide someone in how they construct the comparisons.
Everything else involves Fred changing or improving PureBasic. I think he should detail some more about the standards so that these questions might be dealt with more easily. I think that the suggestions regarding type casts would be helpful. Other hypothetical suggestions such as promoting everything to 80-bit precision extended floats when they are being so that they will 'always' be accurate will have the drawback of possibly slowing things down unnecessarily.
Danilo wrote:
Compiler construction, like mathematics, is taught at universities, and there is plenty of literature available for it.
You seem to think that everybody should invent his/her own mathematics, ignoring all teachings and common standards. It's OK.
There are standards and there is plenty of literature available. All the ones I found have said the standards vary according to what is deemed most important. You can do methods A, B, or C. If you choose A you get some results; B gives some of the results of A and a few others; C will give you some of the results of B but not all of A's. There is nothing that is 'best' or 'perfect' since it is dealing with the limitations imposed by the computer, time, or money.
@wilbert: Wouldn't this code function just as well?
Code:
Procedure CmpQD(quadValue.q, doubleValue.d)
Protected x.d, result
x = doubleValue - quadValue
If x = NaN() Or x = IsInfinity()
result = 7
Else
Select Sign(x)
Case 1 : result = 0
Case -1: result = 1
Case 0 : result = 2
EndSelect
EndIf
ProcedureReturn result
EndProcedure