### Author Topic: A Bug or Not A Bug  (Read 433 times)

0 Members and 1 Guest are viewing this topic.

#### MeasureUp

• Bull Frog
• Posts: 416
##### A Bug or Not A Bug
« on: July 31, 2017, 11:31:23 pm »
(setq number1 (getreal "\n\nGet Number: "))
If "number1" = 5.123, then both (/= number1 5.123) and (= (fix (* number1 1000)) 5122) are true.

Can you please explain?

My version: AutoCAD mech 2016

#### Tharwat

• Bull Frog
• Posts: 495
• Hypersensitive
##### Re: A Bug or Not A Bug
« Reply #1 on: August 01, 2017, 12:51:33 am »
Hi,

Should try it with equal function since you have decimal numbers with fuzz in this case.

Code - Auto/Visual Lisp: [Select]
`(equal number1 5.123 1e-4)`

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #2 on: August 01, 2017, 01:09:08 am »

But why the follow also returns true?
When number1 = 5.12
(= number1 5.12) = T
(= (fix (* number1 100)) 512) = T

These really confuse me.

#### kdub

• SuperMod
• Swamp Rat
• Posts: 935
• class keyThumper<T>:ILazy<T>
##### Re: A Bug or Not A Bug
« Reply #3 on: August 01, 2017, 02:38:47 am »

But why the follow also returns true?
When
(setq number1 5.12)
(= number1 5.12) = T
(= (fix (* number1 100)) 512) = T

These really confuse me.

What would you expect the result to be ?
what is confusing for you ?
called Kerry in my other life

Sometimes the question is more important than the answer.

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #4 on: August 01, 2017, 02:51:23 am »
I was comparing with (fix (* number1 1000)) and 5123 when number1 is 5.123
I find that (= (fix (* number1 1000)) 5123) doesn't return true but (= (fix (* number1 1000)) 5122) is true.

As I also mentioned, the above comparison is no problem when number1 is 5.12

#### kdub

• SuperMod
• Swamp Rat
• Posts: 935
• class keyThumper<T>:ILazy<T>
##### Re: A Bug or Not A Bug
« Reply #5 on: August 01, 2017, 03:51:01 am »
Works for me

using 2017 for this test.

« Last Edit: August 01, 2017, 04:00:41 am by kdub »
called Kerry in my other life

Sometimes the question is more important than the answer.

#### roy_043

• Swamp Rat
• Posts: 1450
##### Re: A Bug or Not A Bug
« Reply #6 on: August 01, 2017, 04:09:17 am »
There seem to be not just one but two issues here:
1.
Reals are not stored in the decimal format. Not every decimal number can be exactly translated to a floating point real. This is where the fuzz argument of the equal function comes in.
2.
The getreal function can have a 'mind of its own'?
Code: [Select]
`(defun c:test ( / str num)  (setq str (getstring "\nNumber as string: "))  (setq num (getreal "\nNumber as real: "))  (- (read str) num))`If 5.123 is entered twice:
BricsCAD V14 32 and 64 bit: Returns 8.88178e-016
BricsCAD V16 64 bit: Returns 0.0

The second issue is new to me.

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #7 on: August 01, 2017, 07:15:32 pm »
Thanks to Kerry & Roy.

I noticed Roy's explanation. Let me restate the issue:

If (setq number1 (getreal "\n\nInput A Real: ")) and 5.123 was entered
(= number1 5.123) returns "nil"
(= (fix (* number1 1000)) 5123) returns "nil"

Instead of "getreal" function, I set (setq number1 5.123), then
(= number1 5.123) returns "T"
(= (fix (* number1 1000)) 5123) returns "T"

On the other hand, if (setq number1 (getreal "\n\nInput A Real: ")) and 5.12 was entered, or simply set (setq number1 5.12)
(= number1 5.12) always returns "T"
(= (fix (* number1 1000)) 512) always returns "T"

A Bug or Not A Bug?

#### kdub

• SuperMod
• Swamp Rat
• Posts: 935
• class keyThumper<T>:ILazy<T>
##### Re: A Bug or Not A Bug
« Reply #8 on: August 01, 2017, 08:08:49 pm »

If (setq number1 (getreal "\n\nInput A Real: ")) and 5.123 was entered
(= number1 5.123) returns "nil"
(= (fix (* number1 1000)) 5123) returns "nil"

< ... >

In this case , to test getreal equality use the equal function and declare a fuzz factor

Code - Auto/Visual Lisp: [Select]
`(equal number1 5.123 1e-4)`
called Kerry in my other life

