Cattiva divisione?Supponiamo di avere questa tabella:
| Categoria |
Articolo |
Livello |
| A |
1 |
delta |
| A |
2 |
foxtrot |
| A |
3 |
albergo |
| B |
1 |
Giulietta |
| B |
3 |
cinque |
Si noti che manca Categoria=B, Articolo=2.
Se provo a "dividere" questa tabella con "Dividi per" = Categoria e "Dividi colonne" = Livello e "Mantieni tutto", restituisce quanto segue:
| Articolo |
A |
B |
| 1 |
delta |
Giulietta |
| 2 |
foxtrot |
cinque |
| 3 |
albergo |
|
Si noti che nella tabella appena divisa, viene visualizzato "lima" come Item=2,Category=B, ma ciò non è corretto: la cella dovrebbe essere vuota e "lima" dovrebbe trovarsi sotto Item=3,Category=B.
Si tratta di un errore dell'utente o di un bug di JMP?
Combinazione e pulizia dei datiRi: Stacking errato?Ciao @BHarris , prova a usare Item nel gruppo. Il risultato sarà quello che ti aspetti.
Migliore,
Ri: Stacking errato?Sì, sembra funzionare.
Puoi spiegare cosa sta succedendo? Vorrei capire perché il passaggio di gruppo è stato necessario.
Ri: Stacking errato?Certo, la suddivisione senza il gruppo avviene letteralmente per riga e non si rende conto che l'elemento ha un componente mancante per la categoria. Il gruppo forza il livello a separare per elemento per ogni categoria, esaminando prima l'elemento e poi la categoria.
Dalla guida in linea ( https://www.jmp.com/support/help/en/18.2/?os=mac&source=application#page/jmp/split-columns-in-data-tables.shtml
Gruppo
Specifica una variabile Gruppo quando si desidera che i dati vengano suddivisi all'interno di ciascun gruppo della variabile selezionata. Ogni gruppo genera una riga nella tabella di output. È inoltre necessario specificare le variabili richieste, Dividi per e Dividi colonne.
Nota: se la variabile in base alla quale si desidera effettuare il raggruppamento contiene gruppi non uguali o è in ordine casuale, specificandola come variabile Gruppo si garantisce che i dati vengano ristrutturati correttamente e che gli eventuali valori mancanti vengano assegnati nei punti appropriati.
Altrimenti dovresti inserire una riga extra e definire Categoria e Articolo, ma lasciare vuoto il Livello per quella riga.
Spero che questo ti sia d'aiuto.
Ri: Stacking errato?Più ci penso, meno ha senso. Non capisco perché split dovrebbe comportarsi in questo modo in nessuna circostanza, quasi come se gli sviluppatori avessero semplicemente annidato dei cicli e sperato che i dati si trovassero nei punti giusti...
Mi chiedo se (a) sono ancora troppo stupido per capire la logica alla base di questo comportamento, (b) è stato implementato in questo modo per offrire prestazioni elevate (divisioni rapide su tabelle di grandi dimensioni) dove gli input sono fattoriali e ci si aspetta che l'utente sappia che si sta facendo questa ipotesi, oppure (c) è solo un bug che deve essere segnalato/corretto.
(Non mi offenderò se è (a).;) )
Ri: Stacking errato?Puoi spiegare meglio i tuoi pensieri?
Io sosterrei il contrario:
Se i dati di input sono ben strutturati, è possibile dividerli senza dover prestare alcuna attenzione.
Se i dati di input non sono ben strutturati, ma contengono anche alcune informazioni di raggruppamento, è sempre possibile utilizzare queste informazioni per indicare a JMP cosa deve fare.
Cosa non funziona:
l'utente conosce le informazioni di raggruppamento (c'è la colonna) ma non le comunica a JMP (tramite l'interfaccia grafica).
Non c'è da stupirsi che JMP non utilizzi le informazioni di raggruppamento.
[ci sono altri casi in cui JMP applica alcune ipotesi | correzione automatica - e l'utente si interroga sulla creatività].
Ri: Stacking errato?Cosa pensi del set di dati fornito nella domanda originale? È "ben strutturato"?
E cosa pensi del comportamento attuale di JMP quando si divide quella tabella?
A quanto ho capito, le colonne "Dividi per" sono quelle con i valori che si desidera vengano inseriti nelle intestazioni di colonna della nuova tabella, mentre le "Dividi colonne" sono le colonne i cui valori si desidera vengano inseriti nelle celle di quelle nuove colonne. Non capisco ancora cosa significhi "raggruppamento" in questo contesto.
Ri: Stacking errato?La tabella dati iniziale è "ben strutturata".
Il concetto di raggruppamento può essere concepito in termini di quali righe nella tabella dei dati di input devono essere raggruppate per definire una riga di output specifica.
Ri: Stacking errato?Un altro modo per spiegare:
Le tue colonne "Categoria" e "Livello" (da sole) non sono ben strutturate: sono necessarie alcune informazioni aggiuntive come
@BHarris ha scritto: Si noti che manca Categoria=B, Articolo=2.
per informare gli altri del fatto: tra la riga n. 5 e la riga n. 6 manca qualcosa.
Caso n. 1:
L'utente non comunica a JMP l'esistenza della colonna "Item" ("Item" non è utilizzato nella GUI **)
In tal caso, JMP non dispone delle conoscenze sufficienti per svolgere correttamente il suo lavoro.
Caso n. 2:
C'è una terza zona di rilascio. Permette all'utente di utilizzare
@BHarris ha scritto: Si noti che manca Categoria=B, Articolo=2.
in modo strutturato, come colonna di raggruppamento .
Il "raggruppamento" si adatta molto bene a ciò che desideri:
Fornire a JMP informazioni aggiuntive in modo che le voci possano essere inserite in righe specifiche, determinate non in base al Rank(riga(), Categorie) dei dati di input, ma raggruppate tramite colonne di raggruppamento.
**) modificare:
"Item" viene utilizzato nella GUI - implicitamente tramite Mantieni tutto
ma questo è troppo "passivo" - vedi sotto.
Ri: Stacking errato?@hogi -- qui hai storto qualcosa, ovvero l'idea che non avessi incluso la colonna Item da nessuna parte nell'interfaccia, e quindi si sottintende che forse l'algoritmo Split non sia nemmeno a conoscenza della sua esistenza.
Credo di aver pensato che *tutte* le colonne fossero importanti nell'operazione Dividi e che si cercasse di mantenere tutte le relazioni possibili, ad esempio che "lima" fosse associato solo all'elemento "3". Ora devo capire se tutte le altre colonne debbano essere colonne di raggruppamento se imposto "Mantieni tutto"...
Un giorno spero di raggiungere lo status di JMP-Master e di essere pienamente illuminato, e forse allora capirò perché JMP non utilizza implicitamente tutte le altre colonne "Mantenute" nel ruolo Gruppo. Fino ad allora, probabilmente continuerà a rendermi nervoso, poiché il suo comportamento in queste condizioni non è ovvio, produce dati di output errati in condizioni che potrebbero essere difficili da identificare e non è sufficientemente documentato per poterlo comprendere. Almeno questo nervosismo mi manterrà più vigile in futuro quando lo userò.
Grazie.
Ri: Stacking errato?L'hai menzionato, ma forse è utile scriverlo esplicitamente:
JMP applica la regola:
- Gruppo : conserva e usa per raggruppare
- Mantenere : tieni (~ non far cadere)
@BHarris ha scritto:
Ora devo capire se tutte le altre colonne dovrebbero essere colonne di raggruppamento se imposto "Mantieni tutto"...
Immagino di sì.
Potresti provare entrambe le soluzioni, verificare le differenze e poi decidere.
Il gruppo ti aiuta a "strutturare" i dati. Se i dati sono già strutturati, non guasta. Se non lo sono, garantirà un output significativo.
Con Mantenere devi sapere con estrema precisione cosa stai facendo. Ecco alcuni esempi.
Queste piccole discussioni nella comunità aiutano molto a comprendere, a mettere alla prova e ad affinare le conoscenze degli utenti.
Ecco una raccolta di domande "divertenti" per principianti di JMP , emerse durante le nostre sessioni di coaching. Le ho raccolte per aiutare altri utenti a comprendere JMP. Molte delle domande sono solo retoriche: dimostrano che a volte è proprio il "gergo di JMP" a rendere la comprensione della logica di JMP tutt'altro che banale.
@BHarris ha scritto:
Fino ad allora, probabilmente continuerà a rendermi nervoso, poiché il suo comportamento in queste condizioni non è ovvio, produce dati di output errati in condizioni che potrebbero essere difficili da identificare e non è sufficientemente documentato per poterlo comprendere. Almeno questo nervosismo mi manterrà più vigile in futuro quando lo userò.
Sono d'accordo. È molto importante "sapere cosa sta facendo JMP" e conoscerlo con un livello di dettaglio tale che l'utente si senta in grado di fare la cosa giusta. Non nervoso, non sorpreso. Se succede qualcosa di inaspettato, l'utente inizia a sentirsi ansioso: dove sono gli altri posti in cui JMP fa qualcosa di inaspettato ?!?!
Forse JMP ha una funzionalità fantastica, ma infastidisce o spaventa gli utenti, almeno quelli che non si aspettano ciò che JMP fa...
Avere una mappa di queste trappole può aiutare gli utenti a evitarle. Ogni utente JMP dovrebbe averne una per "sentirsi al sicuro" lavorando con JMP.
Anche se i dettagli sono ben documentati (JMP è così potente), allo stesso tempo c'è troppa poca e troppa documentazione!
Questo rende difficile trovare le informazioni giuste. LearnBot lo rende molto più semplice ora, ma non conosce ancora tutti i dettagli.
Ri: Stacking errato?Un caso estremo per Dividi con Mantieni senza Raggruppamento
Mantenere : nome (il nome non viene utilizzato per il raggruppamento)
quando 2 righe vengono unite in una sola, molti "nomi" vanno persi.
Vince il primo elemento *), quindi si inizia con i nomi femminili e si eliminano tutti i nomi maschili.
Tutti nomi maschili? No, alla fine rimangono alcuni studenti maschi.
*) NON esiste una regola universale valida per tutte le piattaforme di tabelle: quale valore verrà mantenuto e quale valore verrà perso.
Anche Join mantiene il primo valore (e non si preoccupa dei valori successivi).
Update cerca di mantenere ogni singolo valore e l' ultimo "si blocca": ecco perché Tables/Update è così lento (l'esecuzione del comando può richiedere ore): velocizza Tables/Update
Ri: Stacking errato?
@hogi ha scritto:
Il primo elemento *) vince
oops... questo vale solo per le colonne aggiunte tramite Mantenere .
Per le colonne Split , Split si comporta come Update: l' ultimo "si blocca".
Ho cercato di illustrarlo con questo esempio, in cui ho contrassegnato le voci "nome" e le voci di divisione M/F che finiscono nel set di dati finale. Come si può vedere:
- colonne aggiunte tramite Mantenere (come nome): Grado=1 (prendi la prima, salta le successive)
- righe aggiunte tramite Colonne divise (altezza --> M/F): RankReverse=1 (l'ultima "si blocca")
Ri: Stacking errato?Il comportamento segue una logica, ma si può discutere se la logica sia semplice/attesa da ogni utente : )
Mi chiedo se "Mantieni tutto" sia la scelta giusta come impostazione predefinita. Se JMP inizia con
... quindi un utente che attiva l'opzione Mantieni tutto può consultare la documentazione per accertarsi che faccia ciò che desidera.
JMP potrebbe addirittura visualizzare un avviso: "Sei sicuro di voler usare Keep? Meglio usare Group?"
Sotto la riga: Nessuna sorpresa | ansia per gli utenti che non utilizzano l'opzione.
Molto più pericoloso di Split: Tabelle /Aggiornamento
Anche l'interfaccia predefinita inizia con "Tutti"
a) per Aggiungi colonne
b) per Sostituisci colonne (!)
Alcuni anni fa, ho ritenuto abbastanza pericoloso scrivere un componente aggiuntivo che sostituisce le impostazioni predefinite con:
Un ulteriore vantaggio: con questa modifica la piattaforma non si avvia con un'impostazione che tenta di aggiornare migliaia di colonne.
Ciò lo rende di ordini di grandezza più veloce dell'originale : )
https://community.jmp.com/t5/JMP-Wish-List/Speed-up-Tables-Update/idc-p/653334/highlight/true#M4531
Ri: Stacking errato?Ho aggiunto l'argomento a Attenzione: Luoghi in cui Jmp fa qualcosa di inaspettato
Ri: Stacking errato?Mi piacerebbe vedere un giorno un'animazione che mostri cosa fanno le funzioni split (e stack). Immagino che i valori delle colonne split-by vengano inseriti nelle intestazioni di colonna e che le colonne split-by vengano inserite nelle celle di queste nuove colonne. (Sono rimasto sorpreso nello scoprire che se ci sono più colonne split-by per una determinata colonna split-by, vengono create nuove colonne numerate.)
Ma la parte davvero interessante arriva quando ci sono conflitti, ad esempio quando più valori cercano di finire nella stessa cella. JMP visualizza un avviso che questo sta accadendo (il che è fantastico!), ma l'intero post è nato da un set di dati che sembrava essere suddiviso correttamente, ma dopo averlo analizzato mi sono reso conto che non era così, e avevo ignorato quell'avviso perché non lo capivo.
Il mio contributo: l'avviso dovrebbe essere modificato da: "Più righe, eventualmente con valori diversi, delle colonne da mantenere vengono mappate sulla stessa riga nella tabella divisa. Viene mantenuto un solo valore per ogni colonna." ---> a: "Più valori vengono mappati sulla stessa cella; ne viene mantenuto solo uno."
Ri: Stacking errato?
@BHarris ha scritto:
Sono rimasto sorpreso poco fa nello scoprire che se ci sono più colonne divise per una determinata colonna divisa, vengono create nuove colonne numerate.
se vengono utilizzate più colonne divise, JMP crea i nomi delle colonne come una combinazione del nome della colonna divisa e della voce della colonna divisa:
Se è selezionata solo una colonna come colonna divisa, il nome della colonna divisa non è incluso nel nome della colonna:
I miei colleghi storcono gli occhi quando inizio a usare Big Class per spiegare una funzionalità di JMP.
Ma è un trucco fantastico usare un set di dati alternativo per giocare con le impostazioni:
con "M" e "F" è ovvio cosa sta facendo JMP, non c'è bisogno di interrogarsi sui "numeri" che apparivano con il set di dati originale.
Big Class sembra molto semplice, ma è abbastanza complicato da spiegare molti dettagli.
Mancano solo le collinearità...
