Numeric comparison fails if multiply by 1000

[maxprs]

Hello,

the picture below should explain better than many words.

If I set "Numeric IN 2" to 1,5E-4 and multiply by 100 I get "Compare 2" = true.

So when multiplying by 1000 some limit is exceeded some how; any idea what that limit is?

Or a workaround to make it work anyway.

Thanks

[Yamaeda]

If you increase the precision shown you'll see that 0,015 isn't represented exactly. That's a known limitation of floats. For comparison, multiply by the factor (e.g. 10E6 for 6 digits) and compare the integers.

Since the decimal part is binary (i like to call them binals), which bits would need to be active to get 0.015?

The binary version of 0,015 = 

From wikipedia

So the fraction starts with "1110101110000101"

[crossrulz]

Equality checks for floating points is a lost cause. This is not just a LabVIEW problem: all programming languages that use this IEEE-754 will have this issue. You should compare if the value is in a range.

[Andrey_Dmitriev]

---

@crossrulz wrote:

Equality checks for floating points is a lost cause. This is not just a LabVIEW problem: all programming languages that use this IEEE-754 will have this issue. You should compare if the value is in a range.

---

This is absolutely perfectly true. However, some programming languages provide additional functions or macros such as relative_eq!(), as well as static analysis warnings for such comparisons.

For example:

#![warn(clippy::float_cmp)]
use approx::relative_eq;

fn main() {
	println!("\nCompare 1.5E-2 and 1.5E-5 * 1000:\n");

    println!("Strict comparison of Floats (f32):");
	let a = 1.5E-2_f32;
	let b = 1.5E-5_f32 * 1000.0;
	println!("{a} == {b} > {}\n", a == b);

	println!("Strict comparison of Doubles (f64):");
	let a = 1.5E-2_f64;
	let b = 1.5E-5_f64 * 1000.0;
	println!("{a} == {b} > {}\n", a == b);

	println!("Doubles (f64) with tolreance:");
	let a = 1.5E-2_f64;
	let b = 1.5E-5_f64 * 1000.0;
	println!("{a} == {b} > {}\n", 
		(a - b).abs() <= f64::EPSILON * a.abs().max(b.abs()));

	println!("Doubles (f64) with relative_eq!():");
	let a = 1.5E-2_f64;
	let b = 1.5E-5_f64 * 1000.0;
	println!("{a} == {b} > {}", relative_eq!(a, b));
}

The beauty of relative_eq!() is that it encapsulates the tricky tolerance logic, so you don't have to choose and maintain arbitrary epsilon values yourself. Comparing directly against naked f64::EPSILON is generally not reliable across the full range of floating-point values because the appropriate tolerance depends on the magnitude of the numbers being compared, this needs to be corrected accordingly.

Result:

>cargo run

Compare 1.5E-2 and 1.5E-5 * 1000:

Strict comparison of Floats (f32):
0.015 == 0.015 > true

Strict comparison of Doubles (f64):
0.015 == 0.015000000000000001 > false

Doubles (f64) with tolreance:
0.015 == 0.015000000000000001 > true

Doubles (f64) with relative_eq!():
0.015 == 0.015000000000000001 > true

By the way, the strict comparison for floats works for these particular f32 values. In LabVIEW, it also evaluates to true:

Back to warnings, the linter output looks like this:

>cargo clippy

warning: strict comparison of `f32` or `f64`
  --> src\main.rs:10:32
   |
10 |     println!("{a} == {b} > {}\n", a == b);
   |                                   ^^^^^^ 
   | help: consider comparing them within some margin 
   | of error: `(a - b).abs() < error_margin`
   |
   = help: for further information visit
   https://rust-lang.github.io/rust-clippy/rust-1.97.0/index.html#float_cmp
note: the lint level is defined here
  --> src\main.rs:1:9
   |
 1 | #![warn(clippy::float_cmp)]
   |         ^^^^^^^^^^^^^^^^^

This is one of the reasons I like Rust. I'm not sure whether the LabVIEW VI Analyzer can detect this issue. With the default configuration and all built-in tests enabled, the analysis completed without any warnings or failures:

It is probably possible to implement a custom analyzer test for this with help of VI scripting, but I haven't tried doing so before.

[Yamaeda]

One simple solution is this:

[Andrey_Dmitriev]

---

@Yamaeda wrote:

One simple solution is this:

---

This will obviously fail for the cases like this:

I guess I saw a general approach somewhere on this forum, but I don’t remember where.

[Andrey_Dmitriev]

The learning book says that a generic implementation should perform both relative and absolute comparisons, something like this:

Refer to the relative_eq implementation and the article Comparing Floating Point Numbers.

[maxprs]

Hey guys, I know that this community is full of skilled people, but I didn't expect so many tips and solutions in just few hours.
Thanks a lot to everyone for chiming in to help. I'll be back to the office in a couple of weeks, and along with a colleague we'll try to apply the solution that will best fit into our project.
Again, thank you very much, I will keep you updated in case of any new findings.

[RTSLVU]

I can't remember where I found this but I believe that's what this does

[Yamaeda]

---

@Andrey_Dmitriev wrote:

---

---

This will obviously fail for the cases like this:

I guess I saw a general approach somewhere on this forum, but I don’t remember where.

---

Yes, ofc. If the change is much smaller than the tolerance that's expected. 🙂 I like your other Absolute+Relative check.