Tri sur texte

Michel_ANDREU1 · August 23, 2013, 12:54pm

Bonjour Pat,

J'ai quitté le monde Apple depuis plus de 5 ans, je n'ai donc pas la possibilité de faire la comparaison. Par contre, depuis que je fais de l'informatique (1980) le tri s'est toujours effectué de la manière que je t'ai indiquée.

Dès que je je pourrais, je testerais sous Excel et Windows. Il me semble que Apple utilise aussi Excel, je ne crois pas qu'il y ait eu une manière de trier sous Mac OSX et une différente sous Windows !

Désolé de ne pouvoir, pour l'instant, répondre à ton interrogation.

Cordialement.

Michel

cubytus · August 23, 2013, 4:43pm

Bonjour Michel,

je parlais de tri dans le Finder. Si Excel a reproduit les mêmes problèmes sous Mac et Windows, grand bien lui fasse. Je ne pensais pas qu'on puisse quitter Mac sans y être forcé! Trop peu de support rapide sous Linux, sans compter la taxe Windows. Depuis des décennies l'informatique comptait un gigaoctet comme 1000 mégaoctets, et non pas les 1024 réels. Apple a rétabli l'affichage correct il n'y a que quelques années, Linux a décidé de compter en gibioctets.

D'ailleurs le tri de 1N est aussi erronné: pourquoi 1N914 va après 1N4004, alors que 4004 est supérieur à 914? D'ailleurs ce tri qui a pris une macro dans LibreOffice, est intégré sous forme d'un simple bouton dans Gnumeric. Il serait temps que LibOO s'inspire de cet excellent tableur au lieu de faire un complexe d'infériorité à courir après Excel.

cubytus · August 23, 2013, 5:24pm

Bonjour Michel,

je parlais de tri dans le Finder. Si Excel a reproduit les mêmes problèmes sous Mac et Windows, grand bien lui fasse. Je ne pensais pas qu'on puisse quitter Mac sans y être forcé! Trop peu de support rapide sous Linux, sans compter la taxe Windows. Depuis des décennies l'informatique comptait un gigaoctet comme 1000 mégaoctets, et non pas les 1024 réels. Apple a rétabli l'affichage correct il n'y a que quelques années, Linux a décidé de compter en gibioctets.

D'ailleurs le tri de 1N est aussi erronné: pourquoi 1N914 va après 1N4004, alors que 4004 est supérieur à 914? D'ailleurs ce tri qui a pris une macro dans LibreOffice, est intégré sous forme d'un simple bouton dans Gnumeric. Il serait temps que LibOO s'inspire de cet excellent tableur au lieu de faire un complexe d'infériorité à courir après Excel.

christianwtd · August 23, 2013, 7:40pm

Pas de complexe d'infériorité dans le tri pour Calc:
Données, Trier, Onglet Options : Activer le tri naturel

Pour un tri, disons classique, si on considère le début des données, 1N4(004) passe avant 1N9(14). Ceci explique cela.

Bon surf,
Christian

Michel_ANDREU1 · August 23, 2013, 8:05pm

Bonsoir Pat,

Pour l'instant je n'ai pas les éléments pour répondre d'une manière précise.

Pour ce qui concerne la comparaison de la suite Microsoft et de LibreOffice, il ne faudrait pas confondre le travail de quelque centaines d'ingénieurs "rémunérés" pour développer un logiciel "payant" (suite Microsoft) et celui de quelques développeurs d'une fondation (à but non lucratif) accompagnés de milliers de bénévoles apportant leur savoir avec enthousiasme pour, constamment, améliorer une suite "LIBRE" qui, à mon humble avis et pour l'usage que j'en ai, vaut celle de Microsoft.
Exiger de ces derniers une réactivité "commerciale" n'est pas raisonnable en ce sens que, quant on choisit LibreOffice, on ne doit pas avoir des exigences comme avec avec un logiciel que l'on a "payé" et qui, effectivement, doit répondre au prix qu'on y a mis.
Néanmoins, tu peux immédiatement te rendre compte que, en y mettant quelque courtoisie et civilité, poser une demande sur cette liste a davantage de chance de trouver une réponse qu'en s'adressant à Microsoft, non ?
Depuis que LibreOffice existe (et OpenOffice avant) d'énormes progrès ont été réalisés et je ne doute pas un instant que cela continue. L'attitude à adopter étant plutôt de contribuer que d'exiger, c'est beaucoup plus constructif.

