lo so che ho detto di averci messo una pietra sopra, ma questa cosa mi fa
nella lista del componente “float” contiene una serie di valori numerici di cui 20 valori 40
comparo con il componente “=” con il valore float 40 ma la somma del risultato è di 12
nella parte superiore ho fatto una controprova che conferma quanto scritto sopra
e la somma conferma le 20 unità 40 a differenza della somma 12 nella parte inferiore
i valori sono tutti float, quindi mi chiedo come mai succeda questo? sbaglio qualcosa?
come si può vedere dai pannelli selezionati “verdi” sono tutti float
è una lista di punti estrapolando per fare una prova solo l’asse X
nel rettangolo rosso puoi vedere il raggruppamento dei valori
Se non ho capito male il problema è:
c’è una lista che contiene diversi elementi di cui 20 sono identici ma la definizione di Salvio ne rileva solo 12.
ciao Emilio
nello spazio 1 il totale dell’elemento 40 è 12
nello spazio 2 il totale dell’elemento 40 è 20 (cioè risultato corretto)
ho ordinato tutti i risultati, è come si nota nel panel i numeri 40 ne sono 20
e nel secondo panel (confrontando l’indice) sono tutti e 20 dei float
come anche il num 40 di confronto in basso a sinistra
preciso che il problema viene risolto in due modi: o usando il componente integer
oppure inserendo all’uscita della lista, l’espressione round(x,3) “credo sia la strada più corretta”
ps qualcuno sà, se il componente member index converta i valori in testo?
infattio avevo il dubbio, che con i componenti set ricordavo che trattavano stringhe di testo
quindi avevo ipotizzato una conversione interna del componente.
ma questi problemi di arrotondamento in Gh già ne avevo parlato tempo fa
ma allepoca se non erro, nella lista compariva una differenza visiva del tipo:
una parte dei numeri veniva visualizzata come intera 1 e l’altra parte come float 1.0 ma entrambe float
ovviamente tutti elementi della stessa lista.forse queste differenze è dovuta di codici diversi nei componenti
I “Panel” di grasshopper non dicono tutto. Anzi, principalmente danno solo indicazioni di massima.
Fare ragionamenti solo tramite screenshot è veramente poco utile. Sicuramente inefficiente.
Puoi caricare il file .gh ?
spero che mi perdoniate se non posto la definizione,
nel caso se riesco a replicare in altro modo vi aggiorno
nel frattempo dopo la risposta di Emilio: (che mi ha fatto riflettere su un ragionamento importate)
sono andato a controllare i dati e anche li non ho trovato nulla di strano sono tutti numeri come da foto,
tranne una cosa, se faccio una qualsiasi azione nella casella “Set Multiple Numbers” premere invio ecc
il risultato della lunghezza lista che prima dava 12 adesso si è aggiornato e riporta il totale giusto cioè 20
Leopoldo, come puoi vedere dalla foto ho fatto anche un secondo controllo
in pratica non’é come si era ipotizzato, infatti se si collega a M una Stringa mentre in S dei Float torna 0
mentre invece con il componente Equals in questo caso anche se input è una stringa viene convertito
se può interessare, il link che ho postato nel forum americano è collegato a questo
sembra che il problema originale sia come viene creata/estrapolata la superficie @inno nella sua definizione usa PlaneSrf e non c’é il problema di convertire i valori
come sottolineato da @RiccardoMajewski , il Panel ti mostra qualcosa ma non tutto
in particolare, prendendo dal tuo esempio ricostruito un po’ alla meno peggio, se prendi i valori che il panel ti mostra come integer (nel senso che non venendo rappresentati con punto+decimali sembrano essere integer, ma in verità non lo sono) e li moltiplichi per 10, 100, 1000 and so on, cominciano a venir fuori i “decimali occulti” che rovinano tutto (riposto dal forum us)
@inno ti rispondo qui anche perché è collegato a come è nato questo post (nel caso chi vuole verificare)
come mostravo nel mio messaggio n°13, se si prendono i valori del PointToNumber, e li si internalizzano a NumberDecimal, verificando i valori nel “Set Multiple Numbers” si può constatare che sono tutti interi
ma restituiscono lo stesso il problema, a meno che non “si prema invio ecc” nella casella di testo
(sembra che i valori decimali rimangano memorizzati in latenza fino a quando non si aggiornino)
non proprio
quando vai “in sovrimpressione” con il puntatore del mouse su un output, GH poppa la finestrella gialla con i valori che l’output stesso contiene, proprio come se avessi temporaneamente collegato quell’output a un Panel per vederne il contenuto
quella finestrella segue tutte le “regole” del Panel, ovvero se un float contiene abbastanza decimali che son tutti zeri, allora te ne mostra solo la parte intera
questo significa che, quando colleghi un panel all’output, tutti quei float che sono 50.000000000000001217 (per esempio) te li fa vedere come “50 e basta”, ma in realtà è solo questione di rappresentazione numerica: il valore di quel “50 e basta” è in verità sempre “50.000000000000001217”
in GH, a meno che tu non forzi un valore ad essere int (ovvero numero intero, punto, di cui non esiste la parte decimale: non è che è punto zero zero zero… non esiste il punto, tipo se si parla di indici) questo non sarà mai int “nativo”
anche uno slider settato sui soli Naturali ti outputta dei float
quindi l’output di PointToNumber outputta dei floats, sebbene il Panel ti mostri solo la parte intera dei float perchè la parte decimale differente da 0 è abbastanza lontana
per la domanda non chiesta “ma perchè generando dei punti su quella faccia perfettamente piana sul piano YZ ottengo dei punti che sembra non giacciano su quello stesso piano YZ???” penso sia tutta una questione di tolleranze (infatti i decimali hanno molti zeri dopo la virgola…) il punto di interesse rimane comunque di non comparare i float
@inno come dicevo, intendevo una volta internalizzati i valori all’interno della casella di testo
riscontrerai tutti numeri interi e si presenta il problema, ma avendo accortezza di fare questa prova:
calcelli un valore qualsiasi oppure in fondo alla lista elimini o aggiungi un rigo tutto funziona perfettamente
(quindi i valori internalizzati che prima rimanevano float, dopo questa prova vengono visti come interi)
secondo me c’è un discorso da fare a monte per non far confusione
una cosa sono gli int, ovvero che non possiedono una parte decimale, come gli indici di una lista, tipo il numero schietto “3” o “921”
se parliamo di float, tipo il valore “3.000” questo ha una “parte intera” uguale a 3, ma non è un intero
possiam dire che 3.000 sia “un numero tondo” nel senso che ha decimali che son tutti zeri
secondo me quando dici: quindi i valori internalizzati che prima rimanevano float, dopo questa prova vengono visti come interi
intendi dire: quindi i valori internalizzati che prima rimanevano float, dopo questa prova vengono vistiancora come float, ma tutti numeri tondi
quello che viene fatto passare dentro un Panel, in uscita del Panel stesso è sempre String
in particolare, l’uscita String è quello che viene visualizzato all’interno del Panel stesso
nel passaggio nel Panel, la trasformazione Float → String fa perdere le informazioni decimali che erano contenute nel Float (perchè il Panel stesso le trimma via, non visualizzandole)
esatto sicuramente questa descrizione che hai dato è più idonea.
fermo restando di aver compreso, tutti i discorsi che hai evidenziato
sottolineavo il fatto “particolare” bisogna fare quell’operazione per resettare i valori nel componente float
adesso che mi viene in mente ho spesso riscontrato lo stesso problema con il componente Cluster In/Out.
