Nel nostro tentativo di sfruttare le ampie capacità di Python in JMP, ci siamo trovati di fronte alla sfida di integrare la flessibilità di Python con l'esperienza utente intuitiva e interattiva di JMP. Prima di JMP 18, ci siamo riusciti con una soluzione alternativa: eseguire Python su un server per bypassare la macchinosa integrazione di JMP con Python. Tuttavia, il rilascio di JMP 18 ha reintrodotto l'integrazione con Python, semplificando questo processo.
Partendo dal nostro concetto iniziale di consentire agli utenti di JMP di sfruttare Python senza dover possedere competenze di programmazione, abbiamo sviluppato JMPyFacade (JMPy). Questo strumento offre un'interfaccia familiare, poiché simile a quella di JMP, per l'esecuzione di servizi Python predefiniti tramite un'interfaccia utente generata dinamicamente, il tutto astraendo il codice Python e JSL sottostante.
In questa presentazione, esploreremo l'architettura tecnica di JMPyFacade e mostreremo come colma efficacemente il divario tra JMP e Python. I partecipanti scopriranno come Python può essere sfruttato all'interno di JMP per un'analisi dei dati efficiente e coinvolgente.
Ciao, benvenuti alla mia presentazione poster sull'integrazione di JMP e Python per un'analisi fluida e coinvolgente. Mi chiamo Jarmo Hirvonen e lavoro presso Murata, in Finlandia. In questo poster spiegherò perché utilizzare Python in JMP, o l'integrazione di Python in JMP. Alcune cose da notare riguardo all'integrazione e una delle applicazioni che abbiamo sviluppato qui a Murata, Finlandia, io e il mio collega Eero, che sfrutta l'integrazione. Iniziamo chiedendo perché si utilizza questa funzionalità in JMP.
JMP è uno strumento molto visivo e interattivo con buone capacità analitiche. D'altro canto, Python è fondamentalmente il linguaggio di programmazione de facto per molte attività legate ai dati. Dispone di numerose librerie molto consolidate, ed è possibile che la vostra azienda disponga anche di funzionalità Python.
Vedo la cosa da due punti di vista. Abbiamo alcuni primi utenti che avranno accesso a funzionalità non disponibili in modo nativo in JMP, come alcuni modelli di machine learning, Torch, per esempio, e poi avranno accesso a tipi di file che altrimenti non potrebbero essere utilizzati in JMP.
Un esempio sono i file Parquet, che possono essere aperti in Python e poi trasferiti tramite l'integrazione in JMP. In questo modo, gli utenti Python hanno accesso agli strumenti visivi e interattivi di JMP, che possono utilizzare direttamente in JMP o in modo integrato dal lato Python. Naturalmente, ci sono anche alcune funzionalità analitiche che si trovano solo in JMP. Un aspetto da tenere presente riguardo a questa integrazione tra JMP e Python è che Python è installato con JMP 18, e questo è un aspetto importante.
È un po' lento al caricamento iniziale per istanza JMP. In altre parole, il luogo caricato per primo nell'istanza JMP richiede un po' di tempo, ma al caricamento successivo, se non si chiude completamente JMP, è più veloce. Potrebbe essere necessario tenerne conto se si sta lavorando solo su piccole cose. Potrebbe valere la pena provare a farlo solo in JSL, è più veloce.
La gestione e l'installazione dei pacchetti possono a volte causare problemi, ma esiste una documentazione a riguardo, anche se a volte può essere un po' complicata da risolvere. Si dispone di un solo ambiente, quindi se si è abituati a lavorare con ambienti virtuali, al momento non è possibile farlo tramite l'integrazione dei job. È necessario comprendere a un certo livello le conversioni dei tipi di dati JSL e Python, ma è disponibile una documentazione a riguardo su alcune pagine web. L'ambito può essere confuso, o almeno un po' confuso. Python ha fondamentalmente un ambito globale e, a seconda di come si nominano le variabili, possono creare un po' di confusione tra diversi script e così via.
Infine, a mio parere, forse uno degli aspetti più importanti è che il debug e lo sviluppo in Python possono essere un'esperienza un po' fastidiosa, e può essere difficile entrare nel flusso. Questo accade principalmente perché non è possibile reimpostare Python in JMP o riavviare il kernel, e si finisce in questo tipo di "ciclo di sviluppo". Si sviluppa in Python, poi si vuole testarlo e si sospetta che ci sia qualcosa che si vorrebbe pulire da alcune variabili, ad esempio.
L'unico modo per farlo al momento è chiudere l'istanza JMP, rieseguire i JMP, quindi ricaricare tutto e testare il codice. Non si tratta di un ciclo, in pratica si interrompe qui e bisogna ricominciare tutto dall'inizio. Interrompe il flusso. Questo può causare frustrazione, ma è possibile attenuarla un po', a seconda di come si scrive il codice Python.
Passiamo ora alla nostra applicazione: cos'è JMPyFacade? Innanzitutto, il nome deriva dal modo in cui fondamentalmente maschera il complicato codice JMP e Python dietro un'interfaccia utente simile e piuttosto familiare, simile a quella di JMP. È un controllo di versione aggiunto, che offre agli utenti JMP l'accesso a funzionalità Python predeterminate. Li chiamiamo servizi. Questi spaziano dalla creazione di dataset molto semplici a modelli di apprendimento molto più complessi, [inudibile 00:04:34].
Ciò che vogliamo fare è dare accesso ai nostri utenti JMP per utilizzare le funzionalità di Python senza che si accorgano minimamente di usarlo. In precedenza avevamo qualcosa di simile, ma in quel caso utilizzavamo il server per bypassare l'integrazione Python di JMP, perché prima era un po' difficile da usare. Ora, con JMP18, possiamo usare l'integrazione nativa, che funziona piuttosto bene.
Quindi, il flusso dell'applicazione quando l'utente la esegue, esegue il componente aggiuntivo, quindi verifica se è aggiornato o meno; in caso contrario, riceverà l'aggiornamento e l'utente eseguirà nuovamente il componente aggiuntivo. Se non vengono trovati aggiornamenti, verrà inizializzato il Python LS in JMP. Lo scopo di questo passaggio è fondamentalmente quello di creare l'aggiornamento degli ordini. Se l'utente non l'ha eseguito, è possibile eseguirlo in qualcosa... un'applicazione come questa potrebbe generare problemi se non esiste.
Dopo averli inizializzati, controlleremo tutti dalla nostra gestione pacchetti se ci sono pacchetti che devono essere aggiornati, se li aggiorniamo, se necessario, e se non c'è nulla da aggiornare, allora continuiamo. Controlliamo se l'utente ha una tabella aperta e, se non c'è alcuna tabella, chiuderemo il componente aggiuntivo e informeremo l'utente che è necessario aprire una tabella prima di eseguire questo. Questo viene fatto attualmente perché supportiamo una sola tabella statica, sostanzialmente.
Quindi, quando l'utente ha una tabella aperta e vuole analizzarla, importiamo i pacchetti. Se si verifica un problema, di nuovo, si interrompe e viene visualizzato il log, indicando cosa è andato storto. Se l'operazione ha esito positivo, inizializziamo l'interfaccia utente, la creiamo e gli utenti possono iniziare a utilizzare lo strumento. Se l'interfaccia utente esiste già nell'istanza JMP, la portiamo semplicemente in primo piano senza inizializzare nulla.
Ecco un po' come funziona in background: utilizziamo tipi di dati, classi JMP e poi, sul lato Python, anche il pacchetto Pydantic per creare i modelli che utilizziamo e per la convalida dei tipi e dei dati.
Ecco un esempio di HDBSCAN. Se prendiamo ad esempio questo argomento, si tratta di un elenco di stringhe, un campo di lunghezza minima pari a uno che utilizza lo schema JSON, ovvero colonne numeriche. Quando JMP riceve questo, sa come creare questo tipo di classe, quindi ci si troverà di fronte a un pulsante, una casella di riepilogo delle colonne, in cui l'utente deve inserire un singolo valore numerico, almeno una singola colonna numerica affinché funzioni, e diversi tipi di elementi per diversi tipi di dati: interi, caselle numeriche 8, e poi abbiamo i valori booleani, ovvero caselle di controllo e così via.
Quando gli utenti sono pronti a eseguire il servizio, compilano le colonne, cliccano sul pulsante "Esegui servizio" e, a questo punto, il lato JMP del codice creerà un sottoinsieme dei dati, ovvero queste colonne, e prenderà le colonne che non sono state escluse. Queste vengono poi utilizzate quando viene chiamata la funzione Python. Questo semplifica un po' la gestione lato Python, ed è per questo che lo facciamo in questo modo.
Python eseguirà il suo algoritmo e aggiornerà i valori del sottoinsieme. Quando il sottoinsieme e Python restituiscono alcuni valori, JMP capisce: "Ok, ora possiamo aggiornare la tabella originale". Aggiornerà la tabella, chiuderà il sottoinsieme e creerà anche alcuni script di tabella e proprietà di colonna per la tabella originale. Ogni volta che l'utente esegue un servizio, verranno create nuove colonne nella tabella, se ce ne sono.
Ecco alcuni esempi di utilizzo. Questo è un esempio di base: l'utente esegue il componente aggiuntivo, lo controlla dal controllo di versione e, in questo caso, l'utente desidera eseguire tSNE da questo componente aggiuntivo. Quindi seleziona tSNE dal lato sinistro, inserisce le colonne e controlla anche la documentazione, che è la documentazione ufficiale di tSNE, se, ad esempio, vuole sapere come funziona, cosa fa e quali sono i parametri. Quando l'utente è pronto per eseguire il servizio, fa clic sul pulsante Esegui servizio e vengono create nuove colonne nella tabella JMP, che ora funzionano come il normale pulsante JMP.
Quindi visualizziamo anche lo script del report, in questo caso si tratta solo dei parametri di input. Ecco alcuni esempi un po' più complicati, o esempi eccessivi, o esempi espansivi. In questa dimostrazione, si tratta di una modalità interattiva. A mio parere, una delle migliori funzionalità che abbiamo qui. Queste non creano sempre nuove colonne, aggiornano le colonne statiche e rieseguono immediatamente i loro algoritmi, algoritmi Python, quando l'utente modifica qualsiasi valore nell'interfaccia utente. Ad esempio, è possibile utilizzare questa esportazione di dati per l'analisi o l'ottimizzazione degli algoritmi.
Qui, l'utente clicca semplicemente sulla freccia su sulla tastiera e l'algoritmo Python verrà ripetuto ogni volta, e il clustering cambierà in base all'utente, quando questi aggiorna i valori. Più visualizzazioni qui, più i componenti cambiano, quindi si otterranno cluster completamente diversi a seconda dei valori. Si potrebbero modificare i valori qui in modo interattivo, capire quali sono i migliori in questo caso e poi magari tornare a Python e usarli lì, ad esempio.
Poi abbiamo questo servizio di importanza delle funzionalità che utilizza più algoritmi e poi usa i valori di Shapley per determinare quale potrebbe essere il più importante per la modellazione o la previsione di qualcosa. Eseguiamo i modelli, otteniamo Shapley [inudibile 00:10:32] e poi anche la classificazione degli algoritmi selezionati. In questo caso, RGBM, XGBoost e AdaBoost. E da qui, un utente può sostanzialmente copiare e incollare i valori e quindi iniziare a modellare in JMP utilizzando queste colonne.
Infine, alcuni lavori futuri per questo strumento, come l'aggiunta del supporto per la tabella dinamica, ora abbiamo una tabella statica, più servizi, l'analisi delle immagini e i nostri modelli di apprendimento automatico personalizzati. Migliora l'interattività, quindi Python creerà script grafici o aggiornerà direttamente gli script grafici. Esportazione e importazione di modelli Python. Utilizzo delle straordinarie funzionalità DOE di JMP per la messa a punto dei parametri. Creazione di pipeline, in modo da poter eseguire più servizi in sequenza. Miglioramento delle funzionalità dinamiche che abbiamo qui e, a seconda di ciò che JMP19 porterà, possibile refactoring, in modo da poter migliorare ulteriormente lo strumento. Un altro aspetto da discutere potrebbe essere l'open source, in modo che non ci sia solo noi a sviluppare questo strumento. Grazie.
