Ciao,
chiedo per un amico... :)
LO Calc 5.3.7.2.
Supponiamo di avere dei dati nella colonna A. Questi dati sono stati inseriti tramite database range.
L'altezza del database range e` dinamica, nel senso che i valori vanno dalla cella A1 alla cella A<N> dove <N> varia a seconda dek conteggio di valori prodotto dalla query sottostante.
Ora vorrei - ehm - il mio amico vorrebbe - calcolare i valori della colonna B a partire da valori di A. Per esempio con una formula del tipo:
=A1 * 2 + $X$7
da entrare in B1 e da copiare (presumo?).
La domanda da 6 bitcoin e`: come faccio a fare eseguire questa formula da B1 a B<N> dove <N> e` la riga fino a dove arrivano il valori nella colonna A?
Googlando tutti dicono "no es problema, semplicemente copia la formula su *tutta* *la* *colonna*. Ora questo funziona pure - a quanto pare LO ha un fisso di 2^20 righe...
Solo che produce un documento gonfiato e lento. Sono 3 MB di ods che contiene 250 MB di xml zippato...
Dal mio punto di vista e` una soluzione completamente assurda e inaccettabile. E` come se in un linguaggio di programmazione tutti gli array fossere lunghi 2^20 elementi a prescindere dall'effettiva lunghezza e per ripetere un'operazione l'unico strumento fosse un ciclo da 1 a 2^20 senza possibilita` di avere un limite dinamica...
Mi pare che ci deve essere un modo piu` furbo.
Qualcuno ha un idea o e` proprio un limite intrinseco dello strumento foglio di calcolo?
F.A.Q.
Q: Ma perche` non aggiungi le colonne in SQL e fai il calcolo li`? A: Perche` la formula contiene (tanti) riferimenti a altre celle che non risiedono nel DB (tipo $X$7 nell'esempio sopra).
Q: Ma perche` non te ne freghi e` accetti il file grosso? I dischi costan poco! A: In realta` ho parecchie colonne, verrebbe un file enorme e lentissimo...
Q: Ma perche` non copi la formula solo tipo fino alle riga 1000? Non avrai tanti valori no? A: le mie colonne hanno altezze molte variabili da 100 a 100000, a farle tutte alte anche "solo" 100000 gia` porterebe a problemi di dimensione.
Q: Ma perche` non fai tutto in SQL? A: Il tutto dovrebbe essere semi-interattivo, e programmarci una GUI sopra rischia di essere molto laborioso.
Q: Ma perche` non aggreghi i dati via SQL prima di importarli? A: Eh... per alcune colonne sarebbe anche imaginabili, ma non per tutte :(
Bye, Chris.
Ciao,
soluzione estrema: perché no una macro?
Ammetto di non avere particolare familiarità con le macro di LibreOffice (usate molto raramente), mi pare di ricordare però che si possa programmare in ambiente python in modo abbastanza flessibile.
Ora, si potrebbe fare una macro associata alla pressione di un bottone che, posizionato il cursore su una certa colonna, chieda all'utente la formula, acquisisca il numero di righe occupate in A con un ciclo e replichi la formula sullo stesso numero di righe della colonna selezionata. Chiaramente la cosa è eventualmente da estendere se si richiede di gestire colonne diverse dalla A. Mi pare di ricordare che si possa anche aggiungere un event listener se i dati di una certa colonna vengono aggiornati, in modo eventualmente da aggiungere/togliere elementi in fondo (se arriva da un db probabilmente basta ascoltare l'ultima cella piena e la prima vuota).
A questo link ho visto degli esempi carini:
http://christopher5106.github.io/office/2015/12/06/openoffice-libreoffice-au...
Spero ci siano altre soluzioni meno drastiche.
Buona serata :)
Giacomo
On 30/11/2017 18:24, Chris Mair wrote:
Ciao,
chiedo per un amico... :)
LO Calc 5.3.7.2.
Supponiamo di avere dei dati nella colonna A. Questi dati sono stati inseriti tramite database range.
L'altezza del database range e` dinamica, nel senso che i valori vanno dalla cella A1 alla cella A<N> dove <N> varia a seconda dek conteggio di valori prodotto dalla query sottostante.
Ora vorrei - ehm - il mio amico vorrebbe - calcolare i valori della colonna B a partire da valori di A. Per esempio con una formula del tipo:
=A1 * 2 + $X$7
da entrare in B1 e da copiare (presumo?).
La domanda da 6 bitcoin e`: come faccio a fare eseguire questa formula da B1 a B<N> dove <N> e` la riga fino a dove arrivano il valori nella colonna A?
Googlando tutti dicono "no es problema, semplicemente copia la formula su *tutta* *la* *colonna*. Ora questo funziona pure - a quanto pare LO ha un fisso di 2^20 righe...
Solo che produce un documento gonfiato e lento. Sono 3 MB di ods che contiene 250 MB di xml zippato...
Dal mio punto di vista e` una soluzione completamente assurda e inaccettabile. E` come se in un linguaggio di programmazione tutti gli array fossere lunghi 2^20 elementi a prescindere dall'effettiva lunghezza e per ripetere un'operazione l'unico strumento fosse un ciclo da 1 a 2^20 senza possibilita` di avere un limite dinamica...
Mi pare che ci deve essere un modo piu` furbo.
Qualcuno ha un idea o e` proprio un limite intrinseco dello strumento foglio di calcolo?
F.A.Q.
Q: Ma perche` non aggiungi le colonne in SQL e fai il calcolo li`? A: Perche` la formula contiene (tanti) riferimenti a altre celle che non risiedono nel DB (tipo $X$7 nell'esempio sopra).
Q: Ma perche` non te ne freghi e` accetti il file grosso? I dischi costan poco! A: In realta` ho parecchie colonne, verrebbe un file enorme e lentissimo...
Q: Ma perche` non copi la formula solo tipo fino alle riga 1000? Non avrai tanti valori no? A: le mie colonne hanno altezze molte variabili da 100 a 100000, a farle tutte alte anche "solo" 100000 gia` porterebe a problemi di dimensione.
Q: Ma perche` non fai tutto in SQL? A: Il tutto dovrebbe essere semi-interattivo, e programmarci una GUI sopra rischia di essere molto laborioso.
Q: Ma perche` non aggreghi i dati via SQL prima di importarli? A: Eh... per alcune colonne sarebbe anche imaginabili, ma non per tutte :(
Bye, Chris.
Ciao Chris, ciao lista,
On 2017-11-30 18:24, Chris Mair wrote:
Ciao,
chiedo per un amico... :)
LO Calc 5.3.7.2.
Supponiamo di avere dei dati nella colonna A. Questi dati sono stati inseriti tramite database range.
L'altezza del database range e` dinamica, nel senso che i valori vanno dalla cella A1 alla cella A<N> dove <N> varia a seconda dek conteggio di valori prodotto dalla query sottostante.
Ora vorrei - ehm - il mio amico vorrebbe - calcolare i valori della colonna B a partire da valori di A. Per esempio con una formula del tipo:
Domanda naive da ignorante di calc - database range: Non puoi inserire tramite database range un'area di **due** colonne (che avrà quindi la stessa altezza sia per A che per B) popolando le celle di B con la formula?
Ciao anche al tuo amico, Daniele
--
Questa è la soluzione ottimale, bravo Daniele!
Ho provato con un file .csv banale e funziona perfettamente:
test.csv -8<-- "A";"B";"C=A+B" 1;2;"=A2+B2" 4;3;"=A3+B3" 6;5;"=A4+B4" 8;7;"=A5+B5" 10;9;"=A6+B6" -->8-
--------------------------------------- Diego Maniacco, Bolzano (Italy) diego.maniacco@gmail.com ---------------------------------------
2017-11-30 21:34 GMT+01:00 Daniele daniele@gobbetti.name:
Ciao Chris, ciao lista,
On 2017-11-30 18:24, Chris Mair wrote:
Ciao,
chiedo per un amico... :)
LO Calc 5.3.7.2.
Supponiamo di avere dei dati nella colonna A. Questi dati sono stati inseriti tramite database range.
L'altezza del database range e` dinamica, nel senso che i valori vanno dalla cella A1 alla cella A<N> dove <N> varia a seconda dek conteggio di valori prodotto dalla query sottostante.
Ora vorrei - ehm - il mio amico vorrebbe - calcolare i valori della colonna B a partire da valori di A. Per esempio con una formula del tipo:
Domanda naive da ignorante di calc - database range: Non puoi inserire tramite database range un'area di **due** colonne (che avrà quindi la stessa altezza sia per A che per B) popolando le celle di B con la formula?
Ciao anche al tuo amico, Daniele
-- _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list
La domanda da 6 bitcoin e`: come faccio a fare eseguire questa formula da B1 a B<N> dove <N> e` la riga fino a dove arrivano il valori nella colonna A?
Ciao,
grazie a tutti quelli che hanno risposto!
L'idea di Daniele e` interessante, purtroppo inserendo un campo come "=A1+B1" da database range risulta in una stringa "=A1+B1" inserita, non in una formula...
Il test di Diego funziona, se importato da CSV invece, "=A1+B1" viene interpretato come formula.
Probabilmente l'idea di Giacomo e` buona. In LOBASIC per esempio effettivamente ci sono delle funzione setString e setFormula e tutto... E` solo che vorrei evitare macro il piu` possibile...
Per il momento ho deciso di evitare di creare quella logica in LOBASIC e ho optata per la strada "sprecona", cioe` quella di semplicemente copiare le formule un numero elevato di volte...
Sto incontrando uno strano problema di performance ora. LO e` veloce a importare i dati e fare conti, ma e` molto sensibile a cambiamenti della dimensione di un database range. P.e. esempio importare 50k righe e calcolare 50k righe di formule non e` un problema, lo fa in pochi secondi. Ma guai se cambia la dimesione del database range.
Se parti da un database range von 50k righe, e aggiorni la query sempre con 50k, lo rifa in due secondi, ma se aggiorni la query con 5k righe (molto meno!) resta li` 5 minuti a fare finta di essere crashato prima di riprendersi.
Noto che se il database range diventa piu` piccolo, nelle parte calcolata dove precedentemente c'erano dei valori sostituisce le colonne con #REF! A quanto pare aggiornare un database range non vuole semplicemente dire di sovvrascrivere valori in celle, ma in qualche modo distruggere le celle e inserirne nuove. Questo processo deve triggerare qualche code path worst case dentro Calc...
Intanto sopravivo, ma se qualcuno ha altri buoni consigli sono benvenuti :)
Bye, Chris.
Ciao Chris.
Il problema delle performance che citi è interessante, soprattutto assieme alla successiva tua osservazione. Ritengo che ci sarebbe il materiale per aprire una issue sul bugzilla di LO, ma occorre predisporre i file di esempio e descrivere il caso con tutti i passaggi per renderlo replicabile. Avresti tempo/voglia di farlo e eventualmente anche di sottoporlo?
Ultima cosa: che versione LO stai usando e su quale piattaforma?
-- Per il caricamento delle formule: la scrittura delle stesse nel .csv mi pare la cosa più semplice se si ha accesso alla produzione del .csv.
Grazie, diego
--------------------------------------- Diego Maniacco, Bolzano (Italy) diego.maniacco@gmail.com ---------------------------------------
2017-12-06 12:48 GMT+01:00 Chris Mair chris@1006.org:
La domanda da 6 bitcoin e`: come faccio a fare eseguire questa formula da
B1 a B<N> dove <N> e` la riga fino a dove arrivano il valori nella colonna A?
Ciao,
grazie a tutti quelli che hanno risposto!
L'idea di Daniele e` interessante, purtroppo inserendo un campo come "=A1+B1" da database range risulta in una stringa "=A1+B1" inserita, non in una formula...
Il test di Diego funziona, se importato da CSV invece, "=A1+B1" viene interpretato come formula.
Probabilmente l'idea di Giacomo e` buona. In LOBASIC per esempio effettivamente ci sono delle funzione setString e setFormula e tutto... E` solo che vorrei evitare macro il piu` possibile...
Per il momento ho deciso di evitare di creare quella logica in LOBASIC e ho optata per la strada "sprecona", cioe` quella di semplicemente copiare le formule un numero elevato di volte...
Sto incontrando uno strano problema di performance ora. LO e` veloce a importare i dati e fare conti, ma e` molto sensibile a cambiamenti della dimensione di un database range. P.e. esempio importare 50k righe e calcolare 50k righe di formule non e` un problema, lo fa in pochi secondi. Ma guai se cambia la dimesione del database range.
Se parti da un database range von 50k righe, e aggiorni la query sempre con 50k, lo rifa in due secondi, ma se aggiorni la query con 5k righe (molto meno!) resta li` 5 minuti a fare finta di essere crashato prima di riprendersi.
Noto che se il database range diventa piu` piccolo, nelle parte calcolata dove precedentemente c'erano dei valori sostituisce le colonne con #REF! A quanto pare aggiornare un database range non vuole semplicemente dire di sovvrascrivere valori in celle, ma in qualche modo distruggere le celle e inserirne nuove. Questo processo deve triggerare qualche code path worst case dentro Calc...
Intanto sopravivo, ma se qualcuno ha altri buoni consigli sono benvenuti :)
Bye, Chris.
On 06/12/17 23:00, Diego Maniacco wrote:
Ciao Chris.
Il problema delle performance che citi è interessante, soprattutto assieme alla successiva tua osservazione. Ritengo che ci sarebbe il materiale per aprire una issue sul bugzilla di LO, ma occorre predisporre i file di esempio e descrivere il caso con tutti i passaggi per renderlo replicabile. Avresti tempo/voglia di farlo e eventualmente anche di sottoporlo?
Ultima cosa: che versione LO stai usando e su quale piattaforma?
-- Per il caricamento delle formule: la scrittura delle stesse nel .csv mi pare la cosa più semplice se si ha accesso alla produzione del .csv.
Grazie, diego
Ciao,
grazie degli ulteriori spunti. Alla fine ho risolto riducendo le tabelle con dei GROUP BY lato server in modo ta tenere tutto sufficientemente piccolo. Se non eccedi qualche migliaia di righe, LO sembra farcela.
Non sono riuscito a triggerare questa cosa in modo sintetica. Probabilmente e` semplicemente un fenomeno che si manifesta se hai decine di migliaia di righe che vengono riscritte via refresh di database range. Quindi niente bug report per il momento.
Mi pare di aver sentito che stanno per riscrivere l'allocation dinamiche delle celle (per superare il limite orizzontale), forse per LO 6? Sarebbe da vedere se sia anche piu` efficiente forse?
Come dicevo, il workaround via CSV funziona, ma creerebbe in questo caso un workflow piu` complicato.
Queste erano diverse versioni di LO (abbastanza recente) sia su OS X che su Linux (Ubuntu). Le ultime prove le avevo fatto con con 3.5.7.2 su OS X in particolare.
Bye, Chris.
Ciao Chris.
Dalla versione 3.5 alla attuale 5.x Calc ha fatto parecchia strada, ma il problema della gestione di tabelle con grandi quantità di righe è certamente challenge in un prodotto che deve essere multipiattaforma. Vedimao la nuova v.6 cosa porta. Excel, girando quasi in mono-ambiente, si premette di andare a livelli bassi e sente meno il problema. Sarebbe interessante una prova con grandi volumi di dati fatta sulla versione cloud di MSO365.
Se la fai facci sapere gli esiti?
diego
--------------------------------------- Diego Maniacco, Bolzano (Italy) diego.maniacco@gmail.com ---------------------------------------
2017-12-29 1:45 GMT+01:00 Chris Mair chris@1006.org:
On 06/12/17 23:00, Diego Maniacco wrote:
Ciao Chris.
Il problema delle performance che citi è interessante, soprattutto assieme alla successiva tua osservazione. Ritengo che ci sarebbe il materiale per aprire una issue sul bugzilla di LO, ma occorre predisporre i file di esempio e descrivere il caso con tutti i passaggi per renderlo replicabile. Avresti tempo/voglia di farlo e eventualmente anche di sottoporlo?
Ultima cosa: che versione LO stai usando e su quale piattaforma?
-- Per il caricamento delle formule: la scrittura delle stesse nel .csv mi pare la cosa più semplice se si ha accesso alla produzione del .csv.
Grazie, diego
Ciao,
grazie degli ulteriori spunti. Alla fine ho risolto riducendo le tabelle con dei GROUP BY lato server in modo ta tenere tutto sufficientemente piccolo. Se non eccedi qualche migliaia di righe, LO sembra farcela.
Non sono riuscito a triggerare questa cosa in modo sintetica. Probabilmente e` semplicemente un fenomeno che si manifesta se hai decine di migliaia di righe che vengono riscritte via refresh di database range. Quindi niente bug report per il momento.
Mi pare di aver sentito che stanno per riscrivere l'allocation dinamiche delle celle (per superare il limite orizzontale), forse per LO 6? Sarebbe da vedere se sia anche piu` efficiente forse?
Come dicevo, il workaround via CSV funziona, ma creerebbe in questo caso un workflow piu` complicato.
Queste erano diverse versioni di LO (abbastanza recente) sia su OS X che su Linux (Ubuntu). Le ultime prove le avevo fatto con con 3.5.7.2 su OS X in particolare.
Bye, Chris. _______________________________________________ http://lists.lugbz.org/cgi-bin/mailman/listinfo/lugbz-list
-
Chris Mair -
Daniele -
Diego Maniacco -
Giacomo Fabris