# Decimali in Rh e Gh

**URL:** <https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333>\
**Category:** Grasshopper\
**Created:** [30 Luglio 2020, 9:36am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333 "2020-07-30T09:36:06Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [30 Luglio 2020, 9:36am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/1 "2020-07-30T09:36:06Z")

</div>

> import rhinoscriptsyntax as rs
> 
> print rs.coerce3dpoint([0.12345678901234567,0.12345678901234567,0])  
> 0.123456789012346,0.123456789012346,0  
> 16 decimali su 17
> 
> print x  
> 0.50436847660838,0.445806294102822,0  
> 14 e 15 decimali in MsD
> 
> print round(0.12345678901234567,16)  
> 0.123456789012  
> 12 decimali su 17

ma il massimo dei decimali qual’è?

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [30 Luglio 2020, 9:48am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/2 "2020-07-30T09:48:20Z")

</div>

Guarda qui

> **[IEEE 754](https://it.wikipedia.org/wiki/IEEE_754)**
>
> Lo standard IEEE per il calcolo in virgola mobile (IEEE 754) (ufficialmente: IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985) o anche IEC 60559:1989, Binary floating-point arithmetic for microprocessor systems) è lo standard più diffuso nel campo del calcolo automatico. Questo standard definisce il formato per la rappresentazione dei numeri in virgola mobile (compreso ±0 e i numeri denormalizzati; gli infiniti e i NaN, "not a number"), ed un set di operazioni effettuabi...

sotto “Numeri da 64 bit”

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [30 Luglio 2020, 9:55am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/3 "2020-07-30T09:55:58Z")

</div>

> [@emilio](#):
>
> sotto “Numeri da 64 bit”

> La precisione decimale è di circa 16 cifre decimali.

non comprendo il “circa”

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [30 Luglio 2020, 10:15am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/4 "2020-07-30T10:15:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [30 Luglio 2020, 10:17am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/5 "2020-07-30T10:17:28Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [30 Luglio 2020, 10:25am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/6 "2020-07-30T10:25:02Z")

</div>

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](https://it.discourse.mcneel.com/uploads/short-url/1CvRZQQKXV0VIVlo6ZC1zTypone.gh) (8,1 KB)

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [30 Luglio 2020, 10:31am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/7 "2020-07-30T10:31:36Z")

</div>

15 quindi si trova con il print del MsD

mentre round su 17 decimali ed impostato a 16, ne torna 12 al massimo. limite?

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [30 Luglio 2020, 10:48am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/8 "2020-07-30T10:48:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [30 Luglio 2020, 10:52am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/9 "2020-07-30T10:52:13Z")

</div>

👍

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [31 Luglio 2020, 1:50pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/10 "2020-07-31T13:50:04Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [31 Luglio 2020, 2:09pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/11 "2020-07-31T14:09:32Z")

</div>

grazie per la ricerca Emilio

> [@emilio](#):
>
> round() arrotonda il numero e lo restituisce arrotondato.  
> Occhio: restituisce un NUMERO, non una stringa.

> [@0904](#):
>
> print round(0.12345678901234567,16)

ma io un numero gli ho dato, non una stringa. . . .

---

<div class="post-metadata">

**Author:** ![lucio\_zadra](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/lucio_zadra/32/16361_2.png) [@lucio\_zadra](https://it.discourse.mcneel.com/u/lucio_zadra)\
**Post date:** [31 Luglio 2020, 6:15pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/12 "2020-07-31T18:15:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [31 Luglio 2020, 6:38pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/13 "2020-07-31T18:38:06Z")

</div>

> [@lucio\_zadra](#):
>
> poi print arrotonda ulteriormente a 12 prima di trasformarlo in stringa.

> [@0904](#):
>
> print rs.coerce3dpoint([0.12345678901234567,0.12345678901234567,0])  
> 0.123456789012346,0.123456789012346,0  
> 16 decimali su 17
> 
> print x  
> 0.50436847660838,0.445806294102822,0  
> 14 e 15 decimali in MsD
> 
> print round(0.12345678901234567,16)  
> 0.123456789012  
> 12 decimali su 17

ciao Lucio, ma ho usato il print su tutti gli esempi. non dovrebbe arrotondare a 12 tutti i risultati?

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [1 Agosto 2020, 6:45am UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/14 "2020-08-01T06:45:02Z")

</div>

> [@0904](#):
>
> . 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.

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [1 Agosto 2020, 3:24pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/15 "2020-08-01T15:24:55Z")

</div>

Emilio, dopo questo, io mi arrendo 😄

> print rs.coerce3dpoint([0.1234567890123444,0.1234567890123444,0])  
> 0.123456789012344,0.123456789012344,0
> 
> print 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?

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [1 Agosto 2020, 3:54pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/16 "2020-08-01T15:54:24Z")

</div>

> [@0904](#):
>
> io mi arrendo

Perche’ ?  
Non conferma quanto si diceva sopra ?  
Numero e punto sono cose diverse. ognuno ha il suo metodo di output. 🙂

> [@0904](#):
>
> potrebbe capitare un punto3d con meno numeri?

… non capisco cosa intendi … 😕

> [@0904](#):
>
> con 12 decimali si dovrebbe essere sicuri

Sicuri di cosa ?  
Come sopra … 😀

---

<div class="post-metadata">

**Author:** ![lucio\_zadra](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/lucio_zadra/32/16361_2.png) [@lucio\_zadra](https://it.discourse.mcneel.com/u/lucio_zadra)\
**Post date:** [1 Agosto 2020, 4:17pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/17 "2020-08-01T16:17:36Z")

</div>

> [@0904](#):
>
> con 12 decimali si dovrebbe essere sicuri, oppure potrebbe capitare un punto3d con meno numeri?

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.

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [1 Agosto 2020, 5:46pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/18 "2020-08-01T17:46:29Z")

</div>

> [@emilio](#):
>
> Numero e punto sono cose diverse. ognuno ha il suo metodo di output.

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 😂 😂

> [@emilio](#):
>
> > [@0904](#):
> >
> > potrebbe capitare un punto3d con meno numeri?
> 
> … non capisco cosa intendi …

> [@0904](#):
>
> print x  
> 0.50436847660838,0.445806294102822,0  
> 14 e 15 decimali in MsD

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.

> [@lucio\_zadra](#):
>
> ti conviene fare un arrotondamento al valore della tolleranza impostata nel modello

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.

---

<div class="post-metadata">

**Author:** ![emilio](https://sea3.discourse-cdn.com/mcneel/user_avatar/it.discourse.mcneel.com/emilio/32/16095_2.png) [@emilio](https://it.discourse.mcneel.com/u/emilio)\
**Post date:** [1 Agosto 2020, 6:09pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/19 "2020-08-01T18:09:26Z")

</div>

> [@0904](#):
>
> 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.

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:

```python
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.

> [@0904](#):
>
> se imposto un arrotondamento a 12, sarà sempre 12 oppure può capitare 11 o 10 ecc.

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

---

<div class="post-metadata">

**Author:** ![0904](https://avatars.discourse-cdn.com/v4/letter/0/b3f665/32.png) [@0904](https://it.discourse.mcneel.com/u/0904)\
**Post date:** [1 Agosto 2020, 10:30pm UTC](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333/20 "2020-08-01T22:30:42Z")

</div>

> [@0904](#):
>
> print x  
> 0.50436847660838,0.445806294102822,0  
> 14 e 15 decimali in MsD

accantonato l’arrotondamento, come potrei ottenere un punto3d  
dove le tre coordinate abbiano lo stesso numero di cifre totali?

[Pagina seguente](https://it.discourse.mcneel.com/t/decimali-in-rh-e-gh/3333.md?page=2)
