Libraries & objects
About Archicad and BIMcloud libraries, their management and migration, objects and other library parts, etc.

'Use of real types can result in precision problems'

Durval
Booster
When trying to edit, in AC9, an object created by AC7, I get the message on the title of this post when the 'Check Script' button is pressed. I haven't changed anything in the scripts yet.
The line where the warning points to have IF statements like these:
IF B=0 THEN ....
IF anyparameter<>0 THEN...
Despite the warnings, the object seems to work perfectly.
What 'real types' is AC talking about??
--- www.dtabach.com.br ---
AC 24 BR – MacBook Pro 2,9 GHz Intel Core i7 16GB RAM Mac OS 10.14
23 REPLIES 23
Karl Ottenstein
Moderator
Hi Durvall,

I answered this here:
http://archicad-talk.graphisoft.com/viewtopic.php?p=24377#24377

AFAIK, this is only a checkscript warning/aid ... and will not affect the running of an otherwise correct script.

Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Anonymous
Not applicable
I have run into problems like this with real numbers when using calculated values in conditional statements.

I have had code like this fail:
IF angle = 90 THEN...
...and replaced it with the following which worked:
IF angle > 89.99 & angle < 90.01 THEN...
Durval
Booster
Karl wrote:

AFAIK, this is only a checkscript warning/aid ... and will not affect the running of an otherwise correct script.


In the referred script, I have tens of IFs triggering that warning. So, I wouldn't call it an 'aid', because it is very annoying having to click again and again the 'continue' button every time I need to check for actual errors. I must find a way to get reed of the 'aid', to preserve my finger and my mental health...
I found out that replacing 'IF parameter=0 THEN...' by 'IF NOT(parameter) THEN...' removes the warning. But in other cases, I still didn't figure an efficient alternative.
Matthew wrote:

I have had code like this fail:
IF angle = 90 THEN...

...and replaced it with the following which worked:
IF angle > 89.99 & angle < 90.01 THEN...


What if your angle is 89.991? IMHO, this is actually the one that 'can result in precision problems'... Maybe 'IF NOT(angle-90) THEN...' is a better option. I will test it now.
--- www.dtabach.com.br ---
AC 24 BR – MacBook Pro 2,9 GHz Intel Core i7 16GB RAM Mac OS 10.14
Anonymous
Not applicable
Durval wrote:
Matthew wrote:

I have had code like this fail:
IF angle = 90 THEN...

...and replaced it with the following which worked:
IF angle > 89.99 & angle < 90.01 THEN...


What if your angle is 89.991? IMHO, this is actually the one that 'can result in precision problems'... Maybe 'IF NOT(angle-90) THEN...' is a better option. I will test it now.
If you need tighter precision use 89.9999. I can't believe that a accuracy to 1/10,000 of a degree can possibly matter to you.

The NOT() function may only work with boolean (true/false, checkbox) parameters. I'd be curious to know if it works though.
Karl Ottenstein
Moderator
Durval wrote:
In the referred script, I have tens of IFs triggering that warning. So, I wouldn't call it an 'aid', because it is very annoying having to click again and again the 'continue' button every time I need to check for actual errors. I must find a way to get reed of the 'aid', to preserve my finger and my mental health...
I agree. There should be some preference settings for Check Script. Want to post it to the wish list?

Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Karl Ottenstein
Moderator
Matthew wrote:
IF angle = 90 THEN...
It is perhaps better to use:
epsilon = 0.001 
... 
IF ABS(angle-90) < epsilon THEN 
where you can specify epsilon once in the master script, for example.

Durval's
IF NOT(angle-90) THEN
is no different than saying angle=90, and so would still have potential representational/precision errors and fail (unless the NOT operator does more than zero/non-zero testing and tests for an epsilon factor).

Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB
Durval
Booster
Matthew wrote:
If you need tighter precision use 89.9999. I can't believe that a accuracy to 1/10,000 of a degree can possibly matter to you.

The accuracy should suffice if value of 'angle' is directly typed by user. But if 'angle' stores a results from a formula in the script, even 1/1,000,000 could lead to 'precision problems', couldn't it?
Matthew wrote:
The NOT() function may only work with boolean (true/false, checkbox) parameters. I'd be curious to know if it works though.

Yes, it works, I just tested. 'NOT(x)' results true if x=0, and results false if x is anything but zero (not necessarily 1).
--- www.dtabach.com.br ---
AC 24 BR – MacBook Pro 2,9 GHz Intel Core i7 16GB RAM Mac OS 10.14
Durval
Booster
Karl wrote:
Durval's
IF NOT(angle-90) THEN
is no different than saying angle=90,...
...but NOT(angle-90) doesn't trigger the precision warning, while angle=90 does, god knows why....
--- www.dtabach.com.br ---
AC 24 BR – MacBook Pro 2,9 GHz Intel Core i7 16GB RAM Mac OS 10.14
Karl Ottenstein
Moderator
Durval wrote:
...but NOT(angle-90) doesn't trigger the precision warning, while angle=90 does, god knows why....
It sort of makes sense to not trigger the warning since the result is to be used for simply a zero/non-zero test ... sort of a boolean conversion. Still subject to problems, but I imagine that's their logic.

The point I was trying to make is that the warning could be real, and I wanted to make sure that less experienced GDL programmers didn't use your 'trick' of NOT(expression) to make the message go away, when really they need the 'epsilon' code for the code to work properly.

For example, in you case, if you KNOW that angle is going to 'snap' to 90, 180, 270, and 0, then your code is fine. The value of 90 may not really be 90 exactly (binary rep), but the representation of 90 will always equal the representation of 90. Right?

But, if the angle is computed, then it is very possible that a value of 90.000000001 or 89.9999999999 might result (or whatever) ... in which case your test for 'equality' would fail, even though the numbers are, from a computer math point of view, really equal.

As an addition to the wish for always turning the warning on or off globally, we could ask that GDL include PRAGMAS as in other languages, so that we could write something like:
#PRAGMA noerrorchecking
IF angle=90 THEN ...
#PRAGMA errorchecking
To turn the warning off on code that we know is fine.

Karl
One of the forum moderators
AC 27 USA and earlier   •   macOS Ventura 13.6.6, MacBook Pro M2 Max 12CPU/30GPU cores, 32GB