in effetti il primo valore della lista come l’equivalente del componente Evaluate è sempre il Punto3D,
ma stampando la lista completa dei 3 valori in output invece compare per primo il valore Tangenza
è vero che con i decimali sopratutto in Py ci faccio spesso a testate
ma ha sempre riportato questo risultato con tanti decimali nelle liste. . . .
Non e’ una lista.
Come vedi dalle parentesi graffe, e’ un dictionary, e come sai nel dictionary i dati non sono ordinati.
Mi sembra che se ne fosse gia’ parlato … ma non ricordo cosa avevamo concluso. 
Credo comunque che sia una semplice impostazione di output …
Riguardo a EvaluateCurve:
sembra che restituisca una namedtuple,
ma sembra anche che IronPython quando la stampa la trasformi in dictionary … forse … 
sui decimali in Py ne parlammo “un bel po” se ricordo bene in Py script i decimali erano diversi da Gh
però questo mi sembra che si tratti di una “nuova” novità il fatto che se scrivo 0.1 mi ritorna 16 zeri
nella Shell non succede. chissà forse Gh usa quel vostro giochetto che eleva alla potenza un numero. . . .
delle parentesi graffe me ne ero accorto, ma in buona fede non avevo pensato che si trattasse di un dizionario e ricordo che ne abbiamo discusso un paio di volte ma che i dati non fossero ordinati
questo mi sfuggiva quindi presumo che in questo caso i valori [0] [1] [2] dell’output siano
associati come chiave al valore collegato invece di indicare la nidificazione di una lista. . . .
anche perché di dictionary le uso raramente mentre più spesso uso “SetUserText” che ipotizzo usa proprio le dictionary e in questo caso quando stampo la lista mi visualizza in ordine di come ho inserito
bella sta cosa non la sapevo che si potesse chiamare tramite il nome “point / tang / angle” invece di inserire il numeratore dell’indice 
namedtuple forse l’ho vista qualche volta ma come tante altre scritte sconosciute la ignoravo 
ps sta ad indicare che è possibile richiamare output come l’esempio che hai postato?
nel senso di avere la possibilità di usare sia gli indici [0] [1] come pure la nomenclatura?
Se glieli fai scrivere, anche con la shell vedi i tuoi bei decimali …
>>> print( '%.20f' % 0.1 )
0.10000000000000000555
Non capisco a quale giochetto ti riferisci … 
Dato che sembra essere una namedtuple, credo che l’indice funzioni come nelle liste.
Sospetto che la perdita dell’ordinamento avvenga in fase di stampa … non so perche’ (ammesso che sia cosi’).
SetUserText richiama un metodo RhinoCommon … poi cosa usi RhinoCommon non lo so … 
Esatto ! 
appunto dicevo, probabilmente in Gh questo tipo di formattazione è standar. . . .
nell’altro 3d dove parlammo dei decimali, usaste il componente “power” per verificare meglio i decimali
era quello che avevo immaginato anch’io ma poi mi son detto “è mai possibile? non credo”
(a meno che non è stato fatto di proposito. . . .)
in Py si, però intendevo anche quando lo si usa in RH e richiami tutte le chiavi
per lo meno fino adesso me li riporta in ordine di come io le ho inserite.
Penso anch’io.
E chi si ricorda … provo poi ad andare a vedere.
Non saprei proprio …
Si’, ma io non so come lo fa …
era tipo questa la situazione dove la coordinata X dava risultati come 20.0, 40.0, 180.0 e 190.0
mentre col componente Power aumentando lo slider con gli stessi valori si visualizzava il numero reale
Mah … personalmente queste discussioni su come Rhino/GH formatta l’output non mi appassionano.
Anche perche’ non conosciamo la regola seguita, quindi non c’e’ niente su cui fare affidamento.
Se vogliamo indagare sull’effettivo valore dei vari numeri conviene farlo con uno script.
Dal primo Panel sembra ci siano 4 numeri diversi dagli altri.
A questo punto sarebbe interessante sapere come vengono ricavati quei numeri.
O avere il file 3dm o la definizione che li genera.
Con i numeri a disposizione, li possiamo esaminare e cercare di capire cosa sono …
in pratica le due definizione sono identiche tranne per il fatto che una da il risultato corretto l’altra invece no
nella def cambia solo il componente Move
che in quella superiore sposta la superficie
mentre nella def inferiore sposta i punti
Crazy-Test2.gh (15,1 KB)
poi se proprio ci si vuol far male nella def sopra postata c’é una prova simpatica (nel caso mi fai sapere)
una cosa veramante particolare, i dati copiati erano tutti interi ma venivano visualizzati come float
però se nel menù della lista si da invio e come se si aggiornassero i valori a quelli visualizzati
infatti era proprio quello che mi domandavo ultimamente, credo che (se non sia stato già fatto) sarebbe opportuno delle guide su tali argomenti, per chi lavora a certi livelli immagino siano cose importanti da sapere a priori e non cercare di capire di cosa si tratta dopo che per qualche motivo sorge il problema.
ps chissà forse la conslusione è:
sia che i dati vengono copiati/importati da qualche parte
oppure generati in Rh/Gh debbono essere sempre verificati
Ma i dati originali, quelli che ci sono prima di dare invio, da dove vengono ?
Sono stati inseriti a mano ?
O derivano da qualche geometria, come nella definizione sopra ?
il problema mi era capitato su una def che stavo facendo una prova
con la def appena postata sono riuscito a replicare lo stesso problema
ed i valori che riportano questo problema sono proprio del file postato
è il risultato della coordinata x dei punti estrapolati dalla superficie
quindi ricapitolando, la def crea superficie la sposta ed estrapola i punti,
recuperi i dati dalla coordinata e facendo la prova vedrai il risultato del video.
quando sono andato a vedere i valori all’interno del componente, ed erano tutti interi, mentre nel panel mi faceva capire che alcuni avevano decimali sono rimasto sorpreso, ma poi quando cliccando invio oppure aggiungendo valori manualmente il isultato cambiava a quel punto sono rimasto proprio senza parole 
Ti dico come la vedo io … 
Separerei il problema (per chi ci vede un problema ) in due:
Prima questione:
Gia’ questo ci dice che i valori originali sono dei float,
e comunque essendo immagazzinati dentro un componente Number, anche i valori in uscita non possono essere altro che float.
Non confondere tipo di dato con valore numerico.
Un float puo’ avere benissimo un valore intero, e’ quello che di solito si scrive come:
50.0
Questo e’ un float e il suo valore e’ 50, ma resta comunque un float.
Tu che usi gli script sai bene cosa sia un tipo di dati e quanto sia importante nella programmazione.
Qui il tipo di dati e’ float e certamente non cambia di sua iniziativa.
Ci aveva gia’ spiegato tutto il nostro amico Inno:
Inoltre, trattandosi di coordinate, non c’e’ nessuna garanzia che il valore sia un numero intero.
( Se non hai appena settato tu i valori direttamente da RhinoCommon o cose simili … )
Quindi nella nostra lista potremmo avere dei valori, diciamo 50.000000 come anche dei valori 50.000001 o 49.999999 o molti altri valori diversi.
Seconda questione:
Se al componente Number attacchiamo un Panel, GH ci mostra un output costruito in un certo modo.
A quanto pare (nostra supposizione), quando lui trova un float con valore intero (come 50.000000),
lo scrive senza la parte decimale (che vale zero ovviamente).
Se invece trova un float che vale qualcosa come 50 .0000000001 o 49.999999999 (cioe’ non esattamente 50, ma molto vicino), lui lo scrive come “50.0” oppure come “5.0e+01” o una cosa simile, suppongo per indicare che non ha un valore intero.
Questa scelta naturalmente ha la sua logica, e mi sembra ‘in linea’ con altri comportamenti di GH, come quello di convertire i dati in silenzio quando puo’, diciamo usare dei “coerce” liberamente, un po’ come fa rhinoscriptsyntax.
Credo che l’idea sia quella di risparmiare tempo e spazio, a costo di rendere la logica della definizione un poco piu’ ostica da seguire in alcuni casi.
Ma penso che per GH, come per Rhino, sia richiesto un certo livello di esperienza specifica per poter utilizzare bene il software.
Se ci sono dubbi, c’e’ il forum … infatti siamo qui !
Nel fatto che editando i valori nel componente Number via Set Multiple Numbers, i valori stessi possano cambiare non vedo niente di strano.
Se tu lanci quella operazione, il componente ricavera’ i suoi nuovi numeri dal testo inserito.
Il fatto che tu aggiunga solo un newline e’ irrilevante. Se editi il testo, GH per forza deve andare a leggersi quel testo per ricavare da quel testo i nuovi numeri, non ci sono alternative.
E nella finestra di input i numeri preesistenti sono scritti come ‘50’, quindi lui legge dei valori 50.000000.
Se anche fossero stati scritti come “50.0” non cambiava nulla ovviamente.
In effetti l’unica cosa che a prima vista puo’ lasciare un po’ perplessi e’ proprio che lo stesso numero sia scritto “50” nella finestra di input di Number, ma sia scritto “50.0” nel Panel, ma pensandoci su direi che anche questo ha senso.
Nel componente Number scrivere “50” o “50.0”, come accennato sopra, non fa differenza perche’ il testo serve per l’input dei numeri e il numero ricavato dall’input e’ lo stesso in entrambi i casi.
Mentre nel Panel quel “50,0” ti da’ una informazione in piu’: ti dice che quel numero non ha un valore esattamente intero.
Number e’ un componente per l’input.
Panel e’ un componente per l’output.
Crazy-Test3.gh (7,7 KB)
Emilio ovviamente sai che non ho conoscenze teoriche di base sulla quale fare congetture o ipotesi,
alla fine le mie conoscenze sono dovute soltanto alla pratica quindi mi limito a riportare ciò che vedo:
in questo caso due cose sottolineo: la prima e che i dati li ho anche inseriti oltre che nel componente Float ho usato anche il componente Params/Primitive/Data e ovviamente il risultato sono identici
seconda cosa, assodato che Gh visualizza i numeri interi come 50 mentre visualizza 50.0 se il numero ha anche un milliardesimo di decimale e su questo capisco il concetto e anzi ne condivido anche la scelta ma a questo punto perché non vengono poi visualizzati tutti come float? deduco che il panel alla fine converte a suo piacimento indipendentemente dal formato in quale gli viene dato input.
quando si internalizza una derie di numeri in Float o anche come detto prima in Data ed il risultato visualizzato è sempre float mentre nella lista sono tutti interi credo che dipenda dal fato che la lista e come se non facesse un Refresh e quindi non aggiorna la vecchia lista input con i dati internalizzati.
io comunque ho creato una superficie identica ma già spostata più verso l’asse X e ti dico che i punti estratti senza spostarli o spostare la superficie comunque risultano alcuni con decimali e non interi.
io personalmente dal mio non sapere in una situazione simile avrei messo la mano sul fuoco sul fatto che sia spostando i punti oppure spostando la superficie o anche crearla oltre l’asse X le coordinate ricavate dovrebbero essere sempre intere mentre da ciò che ho appena detto sopra gli unici valori totalmente interi li si trova solo quando le coordinate hanno valore 0 in altri casi compaiono i decimali ma non comprendo del perché alcuni si vedono in decimali e altri invece interi questo è un mistero.
ultima cosa che domando su questo argomento che in conclusione ancora non ho ben capito:
ma quando ho a che fare con i punti e le loro coordinate per fare comparazioni verifiche ecc
come debbo fare? quali sono i componenti giusti da usare e in queli circostanze?
perché a volte funziona Equality a volte Similarity e a volte nessuno dei due.
quindi come fare per verificare le coordinate e regolarmi di conseguenza?
Ho accennato una ipotesi prima su questo.
Ma la vera ragione dobbiamo chiederla a Giuseppe o a David, se ti interessa.
Personalmente la cosa non mi disturba. So che se vedo scritto “50” puo’ anche essere un float. OK.
Se si tratta di coordinate, o pesi o nodi, sicuramente sono dei float
E in ogni caso, se non so se certi valori nella mia definizione sono int oppure float, direi che forse e’ meglio fare una pausa perche’ sono un po’ troppo confuso.
Questa e’ un’altra questione.
Riguarda le geometrie di Rhino.
Finche’ l’errore e’ minimo, io non vedo problemi.
In pratica, se lavori con tolleranza 0.001 e alcune coordinate sono traslate, per cosi’ dire, di 0.000001, non ci vedo niente di strano.
Cosa ci fa Rhino con le coordinate poi io non lo so.
Ma a livello di curiosita’ ovviamente possiamo chiedere lumi a Giuseppe.
Come gia’ consigliato anche nella vecchia discussione …
Testare se due float sono uguali solitamente ha poco senso.
E’ meglio testare se la differenza tra i due e’ minore di una certa tolleranza.
Purtroppo non li conosco bene … 
Ma vedo che c’e’ anche Equality Within Tolerance, che potrebbe essere quello che serve per controllare se due coordinate sono “uguali” ai fini pratici.
Quali sono questi casi in cui i componenti che citi non funzionano ?
Un esempio pratico.
La definizione deve selezionare le curve appartenenti a un piano Z=4.4.(per effettuare il fillet)
Il confronto viene fatto con la Z del punto medio di ogni curva
Con Similarity o Equality Within Tolerance pur con una tolleranza pari quasi a zero si ha un risultato corretto mentre con Equality alcune curve non vengono rilevate.
si infatti oltre a quello che hai fatto notare la differenza tra Equality e Similarity
io ho un dubbio: visualizzando input del Multiplication il tutto rimangono sempre punti
mentre in Equality un punto viene trasformato in numero
mi domando con Equality i due input li compara come numeri?
perché in questo caso potrebbe capitare che due punti differenti possono dare lo stesso numero?
Dalla definizione si vede che i punti che sono in qualche modo simmetrici all’origine danno un identico risultato.
punti.gh (14,0 KB)
ecco scoperto l’arcano che mi cruciava da tempo. . . .
quindi il risultato che veniva trasformato da Equality e Similarity era quello trigonometrico
hai visto alla fine anche in un post “Tanto per” si impara sempre qualcosa di nuovo
(per la serie: anche nel mare morto ci sono pesci vivi)
quindi Leopoldo confermi i miei dubbi, in questi casi non’é un buon sistema usare questi due componenti
riportando valori uguali non’è possibile fare nessuna comparazione o per lo meno ne torna una non veritiera
io ultimamente mi sto orientando con i componenti Sets che se ho afferrato bene trasforma input in testo
e quindi per lo meno i dati da confrontare se sono punti quindi con coordinate xyz rimangono invariati
nel caso si vuole una precisione particolare o un arrotondamento con dei decimali lo si fa prima dell’input
solo che a parte che conosco un pochino solo un paio di questi componenti gli altri non li so gestire,
e quindi ho il dubbio se sia una strada corretta da seguire e se ci sono componenti giusti per farlo. . . .