Bien cordialement

Michel

Jean-Baptiste_Faure · August 23, 2013, 8:46pm

Bonsoir,

Bonjour Michel,

D'ailleurs le tri de 1N est aussi erronné: pourquoi 1N914 va après
1N4004, alors que 4004 est supérieur à 914?

Parce que tu confonds tri numérique et tri alphabétique. Dans le cas
présent le tri qui va bien est un tri alphabétique puisqu'il s'agit
d'une chaine de caractères et non de nombres.
Par exemple dans quel ordre mettrais tu des noms de fichiers tels que
BNJAE et BNEAAE ?

Bonne soirée
JBF

cubytus · August 24, 2013, 1:26am

Bonsoir à tous,

je crois que la remarque de JBF a du sens. Après tout, on ne parle pas de nombre purs (sauf exception), mais de références en lettres et chiffres. Si, dans la macro, j'active “Natural Sort True”, ça vient bien dans l'ordre attendu (pour une chaîne non numérique). On pourrait pinailler et dire que si les concepteurs l'ont appelé “tri naturel”, c'est qu'ils savent que le tri ordinaire n'a rien de “naturel” !

Les quelques cas que j'ai demandé un coup de main à Microsoft (ça date quand même!), la réponse était toujours une variante sur "Demandez à votre revendeur". Ça refroidit, et je pensais plutôt support matériel ET logiciel, pas logiciel seulement. Pour aussi peu de support ça se paye trop cher les produits Microsoft. Enc omparaison la liste de LibOo est bien plus réactive, bien que je n'aime pas personnellement le principe des listes de diffusion.

Je ne conteste pas le travail des bénévoles et quelques développeurs professionnels, mais il faut parfois oser la différence. Gnumeric ne se veut pas un imitateur d'Excel, mais a peaufiné sa précision jusqu'à dépasser LibOo et Excel. Malheureusement, LibOo ne tient pas les lourdes charges dans Calc, et j'ai encore les souvenirs douloureux de ces tableurs qui plantent toujours Calc trois fois sur quatre à la sauvegarde ou quand je tentais de lier d'autres feuilles de calcul pour ne pas tout ouvrir d'un coup, et malgré la quantité suffisante de RAM disponible. D'ailleurs, elle ne sature pas avant le plantage. Sous Excel, ça passe comme une fleur, mais têtu que je suis je n'ai pas voulu l'utiliser pour ce projet. Ça montre bien que le problème en est un de codage du tableur ou de format de fichier, mais clairement, ça ne se voit pas sur les faibles et moyennes charges. Je dois reconnaître à mon corps défendant que LibOo ne peut pas faire tous les travaux.

Un tel cas de données massives se présenterait encore, je pense que je demanderais conseil sur la liste pour une stratégie à adopter avant de passer plus de temps à réparer les fuites qu'à travailler. On en avait discuté il y a longtemps, une base de données aurait peut-être été une meilleure forme, mais plus difficile de la remplis de façon interactive qu'un tableur.

Jean-Baptiste_Faure · August 24, 2013, 6:09am

Bonjour,

Je te suggère de suivre le travail de Kohei Yoshida sur Calc.
Par exemple :
http://kohei.us/2013/08/15/shared-formula-to-reduce-memory-usage/

Bonne journée
JBF

cubytus · August 24, 2013, 7:17am

bonsoir,

pas sûr que son travail aie beaucoup aidé dans mon cas. Il n'y avait pas beaucoup de formules, mon fichier était déjà très gros avant ajout des formules. LibOoo ne planterait peut-être pas s'il savait utiliser toute la RAM disponible avant de taper dans la swap, ou s'il évitait de tout décompresser en même temps, mais se limiterait à une dizaine de feuilles à la fois. Je crois que c'est la technique utilisée par Excel pour éviter la surconsommation, d'ailleurs. Avec 16Gio de RAM je ne pensais plus voir le problème, et le fait est que ça plante encore alors qu'il reste plusieurs Gio de libres. Je serai curieux de connaître la raison technique de ces plantages alors que la mémoire n'est plus une limitation.

