Uso di > princ >

Salve a tutti,
vorrei, per favore, conoscere il motivo per il quale questa semplicissima routine restituisce valori non esatti :


La routine restituisce :
4420568.319
698901.058
4529365.156
4.42057e+06
698901.0
4.52937e+06

dove 698901.0 è palesemente sbagliato.
Grazie.

Devi sempre partire dal presupposto che non è il programma a "sbagliare", ma che sei tu che non hai compreso cosa genera il risultato inaspettato.
Il problema sta nell'ATOF, non so perche ma (da quello che vedo) pare che restituisca sempre un risultato di 8 caratteri, punto decimale compreso.
In questo caso tronca COYY perché riesce a mettere il decimale dopo il numero completo, gli altri li mette in notazione scientifica perche con 8 caratteri non andrebbe a completare il numero (arriva fino al punto di COXX), per cui trasforma il numero in notazione scientifica, facendo entrare il punto ed usando l'ultimo carattere a disposizione come esponente (che rappresenta con e+06).
Ma tutti e dico tutti i numeri sono in qualche modo arrotondati.

In tutti i casi in Ecef1 non hai inserito lo spazio tra CoYY e CoZZ

Non è meglio costruire Ecef1 come una lista?
Il passaggio da stringhe a numeri puo dare dei problemi, ragionare direttamente con i numeri no.

Se hai un punto (punto come oggetto) AA puoi ottenere la sua lista coordinate attraverso
(setq COORD (cdr (assoc '10 (entget AA))))
e da qui ottenere le coordinate singole
(setq CoXX (nth 0 COORD))
(setq CoYY (nth 1 COORD))
(setq CoZZ (nth 2 COORD))

Poi puoi ricostruire Ecef1 con le stringhe, se proprio ti serve in formato stringa concatenata
(setq Ecef1 (strcat (rtos CoXX 2 3) ", " (rtos CoYY 2 3) ", " (rtos CoZZ 2 3)))

Grazie Cristallo,
come puoi notare le tre coordinate presenti in Ecef1 hanno lunghezza uguale, ma CoYY contiene uno spazio che viene poi eliminato da (vl-string-left-trim " " .....)
Le coordinate presenti in Ecef1 non sono quelle del Punto, ricavabili con setq COORD (cdr (assoc '10 (entget AA)))) ma formano la stringa di nome Ecef1 e quindi le devo estrarre con substr.
Rimane il quesito, perché con 7 interi + 3 decimali il risultato è giusto e con 6 interi + 3 decimali no?
Grazie.

I numeri reali sono memorizzati in formato a virgola mobile a doppia precisione, fornendo almeno 14 cifre significative di precisione, nonostante ne compaiano solo 6 nell'area della linea di comando di Autocad.
Puoi verificare con questo test:

(princ CooYY) restituisce 698901.0
(rtos CooYY 2 6) restituisce "698901.058000"

p.s. l'uso di princ presuppone l'utilizzo di una stringa, non un numero

Grazie,quindi, indipendentemente dal valore osservabile con princ, i calcoli ed irisultati vengono espressi con 14 digit di precisione.

no, sta dicendo una cosa diversa.
Se parti da un numero reale (come tipologia di dato) autocad ragiona in virgola mobile.
Se parti da un dato "stringa" no (ovviamente)
Per questo ti sto chiedendo: perchè Ecef1 è una stringa e non una lista?

GP. ha detto:

p.s. l'uso di princ presuppone l'utilizzo di una stringa, non un numero

Clicca per espandere...

A me princ restituisce anche il valore di una variabile reale, con gli arrotondamenti delle unità corrente...

Cristallo ha detto:

… Se parti da un numero reale (come tipologia di dato) autocad ragiona in virgola mobile.
Se parti da un dato "stringa" no (ovviamente)

Clicca per espandere...

Nei vari passaggi da stringa a reale, e viceversa, i valori passati corrispondono sempre.
E' nella linea di comando che non vengono visualizzate più di 6 cifre.

Cristallo ha detto:

A me princ restituisce anche il valore di una variabile reale, con gli arrotondamenti delle unità corrente...

Clicca per espandere...

Perché non supera le 6 cifre.

Grazie!