skill assoc : How does assoc command of skill work with anumerical value ?

Hi Giora,

It's not a numerical bug.  It appears to be a rounding error, within the bounds of what might be expected.

assoc simply uses equal() (which is the same as the == operator) to compare the values, and one should never use equal on floating point numbers because there is a possibility of rounding errors (there have been posts related to this before on this forum). Note that this is not something peculiar to SKILL, but in many languages (including C).

It appears that there has been a subtle change in ICADV12.1 (and IC616) in how the suffix notation is converted to a floating point number.

If you do: 50n-5e-8 you'll see there is a small residual error -  6.617444900424221e-24

If I do:

> printf("%.20g\n" 50n)
5.0000000000000004355e-08

> printf("%.20g\n" 5e-8)
4.9999999999999997737e-08

And If I do 

> printf("%.20g\n" 50*1e-9)
5.0000000000000004355e-08

In general, as I said, you should not use equal (or assoc) to compare floating point numbers, because a small rounding error (often just due to a single bit difference in the mantissa) can mean they are no longer precisely equal.

You could use something like:

procedure(myAssoc(val lst @optional (epsilon 1e-15))
  car(exists(entry lst abs(car(entry)-val)<epsilon))
)

Then you can use myAssoc instead of assoc in the above examples (this is using an absolute error criteria, but you could write it to have a relative error criteria if you preferred).

Kind Regards,

Andrew.

Hi Giora,

It's not a numerical bug.  It appears to be a rounding error, within the bounds of what might be expected.

assoc simply uses equal() (which is the same as the == operator) to compare the values, and one should never use equal on floating point numbers because there is a possibility of rounding errors (there have been posts related to this before on this forum). Note that this is not something peculiar to SKILL, but in many languages (including C).

It appears that there has been a subtle change in ICADV12.1 (and IC616) in how the suffix notation is converted to a floating point number.

If you do: 50n-5e-8 you'll see there is a small residual error -  6.617444900424221e-24

If I do:

> printf("%.20g\n" 50n)
5.0000000000000004355e-08

> printf("%.20g\n" 5e-8)
4.9999999999999997737e-08

And If I do 

> printf("%.20g\n" 50*1e-9)
5.0000000000000004355e-08

In general, as I said, you should not use equal (or assoc) to compare floating point numbers, because a small rounding error (often just due to a single bit difference in the mantissa) can mean they are no longer precisely equal.

You could use something like:

procedure(myAssoc(val lst @optional (epsilon 1e-15))
  car(exists(entry lst abs(car(entry)-val)<epsilon))
)

Then you can use myAssoc instead of assoc in the above examples (this is using an absolute error criteria, but you could write it to have a relative error criteria if you preferred).

Kind Regards,

Andrew.