import rhinoscriptsyntax as rs
print rs.coerce3dpoint([0.12345678901234567,0.12345678901234567,0])
0.123456789012346,0.123456789012346,0
16 decimali su 17print x
0.50436847660838,0.445806294102822,0
14 e 15 decimali in MsDprint round(0.12345678901234567,16)
0.123456789012
12 decimali su 17
ma il massimo dei decimali qual’è?
Guarda qui
sotto “Numeri da 64 bit”
La precisione decimale è di circa 16 cifre decimali.
non comprendo il “circa”
Come dice Wikipedia, i numeri sono memorizzati in binario, quindi hanno una precisione fissa in binario.
Suppongo che convertendo in decimale la precisione ottenuta non sia costante ma possa variare per numeri diversi.
quindi ritieni che sia impossibile ottenere da valori diversi lo stesso numero di decimali giusto?
quindi, la domanda corretta sarebbe: qual’è il numero massimo di decimali da poter ottenere sempre?
Se ben ricordo, generalmente, cioe’ esclusi numeri troppo grandi o troppo piccoli, 15 cifre dovrebbero essere esatte.
Ma se vuoi i particolari ci vuole qualcuno piu’ sveglio del qui presente povero vecchio stupido (e soprattutto non ancora pensionato ! 
).
Oppure ti fai una bella ricerca tu sul Web. 
EDIT:
Se vuoi sperimentare, scrivi 64 cifre binarie nel Panel e vedo che numero viene fuori.
(salvo errori, come d’uopo)
floatB.gh (8,1 KB)
15 quindi si trova con il print del MsD
mentre round su 17 decimali ed impostato a 16, ne torna 12 al massimo. limite?
Mah …
Potrebbe essere Python o IronPython o Rhino o GH o … non saprei. 
Adesso sono in ufficio, non ho modo di fare delle prove, ho solo Rhino a disposizione. 
Ho cercato informazioni …
Pare che round() non sia stata capita granche’ da alcui utilizzatori ( io, te, e anche altri … )
La spiegazione dovrebbe essere questa:
round() arrotonda il numero e lo restituisce arrotondato.
Occhio: restituisce un NUMERO, non una stringa.
Se tu stampi il risultato, Python usa la sua formattazione standard per generare la stringa da stampare.
Se vogliamo controllare, ad esempio, il numero di decimali mostrati, dobbiamo usare i soliti strumenti di Python per formattare l’output.
… Ma non ho fatto dei test … se vuoi provare tu.
grazie per la ricerca Emilio
ma io un numero gli ho dato, non una stringa. . . .
Se non ho capito male, Emilio ha detto che print usa una formattazione standard per restituirti il numero e questa formattazione probabilmente arrotonda il numero alla dodicesima cifra… quindi, anche se round ti arrotonda a 16 cifre, poi print arrotonda ulteriormente a 12 prima di trasformarlo in stringa.
ciao Lucio, ma ho usato il print su tutti gli esempi. non dovrebbe arrotondare a 12 tutti i risultati?
Non necessariamente.
Prova su altri numeri e vedi quante cifre scrive.
Il print sui punti e’ una cosa diversa: ci sara’ un metodo per i punti (forse __str__ o __repr__) scritto da McNeel che definisce il formato dell’output.
Emilio, dopo questo, io mi arrendo 
print rs.coerce3dpoint([0.1234567890123444,0.1234567890123444,0])
0.123456789012344,0.123456789012344,0print rs.coerce3dpoint([0.1234567890123444,0.1234567890123444,0])[0]
0.123456789012
mah, forse è stato fatto in modo che un punto3d deve essere più preciso si un valore numerico. . . .
edit:
con 12 decimali si dovrebbe essere sicuri, oppure potrebbe capitare un punto3d con meno numeri?
Perche’ ?
Non conferma quanto si diceva sopra ?
Numero e punto sono cose diverse. ognuno ha il suo metodo di output. 
… non capisco cosa intendi … 
Sicuri di cosa ?
Come sopra … 
Zio billy Salvio, 12 cifre dopo lo zero… e calcola che la tolleranza di modellazione si ferma molto prima… ma dove ti stai infilando? Modellazione atomica?
Edit: se per caso il problema è il poter verificare che due numeri siano uguali (o due punti siano corrispondenti) ti conviene fare un arrotondamento al valore della tolleranza impostata nel modello perché altrimenti ti ritroverai sempre con qualche malfunzionamento.
si ma non dovrebbe essere diverso in questo caso, essendo che il numero viene prima elaborato con il coerce come punto, quindi che poi mi vado a prendere solo uno dei tre valori non mi dovrebbe cambiare il risultato. (così avevo ipotizzato la “genialata” passare per il coerce) mi ha fregato 
come mi sono ritrovato che il risultato di MdSlider avesse un valore con 14 e l’altro con 15 decimali
quindi se imposto un arrotondamento a 12, sarà sempre 12 oppure può capitare 11 o 10 ecc.
eeee Lucio Lucio, come si dice: deformazione professionale, o meglio nel mio caso “caratteriale”
cerco sempre di trovare punti in comuni tra cose diverse, ma quasi mai la trovo
il discorso era di conoscere il punto in comune con il massimo di decimali
nelle varie situazioni di: Rh Gh Py usando il Coerce oppure MdSlider
la risposta e che non esiste, ma lo devi dare tu in pratica.
Come detto in precedenza: non e’ il numero che cambia.
Cambia la stringa che Rhino o GH scrivono su command area, Panel o file o dove vuoi …
E’ solo questione di formattazione per l’output.
Per avere qualcosa che noi poveri deficienti riusciamo a vedere e a capire.
Il PC e Rhino non ne hanno nessun bisogno.
Prova questo:
n = 1.0/3.0
for p in range( 20 ):
fmt = '%%.%df' % p
print( fmt % n )
Il numero e’ sempre lo stesso, cambia solo la stringa che vediamo.
Intanto io lascerei perdere l’arrotondamento.
Se quello che ti interessa e’ il numero che vedi scritto, e’ solo formattazione.
Come dicevamo ieri, riguardo alla precisione per i numeri floating point possiamo presumere che 15 cifre siano significative.
Cioe’ le prime 15 cifre sono affidabili, non dipendono da limiti del formato, ma solo dai calcoli fatti per ottenere il numero.
Occhio ! 15 cifre in totale, non 15 decimali, perche’ se il tuo numero e’ intorno a 5000, di decimali validi ce ne sarenno solo piu’ 11. E se il numero e’ intorno a 0.0003 i decimali buoni saranno 18.
Questo per quanto riguarda i numeri in se’.
Per la geometria su Rhino ti ha gia’ detto tutto Lucio.
accantonato l’arrotondamento, come potrei ottenere un punto3d
dove le tre coordinate abbiano lo stesso numero di cifre totali?