Jean-Baptiste_Faure · August 24, 2013, 8:15am

Bonjour,

bonsoir,

pas sûr que son travail aie beaucoup aidé dans mon cas.

C'est un travail en cours.

Il n'y avait pas beaucoup de formules, mon fichier était déjà très gros avant ajout

des formules. LibOoo ne planterait peut-être pas s'il savait utiliser
toute la RAM disponible avant de taper dans la swap, ou s'il évitait de
tout décompresser en même temps, mais se limiterait à une dizaine de
feuilles à la fois. Je crois que c'est la technique utilisée par Excel
pour éviter la surconsommation, d'ailleurs. Avec 16Gio de RAM je ne
pensais plus voir le problème, et le fait est que ça plante encore alors
qu'il reste plusieurs Gio de libres. Je serai curieux de connaître la
raison technique de ces plantages alors que la mémoire n'est plus une
limitation.

Pour savoir il faut que d'autres testent ton fichier. Tu peux me
l'envoyer si tu veux, en expliquant le type de modification que tu
réalises sur ce fichier.

Bonne journée
JBF

cubytus · August 24, 2013, 8:04pm

Bonjour,

si ça intéresse qqn, effectivement j'ai mis les deux documents incriminés. Deux parce que normalement, je devais les garder ouverts en même temps.

Un exemple de modification: Sur n'importe quelle feuille, par exemple la 101302_101303 du fichier en 20(tt), reproduire les calculs de AT2 à BB25 sur la plage AT61 à BB84 (le codage couleur est mis pour faciliter l'alignement, notamment en cas d'exceptions dans l'emplacement exact des colonnes (plusieurs exceptions dans tout le fichier si je me souvient bien). Répéter sur toutes les feuilles nommées suivant la convention xxxxx2_xxxxx3.

Dans le fichier en 4cat, on remarque, dans les colonnes EE à EQ de toutes les feuilles respectant la convention que les formules donnent le résultat "#VALEUR!", ce qui n'était pas le cas quand le fichier a été créé, sous OpenOffice 3.2. J'ignore la source de cette erreur.

Par contre ce n'est pas sur Cjoint, mais Dropbox, comme Cjoint n'autorise pas les documents supérieurs à 8Mio. Il pourrait rester des embryons de macro dans chaque fichier, elles ne sont pas nécessaires pour l'observation.
https://dl.dropboxusercontent.com/u/1186986/20(tt)_anon_2013.ods
https://dl.dropboxusercontent.com/u/1186986/4cat_anon_2013.ods

D'ici deux heures de réception de ce message les deux liens devraient être actifs.

Jean-Baptiste_Faure · August 25, 2013, 5:33am

Normal, tu fais des opérations numériques sur des cellules vides.
Option déjà signalée : dire à Calc de considérer les cellules vides
comme valant zéro. Outils > Options > Calc > Formules > Paramètres de
calcul détaillés.

Bonne journée
JBF

cubytus · August 26, 2013, 5:53pm

Bon, ça c'est réglé. Apparemment dans OpenOffice 3.x, par défaut le comportement est celui que tu décris, ce qui a changé dans LibreOffice 4.x.

Pas de retour sur l'instabilité de ces deux fichiers en édition?

Jean-Baptiste_Faure · August 26, 2013, 8:43pm

Bonsoir,

Bon, ça c'est réglé. Apparemment dans OpenOffice 3.x, par défaut le comportement est celui que tu décris, ce qui a changé dans LibreOffice 4.x.

Oui cette option a été ajoutée par LibreOffice, le comportement par
défaut précédent (cellule vide =0) ne convenant pas à tout le monde.

Pas de retour sur l'instabilité de ces deux fichiers en édition?

