It looks like you're new here. If you want to get involved, click one of these buttons!

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?

## Comments

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

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

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.

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)`

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.Thank for clarifying, the Support Request I sent did not cover this. I noticed it involves approximately one decimal place of precision.

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 !

@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:

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.

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.

Thanks Torsten.

@Wiebe van der Worp

I had a laugh at

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 !

I stop making compliments!