Blackboard variable behaviour

Wiebe van der Worp

Hi all, if I paste this on the command line:

(type (vl-bb-set (read "a-real") 5.0))
REAL
(type (vl-bb-ref 'a-real))
INT

In the last case I would have expected a real. Is this intended behaviour?

Jason Bourhill

Looks like a bug. You will need to raise an SR to get it fixed. It works as expected in AutoCAD

(type (vl-bb-set 'a-real 5.0))
REAL
(type (vl-bb-ref 'a-real))
REAL

As a workaround to force a real to be returned you could include a float call
(type (float (vl-bb-ref 'a-real)))
REAL

Regards,
Jason Bourhill
CAD Concepts

---

Come to the Australasia BricsCAD Conference

---

Wiebe van der Worp

Thanks for verifying Jason, I'll do a SR.

Roy Klein Gebbinck

If you are using the 'blackboard' for reals you should be aware that internally it stores everything in a string format. There can be precision issues.

: (vl-bb-set 'stored_pi pi)
3.14159265358979
: (equal (vl-bb-ref 'stored_pi) pi)
nil
: (- (vl-bb-ref 'stored_pi) pi)
-3.10862446895044e-015

Wiebe van der Worp

In the mean time Torsten fixed bb, thanks (and again amazing how quick)!

Roy, I assume you are pointing to the difference between equal and =. In that case...

(vl-bb-set 'stored_pi pi)

(equal (vl-bb-ref 'stored_pi) pi)
nil

... with whiskey factor
(equal (vl-bb-ref 'stored_pi) pi 0.0001)
T

... where I would expect both expressions to be True, just like:

(= (vl-bb-ref 'stored_pi) pi)

Roy Klein Gebbinck

It was my intention to discus the vl-bb-set and vl-bb-ref functions. In my example the equal function can be replaced by =. Either will do to demonstrate the issue. Basically using the 'blackboard' for reals can be problematic as there is a loss of accuracy. BTW: I have been informed that this problem does not occur in AutoCAD.

Wiebe van der Worp

Thank for clarifying, the Support Request I sent did not cover this. I noticed it involves approximately one decimal place of precision.

Torsten Moses

Dear All,

the problem with precision for "double" is a generic problem - the 14th and 15th digits are unreliable in generally, also in AutoCAD :-)
AutoCAD stores the doubles as doubles, so no problem there with double -> string -> double conversions;
BricsCAD stores doubles (for BlackBoard) as string, with 15 digits, so it is at the precision limit of what a double be be, anyway.

Even more, some numerical numbers can not be even expressed as 8-byte-double, due to the definition how a "double" uses the bits (IEEE standards), so several numerical numbers, when entered, will internally be stored as double, with unpreciseness at 15th digit.

And after a few numerical operations (multiplication, division), an initially precise double will become unprecise, at least in 15th digit.
So we think, that the storage of doubles via string should not be a real problem ... but if that turns out, it is also no problem to internally improve the BlackBoard code, using the vlo_VL custom object, as AutoCAD does here (that vlo_VL object is also used for the (vlax-ldata-xxx) function family).

many greetings !

Roy Klein Gebbinck

@Torsten Moses
I understand the limitations of reals.

IMO you have already given two good reasons to improve the BlackBoard, and I'll add a third:

1. Consistency with AutoCAD. A.k.a. compatibility.
2. Consistency with Ldata. If it is important enough for Ldata to exactly store reals (use a string representation for the list with placeholders for reals), then the same should apply to the BlackBoard.
3. Consistency with user expectations. Users will expect the BlackBoard functions to store and return values without any modifications.

Torsten Moses

Dear Roy, Dear All,

besides that the problem with precision (max. 15 digits) of doubles, becoming more & more unprecise with each numerical operation, there is indeed a valid point from Roy's "point #3", so I will improve our BlackBoard - not using vlo_VL custom objects, as AutoLISP does (overkill), with a more lightweight approach;
that will then clearly solve the issues with the sample code using doubles, but will additionally improve performance of BlackBoard operations, for plain Lisp atoms (int, real, string, ename) ...

For any other Lisp data, there are no known issues, it is also extensively tested in our test system ...
will provide updates here.

Wiebe van der Worp

I had some thoughts before Roy's post. Point 4 is the marketing element and point 5: it itches.

I agree 100% with point 3 from Roy, but at the same time every coder should also realize that a reliable equation of reals always has the form (equal real1 almost-real1 tolerance), IMHO.

For the rest of the points I will place another thread so as not to contaminate this thread. However, I would like to say that I greatly appreciate that the distance between (Lisp) users and Bricsys is so small.

Kerry Brown

@Torsten Moses said:
Dear Roy, Dear All,

that will then clearly solve the issues with the sample code using doubles, but will additionally improve performance of BlackBoard operations, for plain Lisp atoms (int, real, string, ename) ...

For any other Lisp data, there are no known issues, it is also extensively tested in our test system ...
will provide updates here.

Thanks Torsten.

@Wiebe van der Worp
I had a laugh at

5: it itches.

Torsten Moses

Dear All,

the VL BlackBoard storage is completely reworked - no problems with "doubles as string" anymore
And as a nice side-effect : (vl-bb-ref) is ~30% faster now ... but was faster by factor 4 anyway, compared to recent AutoCAD

many greetings to all & thanks for the feedback !

Wiebe van der Worp

I stop making compliments!