J'ai déjà fait quelques essais avec avec LO 4.1 et le master (futur LO
4.2) sans obtenir de plantage. J'ai remarqué que l'empreinte mémoire
avec le master est près de 2 fois moindre qu'avec la 4.1.

Bonne soirée
JBF

cubytus · August 26, 2013, 10:08pm

Bonsoir à la liste et JBF,

Dommage que le défaut ne soit pas resté comme avant, ou au moins, qu'il n'y aie aucun avertissement en cas d'erreur de calcul massive à l'ouverture d'une feuille.

Apparemment il reste un bug, alors que les liens vers les fichiers externes ne peuvent être actualisés, Calc ne précise pas quels sont ces fichiers externes. Pas très pratique!

Si l'empreinte diminue et qu'il n'y a pas plantage, quelle est la taille finale du fichier, une fois répété le calcul mentionné sur toutes les feuilles?

Jean-Baptiste_Faure · August 27, 2013, 6:32pm

Bonsoir à la liste et JBF,

Dommage que le défaut ne soit pas resté comme avant, ou au moins, qu'il n'y aie aucun avertissement en cas d'erreur de calcul massive à l'ouverture d'une feuille.

Il n'y a pas erreur de calcul mais calcul différent et je ne vois pas
trop comment Calc pourrait savoir que le résultat est différent de ce
qu'il était lors d'une utilisation avec une version précédente.

Apparemment il reste un bug, alors que les liens vers les fichiers externes ne peuvent être actualisés, Calc ne précise pas quels sont ces fichiers externes. Pas très pratique!

On peut les obtenir à partir du menu Édition > Liens... mais c'est
laborieux, j'en conviens. N'hésite pas à faire des propositions pour
améliorer ça.

Si l'empreinte diminue et qu'il n'y a pas plantage, quelle est la taille finale du fichier, une fois répété le calcul mentionné sur toutes les feuilles?

Je ne sais pas, je n'ai pas vraiment le temps ni le goût de faire un tel
volume de modifications sur tes fichiers. Je te laisse le plaisir
d'essayer la version alpha de la prochaine 4.2 pour le savoir.
Mais la taille du fichier après enregistrement n'est pas directement
liée à l'empreinte mémoire et ne devrait pas changer de façon
gigantesque il me semble.

Bonne journée
JBF

cubytus · August 27, 2013, 8:42pm

Bonjour à la liste,

Bonsoir à la liste et JBF,

Dommage que le défaut ne soit pas resté comme avant, ou au moins, qu'il n'y aie aucun avertissement en cas d'erreur de calcul massive à l'ouverture d'une feuille.

Il n'y a pas erreur de calcul mais calcul différent et je ne vois pas
trop comment Calc pourrait savoir que le résultat est différent de ce
qu'il était lors d'une utilisation avec une version précédente.

Peut-être avec une forme de "sanity check"? En se doutant bien que l'utilisateur n'aurait pas, volontairement, inclus des cases qui donnent une erreur de calcul massive?

Apparemment il reste un bug, alors que les liens vers les fichiers externes ne peuvent être actualisés, Calc ne précise pas quels sont ces fichiers externes. Pas très pratique!

On peut les obtenir à partir du menu Édition > Liens... mais c'est
laborieux, j'en conviens. N'hésite pas à faire des propositions pour
améliorer ça.

Au pif, en laissant le dialogue donner la liste des fichiers auxquels les liens sont coupés, et l'option de sauvegarder la liste ? Ou de les "reconnecter" manuellement, à partir de ce même dialogue, soit en les sélectionnant, soit en indiquant à LibO de chercher dans un répertoire donné?

Si l'empreinte diminue et qu'il n'y a pas plantage, quelle est la taille finale du fichier, une fois répété le calcul mentionné sur toutes les feuilles?

Je ne sais pas, je n'ai pas vraiment le temps ni le goût de faire un tel
volume de modifications sur tes fichiers. Je te laisse le plaisir
d'essayer la version alpha de la prochaine 4.2 pour le savoir.
Mais la taille du fichier après enregistrement n'est pas directement
liée à l'empreinte mémoire et ne devrait pas changer de façon
gigantesque il me semble.

