RTOS - where are added digits coming from?

[hencoop]

Hello all,

This code returns some non-zero digits beyond those supplied, I.e., "0.1234567890001017".  How and why?  I'm just curious.  I don't need this solved for any particular use.

(RTOS (REM 1234.1234567890 1.0) 2 16)

[ВeekeeCZ]

You will have to dive into mathematics. IMHO it's simply beyond the capabilities of a double-precious floating-point system HERE 

[hak_vz · Accepted solution]

For simple explanation check this link that talks about floating point number precision 

For huge and detailed math regarding this issue check "What Every Computer Scientist Should Know About Floating-Point Arithmetic ".

If you are even more curious you can check my code that I shared here about continuous fractions and google about this subject.

[hencoop]

@ВeekeeCZ & @hak_vz, Thanks for the info.

I provided a real number of a fixed value.  it is still not at all clear how that number can change unless the result of RTOS is in error... (admittedly, at a precision level that is entirely negligible).

It is my understanding that the result should match the original:

(from https://en.wikipedia.org/wiki/Double-precision_floating-point_format)

"The 53-bit significand precision gives from 15 to 17 significant decimal digits precision (2−53 ≈ 1.11 × 10−16). If a decimal string with at most 15 significant digits is converted to IEEE 754 double-precision representation, and then converted back to a decimal string with the same number of digits, the final result should match the original string. If an IEEE 754 double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number."

(emphasis added)

Again, it's not a problem.  I just wondered why it is not the same.  It appears to be a deeper programming discussion than the Wikipedia article addresses (or I didn't read far enough into it).

[ВeekeeCZ · Accepted solution]

The issue is the precision of REM calculation, not RTOS conversion.

Command: (- (REM 1234.1234567890 1.0) 0.123456789)
1.0171e-13

[hencoop]

@ВeekeeCZ Indeed!

Nevertheless, it makes no sense to me that REM would do anything other than strip off the decimal portion when the divisor is 1.0 (or even 1)

(RTOS (REM 1234567.1234567890 1) 2 16) returns "0.1234567889478058"

as does (RTOS (REM 1234567.1234567890 1.0) 2 16)

It just seems so imprecise.  Perhaps it is related to why LUPREC has a max value of 8.

REM uses LUPREC to determine what is displayed in the VLIDE console and the display from REM cannot be  set otherwise.  (REM 1234567.1234567890 1.0) returns 0.123457 when LUPREC=8.  I began using RTOS precisely to have all of the available digits displayed regardless of LUPREC.  It seems it would be best to make sure that I only use the precision of the input as that is all that will be returned correctly (should I ever need more than 3or 4 decimal places of precision).

[hencoop]

@hak_vz  Thanks!

That microsoft link does explain it simply.  I already use (EQUAL x y 0.001) very often.  I just never knew why it was so necessary.  Now I do.

[hak_vz]

As @ВeekeeCZ pointed out

 (- (REM 1234.1234567890 1.0) 0.123456789)  --> 1.0171e-13

Real numbers are stored in double-precision floating-point format, providing at least 14 significant digits of precision. This is at the edge of number precision.  If really needed to retain maximal precision 1e-8  is enough.

[ВeekeeCZ]

I just know that REM is not a very popular func and many trying to avoid using it. Not sure whether is generally low precision or some other systematic issue. I'd have to do some research if I was interested.

[hencoop]

@ВeekeeCZ  I was trying to fix the value so I could write it out to a file and make sure it was not in exponential notation.  As a test for my code I picked an unreasonable number, 1234567890.1234567890, which lead to my post.  The actual numbers that I am writing out are very well behaved in terms of significant digits.

Here's the code I used:

(IF (EQ (TYPE (EVAL (READ (CAR n)))) 'REAL)
  (PRIN1 (STRCAT "(" (CAR n) " . "
                 (IF (EQ (REM (EVAL (READ (CAR n)))1.0) 0.0)
                   (STRCAT (RTOS (EVAL (READ (CAR n))) 2 2)".0")
                   (STRCAT (CAR (DOS_STRTOKENS (RTOS (EVAL (READ (CAR n))) 2 2) "`."))
                           "."
                           (CADR (DOS_STRTOKENS (RTOS (EVAL (READ (CAR n))) 2 16) "`."))
                   )
                 )
                 ")"
         )
         atomsout
  )
  (PRIN1 (CONS (CAR n) (EVAL (READ (CAR n)))) atomsout)
)

[john.uhden]

Well, @hencoop, the key thing is to realize that 'REALs are not exact.

Thus the use of (equal) to bring perceptive reality into place.  Just use the fuzz factor that is appropriate.

F'rinstance, we civil/survey types don't care if the monument location is a hundredth or three off.  It's close enough to being dead on.  But 0.3' off requires notation because it's outside the head.  Plus, it may have been run over by a garbage truck or snow plow or any contractor with heavy equipment, so it's still a valid indication of where the property corner is.

My @$$hole neighbor didn't like our monument sticking out of the ground by 3 inches, so he had his landscaper push it into the ground

[ronjonp]

@hencoop Have you see the 'tostring' function by Michael Puckett ?

(defun ToString ( x / typex )

    ;;  convert item to a string, if x is a real use
    ;;  the highest possible precision, if x is a
    ;;  string double quote it, if x is a list process
    ;;  each item in the list appropriatel, otherwise
    ;;  just hammer item with vl-princ-to-string

    (cond

        ;;  it's a string, return it double quoted

        (   (eq 'str (setq typex (type x)))

            (strcat "\"" x "\"")

        )

        ;;  it's a real, covert to the highest possible
        ;;  resolution string equivalent

        (   (eq 'real typex)
       
            (rtos x 2 (if (zerop (- x (fix x))) 1 15))

        )

        ;;  it's a list

        (   (eq 'list typex)

            (if (vl-list-length x)

                ;;  it's a normal list

                (strcat
                    (chr 40)
                    (ToString (car x))
                    (apply 'strcat
                        (mapcar
                           '(lambda (x)
                                (strcat " " (ToString x))
                            )
                            (cdr x)
                        )
                    )
                    (chr 41)
                )

                ;;  it's a dotted pair

                (strcat
                    (chr 40)
                    (ToString (car x))
                    " . "
                    (ToString (cdr x))
                    (chr 41)
                )

            )

        )

        ;;  hammer down on everything else

        ((vl-princ-to-string x))
    )
)

[john.uhden]

Well, @hencoop, the key thing is to realize that 'REALs are not exact.

Thus the use of (equal) to bring perceptive reality into place.  Just use a fuzz factor that is appropriate.

F'rinstance, we civil/survey types don't care if the monument location is a hundredth or three off.  It's close enough to being dead on.  But 0.3' off requires notation because it's outside the head.  Plus, it may have been run over by a garbage truck or snow plow or any contractor with heavy equipment, but it's still a valid indication of where the property corner is.

My @$$hole neighbor didn't like our monument sticking out of the ground by 3 inches, so he had his landscaper push it into the  ground, out of sight.  It probably shifted a little, but not enough to worry about what I own.  My deed is quite clear.  I oughta know because I wrote the description myself.