PureBasic Forum

Hi all,

I recently discovered that it's not possible to compare integer and float (or double) variables reliably -- tested with PB 5.22 LTS x86 and x64 on Windows 7.
Please see the following code:


As the code shows, the comparison only works correctly when I first copy the value of the integer variable to another float variable, and then compare both float variables.

Is this by design, or is it a bug?

The compare sign and if statements use the first parameter for comparison:

I thick it ist no bug, it is a feature

I think it's a kind of bug-by-design.

Change the a < x to a = x and you will see it will print "OK", that's because the float it's converted to integer (FISTP) so it lose its decimal part.

PB seems to found an integer (a.i) first in the expression, so switches to integer mode for the rest of the expression.

I suppose that's the same reason why you can't use bit shift operators (<< >>) with a perfectly valid integer if there is a float before in the expression.



So it's by design. Having explicit casts we could at least influence the thing.
Having implicit cast on the other hand should require the compiler to issue warnings from time to time when a possible loss of info can be caused by the implicit conversion, as it happens in your specific example where the decimal part is silently gone.
But not having explicit casts to guide the compiler the warnings could become annoying. Those we have are already annoying to me since you don't have a compiler directive to shut off a specific warning.

Normally in a case like yours the implicit conversion is from integer to float, and not the other way around like PB is doing.

Don't know if this is explained somewhere in the manual BTW, if not it should be... if you know it and pay some (a lot ?) of attention since the compiler doesn't warn you, and since the conversion seem to be just based on a first come first served basis (left to right order), you can avoid it.

As has been stated the left hand side of comparison determines how the right hand side of the comparison will be used.

Because the expression you used on the left hand side of the comparison operator starts with an integer and doesn't include any floating point math or variables it evaluates to an integer and the right hand side will also be converted to an integer to make the comparison.

If you want both sides to be treated as floats then you need to reverse the order of the comparison (i.e x.f > a.i instead of a.i < x.f) or add a float to the first expression (i.e a.i + 0.0 < x.f) or assign the first expression to a float variable before comparison.

It is a bug. When 2 values are compared, the smaller type is first widened to the bigger type, and
then both are compared. For example, if you compare a Byte and a Quad, the Byte first gets widened
to Quad, and then two quads get compared. It does not matter on which side the Byte stands.
It would not make sense to cut off the Quad to be a Byte, and then compare two Bytes.

Instead, the smaller type gets widened to the greater type:


In this case here, the Float has higher priority than Long, because it can contain more precise values.
The Long needs to get converted to Float, and then 2 Float values get compared.
It does not matter on which side a value stands. With "a.l < b.f" and "b.f > a.l", both times
the Long value needs to get converted to Float first, and then two floats are compared.

6.5.2: Type Conversions

@danilo

That's how other languages do these things following some kind of logic widely accepted.
In that light, my example of bit shifting should work too, as it does in other languages.
That one has already been marked as a "coding question" and not a bug report (which initially was).

So this can look like a bug to you compared to what it's normally accepted as a solution for the problem, but if fred tell us it is by design, then it's how the thing ends, in a bug-by-design (TM).

When a language it's not strictly defined and almost any behavior involving expressions and such is derived by looking at the forum following the programming by example approach, it's quite difficult to call something a bug.

Could be by "design".

We'll see about this one.

That rule is true of integers but not of floats and integers. See code below. The code demonstrates that a float is not greater than a long for the reason that it does not hold greater amount of precision. In fact when the max value of a long is assigned to a float the float gets the incorrect value. The example code also shows that a float being at its max precision (that of a long) cannot be incremented by a single unit of precision any more. It doesn't matter what its exponent is, it has the same precision as a long.

Since that is true which should be converted to the other and why?





So I would say that the above diagram is incorrect and that float and long are "mostly equal" and not one above the other and I would say the same is true of quads and doubles.

@Little John

How GNU GCC treat this




output:



That's the way (uh huh uh huh) I like it (uh huh uh huh)

shorter integer types are converted to longer integer types
shorter float types are converted to longer float types
integers are converted to floating point
signed/unsigned conversions try to avoid loss of data

The validity of the resulting conversions depends on the actual values contained in the variables obviously.

That's why compilers supporting implicit type conversion normally show a lot of warnings when something potentially dangerous is detected and offer explicit casting to let the programmer say to the compiler: "Don't worry, I know in this specific case the range of values stored in the var I'm asking you to coerce into another type will not cause problems."

When comparing float/double and integer, all types should be internally converted to floating point by the compiler.

The FPU doesn't care what precision your floating point number is. It only deals with EXTended 80 bit floating point numbers. The 32 bit float and 64 bit double only exist in memory, not on the FPU.

When any float/double is loaded onto the FPU it is converted to an internal 80 bit format before being used in any calculation. That conversion is 100% accurate.

That same 80 bit EXT format can fully contain all integers up to 64 bits so any comparison between any float/double and any integer up to 64 bits can be done with the FPU with 100% accuracy.

Thank you for sharing that.

That would be great if comparisons were using the 80-bit EXT when making comparisons between floats/dobules and integers because the significand would be able to hold an integer value without loss of precision. Unfortunately it doesn't seem to work that way when variables are involved. The variables are still limited to the precision that they are defined with. Only expressions can make use of the 80-bit EXT format, so it is ineffective in resolving these situations without compromising the comparison (at least in the extremes).



@Edit: added the display of the values (all these years later )

See my previous examples (in response to your previous posts) and their explanatory comments.

To sum it up, you can't fix the long to float comparison in all cases by simply converting both sides of the expression to either floats or to longs, they both have limitations. Floats can't represent all long values and longs can't represent all float values. The same is true for quads and doubles.

You need to make sure that both are within limits, when you compare Float and Long / Double and Quad / Long with Double / Quad and Float.
The original topic is within this limits:
Your numbers are not within the limit (as shown by my last posting), so you can't use this numbers to compare Floats with Longs and Doubles with Quads.


PB does not handle the first case correctly (when numbers are within limits), so it is a bug.
(There are usually more things involved, like setting FPU precision mode etc., but you already know that)

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.

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.

In my example above, staying within limits of both involved data types, 100% of ASM output is correct,
and 40% of PB output is correct for the same comparison. What's better in your world?

You can create your own compare procedure based on the code Danilo posted

@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.



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:


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.


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.


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?