Dans le cas de ces fichiers, ce copier-coller massif avait justement fait croître l'empreinte à des niveaux que OOo 3.x ne pouvait pas gérer sans planter. Je vais réessayer dès que j'ai le temps.

P

Jean-Baptiste_Faure · August 28, 2013, 10:15am

Bonjour,

Bonjour à la liste,

Bonsoir à la liste et JBF,

Dommage que le défaut ne soit pas resté comme avant, ou au moins, qu'il n'y aie aucun avertissement en cas d'erreur de calcul massive à l'ouverture d'une feuille.

Il n'y a pas erreur de calcul mais calcul différent et je ne vois pas
trop comment Calc pourrait savoir que le résultat est différent de ce
qu'il était lors d'une utilisation avec une version précédente.

Peut-être avec une forme de "sanity check"? En se doutant bien que l'utilisateur n'aurait pas, volontairement, inclus des cases qui donnent une erreur de calcul massive?

Ce que je trouverais plus utile ce serait un complément de la fonction
Outils > Audit > Repérer les erreurs qui permet, en sélectionnant une
cellule contenant une erreur, de voir les cellules d'où provient cette
erreur. Ce complément serait un moyen de naviguer d'erreur en erreur,
par exemple depuis le navigateur, car il n'est pas toujours facile de se
rendre compte qu'il y a des [diagnostics d']erreurs dans une feuille de
calcul. Par exemple sur ton fichiers les erreurs sont dans des colonnes
éloignées et ne sautent pas aux yeux.

Je n'ai pas trouvé de moyen d'obtenir une telle liste des cellules avec
erreur, mais j'ai peut-être mal cherché.

Apparemment il reste un bug, alors que les liens vers les fichiers externes ne peuvent être actualisés, Calc ne précise pas quels sont ces fichiers externes. Pas très pratique!

On peut les obtenir à partir du menu Édition > Liens... mais c'est
laborieux, j'en conviens. N'hésite pas à faire des propositions pour
améliorer ça.

Au pif, en laissant le dialogue donner la liste des fichiers auxquels les liens sont coupés, et l'option de sauvegarder la liste ? Ou de les "reconnecter" manuellement, à partir de ce même dialogue, soit en les sélectionnant, soit en indiquant à LibO de chercher dans un répertoire donné?

Il me semble que si les liens cassés étaient montrés en rouge dans le
dialogue Édition > Liens... ce serait déjà pas mal.

Si l'empreinte diminue et qu'il n'y a pas plantage, quelle est la taille finale du fichier, une fois répété le calcul mentionné sur toutes les feuilles?

Je ne sais pas, je n'ai pas vraiment le temps ni le goût de faire un tel
volume de modifications sur tes fichiers. Je te laisse le plaisir
d'essayer la version alpha de la prochaine 4.2 pour le savoir.
Mais la taille du fichier après enregistrement n'est pas directement
liée à l'empreinte mémoire et ne devrait pas changer de façon
gigantesque il me semble.

Dans le cas de ces fichiers, ce copier-coller massif avait justement fait croître l'empreinte à des niveaux que OOo 3.x ne pouvait pas gérer sans planter. Je vais réessayer dès que j'ai le temps.

J'ai l'impression que là tu confonds l'empreinte mémoire et la taille du
fichier. Je conçois que la réalisation de modifications massives des
données et formules, augmente sensiblement l'empreinte mémoire. On le
vois déjà rien qu'en faisant une petite modification puis en rechargeant
le fichier. En revanche la taille du fichier c'est ce que tu as sur ton
disque dur et ça oublie les étapes intermédiaires et variables
temporaires utilisées par LO pour faire ses modifications.

Bonne journée
JBF

cubytus · August 29, 2013, 3:30pm

Bonjour à JBF et la liste,

Bonjour,

Bonjour à la liste,

Bonsoir à la liste et JBF,

Dommage que le défaut ne soit pas resté comme avant, ou au moins, qu'il n'y aie aucun avertissement en cas d'erreur de calcul massive à l'ouverture d'une feuille.