Sometimes the question is more important than the answer.

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #9 on: August 02, 2017, 09:01:19 pm »
Hi Kerry, thank you again.

Obviously, a fuzz factor solves the problem.

However, it seems not to be logical in practice.
If (setq number1 (getreal "\n\nInput A Real: ")) and 5.123 was entered, we all can tell the value of "number1" is exactly same as 5.123
The introduction of fuzz factor to the comparison (equal number1 5.123 fuzz) seems not making sense, logically.
Furthermore, to the examples given in my reply post #7 or examples just retested below, when does user insert the fuzz factor?

I am still wondering if there is a "practical" workaround for this issue.

= = = = = = = = = = = = = = = = =
BTW I retest the following examples.
(1) 5.12
If (setq number1 (getreal "\n\nInput A Real: ")) and 5.12 was entered, or simply set (setq number1 5.12)
(= number1 5.12) always returns "T"
(= (fix (* number1 1000)) 512) always returns "T"

(2) 5.123 - This is the only problematic case.
If (setq number1 (getreal "\n\nInput A Real: ")) and 5.123 was entered
(= number1 5.123) returns "nil"
(= (fix (* number1 1000)) 5123) returns "nil"

Instead of "getreal" function, I set (setq number1 5.123), then
(= number1 5.123) returns "T"
(= (fix (* number1 1000)) 5123) returns "T"

(3) 5.1234
If (setq number1 (getreal "\n\nInput A Real: ")) and 5.1234 was entered, or simply set (setq number1 5.1234)
(= number1 5.1234) always returns "T"
(= (fix (* number1 10000)) 51234) always returns "T"

#### Keith™

• Villiage Idiot
• Seagull
• Posts: 16617
• Superior Stupidity at its best
##### Re: A Bug or Not A Bug
« Reply #10 on: August 02, 2017, 09:21:00 pm »
I cannot verity that problem using 2014 or 2017.
Perhaps you can verify the value of number1 independently of =

That being said, as others have suggested, equal is probably the best solution until/unless you can confirm it is indeed a bug.

Have you tried this exact scenario on both AMD and Intel processors? I discovered an error on certain Intel processors that was did not exist on AMD processors. It was confirmed independently by the head of the CS department at a local university.
Proud provider of opinion and arrogance since November 22, 2003 at 09:35:31 am
CadJockey Militia Field Marshal

#### ronjonp

• Needs a day job
• Posts: 6278
##### Re: A Bug or Not A Bug
« Reply #11 on: August 02, 2017, 09:53:24 pm »
Definitely some rounding issues:
Code - Auto/Visual Lisp: [Select]
`(setq n 5.123)(rtos (* n 1000) 2 16)(= 5123 (* n 1000))(equal 5123 (* n 1000) 1e-8)  (setq n (getreal))(rtos (* n 1000) 2 16)(= 5123 (* n 1000))(equal 5123 (* n 1000) 1e-8)  ;;;_\$ ;;;;;;5.123 ;;;"5123.000000000001" ;;;T ;;;T ;;;5.123 ;;;"5122.999999999999" ;;;nil ;;;T ;;;; 8 forms loaded from #<editor "<Untitled-6> loading...">;;;_\$ `
Use equal and fuzz as mentioned above .. FWIW when comparing numbers I always use a fuzz factor that is acceptable to me.
« Last Edit: August 02, 2017, 10:12:16 pm by ronjonp »

Windows 10 x64 - AutoCAD /C3D 2018

Custom Build PC

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #12 on: August 03, 2017, 12:36:25 am »
Hi Keith, thanks for the info.
I didn't know that an Intel/AMD processor could cause this kind of error.
Unfortunately, I cannot test it as all my pc and all the machines at my workplace are with Intel CPU.

#### roy_043

• Swamp Rat
• Posts: 1450
##### Re: A Bug or Not A Bug
« Reply #13 on: August 03, 2017, 04:56:26 am »
FWIW: My tests were done on the same machine. Maybe getreal can return a 32 bit real (depending on OS or CAD program versions)?

#### MeasureUp

• Bull Frog
• Posts: 416
##### Re: A Bug or Not A Bug
« Reply #14 on: August 03, 2017, 08:26:28 pm »
Thanks Roy.
Our machines are all 64 bit OS with 64 bit AutoCAD mech 2016.
Sorry I have no chance to test the difference.

BTW it seems not much I can do because IT guys do not want to install 2017 or 2018 versions, even our company has paid for the subscription.