Blackboard variable behaviour

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.

  • Roy Klein Gebbinck
    edited January 2019

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

    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.
  • 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.

  • @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.

  • Dear All,

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

    many greetings to all & thanks for the feedback !

  • I stop making compliments!
    ;)