Il n'y a pas erreur de calcul mais calcul différent et je ne vois pas
trop comment Calc pourrait savoir que le résultat est différent de ce
qu'il était lors d'une utilisation avec une version précédente.

Peut-être avec une forme de "sanity check"? En se doutant bien que l'utilisateur n'aurait pas, volontairement, inclus des cases qui donnent une erreur de calcul massive?

Ce que je trouverais plus utile ce serait un complément de la fonction
Outils > Audit > Repérer les erreurs qui permet, en sélectionnant une
cellule contenant une erreur, de voir les cellules d'où provient cette
erreur. Ce complément serait un moyen de naviguer d'erreur en erreur,
par exemple depuis le navigateur, car il n'est pas toujours facile de se
rendre compte qu'il y a des [diagnostics d']erreurs dans une feuille de
calcul. Par exemple sur ton fichiers les erreurs sont dans des colonnes
éloignées et ne sautent pas aux yeux.

Ça serait un bon début, mais se prêterait mal à l'examen de nombreuses erreurs. Dans l'exemple de mon fichier, ce ne serait pas bien grave puisque tout a été unifié, mais tout de même.

D'ailleurs, qu'est censée afficher cette commande? Quand je clique, il ne se passe rien de spécial. Pas de surlignement, pas de dialogue en lien avec ces colonnes éloignées quand je rétablis le comportement par défaut de ne pas compter les cellules n'affichant rien comme valant 0.

Je n'ai pas trouvé de moyen d'obtenir une telle liste des cellules avec
erreur, mais j'ai peut-être mal cherché.

Apparemment il reste un bug, alors que les liens vers les fichiers externes ne peuvent être actualisés, Calc ne précise pas quels sont ces fichiers externes. Pas très pratique!

On peut les obtenir à partir du menu Édition > Liens... mais c'est
laborieux, j'en conviens. N'hésite pas à faire des propositions pour
améliorer ça.

Au pif, en laissant le dialogue donner la liste des fichiers auxquels les liens sont coupés, et l'option de sauvegarder la liste ? Ou de les "reconnecter" manuellement, à partir de ce même dialogue, soit en les sélectionnant, soit en indiquant à LibO de chercher dans un répertoire donné?

Il me semble que si les liens cassés étaient montrés en rouge dans le
dialogue Édition > Liens... ce serait déjà pas mal.

Une variante de la question plus haut: le fichier source est noté comme file:///Volumes/Utilisateurs/Cubytus/Documents/#REF !, ce qui correspond à mon ancienne arborescence d'avant le reformatage, mais ne renseigne pas sur le nom du fichier en question

Si l'empreinte diminue et qu'il n'y a pas plantage, quelle est la taille finale du fichier, une fois répété le calcul mentionné sur toutes les feuilles?

Je ne sais pas, je n'ai pas vraiment le temps ni le goût de faire un tel
volume de modifications sur tes fichiers. Je te laisse le plaisir
d'essayer la version alpha de la prochaine 4.2 pour le savoir.
Mais la taille du fichier après enregistrement n'est pas directement
liée à l'empreinte mémoire et ne devrait pas changer de façon
gigantesque il me semble.

Dans le cas de ces fichiers, ce copier-coller massif avait justement fait croître l'empreinte à des niveaux que OOo 3.x ne pouvait pas gérer sans planter. Je vais réessayer dès que j'ai le temps.

J'ai l'impression que là tu confonds l'empreinte mémoire et la taille du
fichier. Je conçois que la réalisation de modifications massives des
données et formules, augmente sensiblement l'empreinte mémoire. On le
vois déjà rien qu'en faisant une petite modification puis en rechargeant
le fichier. En revanche la taille du fichier c'est ce que tu as sur ton
disque dur et ça oublie les étapes intermédiaires et variables
temporaires utilisées par LO pour faire ses modifications.

Quand je fais les modifications, l'empreinte mémoire avoisine le 2Gio de mémoire virtuelle. C'est toujours largement plus que Excel dans mon souvenir, mais au moins, ça ne plante plus.