use di ▪

[Angelo2449]

Hello everyone,
I would like, please, to know why this simple routine returns non-exact values:

(defun c: ecef (/)

(setq eck1 "4420568.319, 698901.058.4529365.156")

(setq cooxx (atof (vl- string- left- trim "" (substr eck1 1 11))); corordinata ecef x
(setq cooyy (atof (vl- string- left- trim "" (substr eck1 13 11)))
(setq coozz (atof (vl- string- left- trim "" (substr eck1 25))); corordinata ecef z

(pr "n")
(prc (vl- string- left- trim ")
(pr "n")
(prc (vl- string- left- trim ")
(pr "n")
(prc (vl- string- left- trim ")

(pr "n")
(cooxx trap)
(pr "n")
(cooyy prince)
(pr "n")
(coozz snap)
(pr "n")
)

the routine returns:
4420568.
69890
4529365.156
4.42057e+06
69890
4.52937+06

where 698901.0 is clearly wrong.
Thank you.

 

[Cristallo]

You must always assume that it is not the program to "wrong", but that it is you who did not understand what generates the unexpected result.
the problem lies in the atof, I don't know why but (from what I see) it seems that it always returns a result of 8 characters, decimal point included.
in this case trunca coyy because it manages to put the decimal after the full number, the others put them in scientific notation because with 8 characters it would not go to complete the number (arrive up to the point of coxx), so it turns the number into scientific notation, making enter the point and using the last character available as exponent (which represents with e+06).
but all and I say all the numbers are somehow rounded.

in all cases in ecef1 you did not enter the space between coyy and cozz

is it not better to build ecef1 as a list?
the passage from strings to numbers can give problems, reason directly with the numbers no.

if you have a point (point as object) aa you can get its coordinate list through
(setq coord (cdr (assoc '10)))
and from here get the individual coordinates
(setq coxx (nth 0 coord)
(setq coyy (nth 1 coord)
(setq cozz (nth 2 coord)

then you can reconstruct ecef1 with strings, if you just need it in chained string format
(setq ecef1 (strcat (rtos coxx 2 3) ", " (rtos coyy 2 3) ", " (rtos cozz 2 3))

 

[Angelo2449]

thanks crystal,
as you can notice the three coordinates present in ecef1 have equal length, but coyy contains a space that is then deleted from (vl-string-left-trim "....)
the coordinates present in ecef1 are not those of the point, obtained with setq coord (cdr (assoc '10 (entget aa)))) but form the string of name ecef1 and therefore I have to extract them with substr.
remains the question, because with 7 whole + 3 decimals the result is right and with 6 whole + 3 decimals not?
Thank you.

 

[GP.]

real numbers are stored in double precision mobile comma format, providing at least 14 significant precision figures, despite compaiano solo 6 in the autocad command line area.
you can check with this test:
(princ cooyy) re-establishment 698901.0
(Cooyy 2 6) re-establishment "698901.058000"

p.s. the use of princ presupposes the use of a string, not a number

 

[Angelo2449]

Thank you, therefore, regardless of the observed value with princ, calculations and results are expressed with 14 precision digits.

 

[Cristallo]

No, he's saying something different.
if you start from a real number (as type of data) autocad reason in mobile comma.
if you leave from a given "stringa" no (obviously)
for this I am asking you: why ecef1 is a string and not a list?

 

[Cristallo]

p.s. the use of princ presupposes the use of a string, not a number

to me princ also returns the value of a real variable, with roundings of the current units. . .

 

[GP.]

... if you start from a real number (as type of data) autocad reasons in mobile comma.
if you leave from a given "stringa" no (obviously)

in the various steps from string to real, and vice versa, the past values always correspond.
It's in line di command who are not coming view more than 6 digits.

to me princ also returns the value of a real variable, with roundings of the current units. . .

Perched not supera 6 cifre.

 

[Cristallo]

 

[Angelo2449]

Grazie!