Mise en forme de fichier source Panoramic (nième version)

Ca doit être l'ordre de tri sous Windows. J'ai essayé avec une listbox sous Visualbasic, et le problème est le même: la suite (a,_,A) est triée en (_,A,a). Le "_" passe donc bien avant les lettres majuscules, alors que le code ASCII est plus élevé. Il faudra le savoir et faire avec.

Ce petit programme montre le véritable ordre de tri des caractères:

Code:

dim i%
list 10 : top 10,10 : left 10,10 : height 10,200
for i%=32 to 254
    item_add 10,chr$(i%)+" = " + str$(i%)
next i%
sort 10
end

Sans commentaire. Juste à savoir.

Bonjour Klaus,

Concernant la boucle de 32 à 254, j'ai déjà fait l'essai : c'est assez bizarre comme résultat non ?

Concernant le lower$():
Cela ne fonctionne pas car je souhaiterai que le caractère '_' soit supérieur à z,Z (ordre naturel ascii) donc dans la liste:
FILE_xxx doit normalement se trouver après FILEBIN_xxx

Ce qui n'est pas le cas dans la list, même en passant tout en lower$

La seule chose que je peut faire c'est :
Au lieu de faire un FILE_LOAD MaDLIST, "ListeDesMotsClé.txt", il faut que j'ouvre le fichier , de faire un FILE_READLN de chaque élément et de faire un tri manuel en utilisant ma fonction strcmp de comparaison de chaine...
C'est la seule façon pour obtenir un ordre dans ma liste compatible avec strcmp. --> Le problème c'est que ça rame !

Autre solution : J'essaye de voir pour adapter ma fonction strcmp par rapport au caractère '_'
...

Est-ce que cela vous convient le résultat (sortie sur une 2ème liste pour comparer)

Code:

dim i% ,v,a$ ,a
 height 0,550
list 10 : top 10,10 : left 10,10 : height 10,200
for i%=32 to 254
    item_add 10,chr$(i%)+" = " + str$(i%)
next i%
sort 10

data "FILE_READLN","FILE_RENAME","FILEBIN_OPEN_WRITE"
data "FILE_SAVE","FILE_WRITE","FILE_WRITEBUF"
data "FILEBIN_BLOCK_READ <- mon point milieu","FILEBIN_BLOCK_WRITE"
data "FILEBIN_CLOSE","FILEBIN_HEXA_READ","FILE_WRITELN","FILE_READBUF"
data "FILEBIN_HEXA_WRITE","FILEBIN_OPEN_READ","FILEBIN_POS()"
data "*"
list 1:left 1,100:height 1,500 :font_size 1,10:width 1,200
list 2:left 2,320:height 2,500 :font_size 2,10:width 2,200
a$=""
repeat
  read a$ :a$=lower$(a$):if a$="*" then exit_repeat
  v=instr(a$,"_") :if instr(a$,"_")>0 then a$=left$(a$,v-1) + chr$(91) + mid$(a$,v+1,len(a$))
  item_add 1,a$
until a$="*"
wait 2000
sort 1
message chr$(91)+"    "+upper$(chr$(91))
for a= 1 to count(1)
  a$=upper$(item_read$(1,a))
  v=instr(a$,chr$(91))
  if v>0 then a$=left$(a$,v-1)+"_"+mid$(a$,v+1,len(a$))
  item_add 2,a$
next a
end

Merci cosmos pour ton aide,

Voila ce que j'ai dans la DLIST (et dans l'exemple que tu as fourni)
FILE_READBUF
FILE_READLN
FILE_RENAME
FILE_SAVE
FILE_SYSTEM
FILE_SYSTEM_OFF
FILE_WRITE
FILE_WRITEBUF
FILE_WRITELN
FILEBIN_BLOCK_READ
FILEBIN_BLOCK_WRITE
FILEBIN_CLOSE

Et normalement, voila ce qu'il devrait y avoir si on s'en tient aux codes ASCII pour l'ordre de tri:

FILEBIN_BLOCK_READ
FILEBIN_BLOCK_WRITE
FILEBIN_CLOSE
FILE_READBUF
FILE_READLN
FILE_RENAME
FILE_SAVE
FILE_SYSTEM
FILE_SYSTEM_OFF
FILE_WRITE
FILE_WRITEBUF
FILE_WRITELN

car : asc("_") > asc("B")

J'ai trouvé la solution: j'ai modifié ma procédure de comparaison de chaine :

Code:

' ------------------------------------------------------------------------------
' Comparaison de deux chaine de caractères :
'  Appel : strcmp_s1$ = "Aea" : strcmp_s2$ = "Aeb" : gosub strcmp
'  Retour:    -1: [s1$ < s2$]    0: [s1$ = s2$]    1: [s1$ > s2$]
' ------------------------------------------------------------------------------
strcmp:
    IF VARIABLE("strcmp_a1")=0
        DIM strcmp_a1, strcmp_a2
    END_IF
    strcmp=1
    WHILE MID$(strcmp_s1$, strcmp, 1)= MID$(strcmp_s2$, strcmp, 1)
        IF ((strcmp = LEN(strcmp_s1$)) OR (strcmp = LEN(strcmp_s2$)))
            IF LEN(strcmp_s1$)<> LEN(strcmp_s2$)
                strcmp = SGN(LEN(strcmp_s1$)- LEN(strcmp_s2$))
            ELSE
                strcmp=0
            END_IF
            RETURN
        END_IF
        strcmp =strcmp +1
    END_WHILE
    ' traitement particulier du caractère "_" : on fait en sorte qu'il soit inferieur à "A"
    strcmp_a1= ASC(MID$(strcmp_s1$, strcmp, 1)) : IF strcmp_a1 =95 THEN strcmp_a1=64
    strcmp_a2= ASC(MID$(strcmp_s2$, strcmp, 1)) : IF strcmp_a2 =95 THEN strcmp_a2=64
    strcmp = SGN(strcmp_a1-strcmp_a2)
RETURN

En fait c'était tout bête...

Cela a quand même permis de constater qu'il ne faut pas faire confiance à la commande SORT...
PS: J'ai mis à jour le source (voir lien 1er post)

Merci à tous de vous êtes creusés la tête sur ce pb...

Note : ma procédure strcmp fonctionne uniquement que pour mon cas particulier (list des mots clé) qui ne contient que [A-Z][0-9][_$]

Note2: pour l'ordre de tri, tu as raison Klaus, j'ai pas encore trouvé de doc parlant de ce sujet...
Le plus étonnant c'est que quand on regarde sur le net, tout le monde passe par une comparaison du code ascii...
même les sources de strcmp...

Mes certitudes s'effondrent ! après essai, je m'aperçois que le Sort du Dos fait la même chose, pas de distinction des majuscules et minuscule, et l'underscore ('_') se retrouve classé entre l'espace et les chiffres...

Quel con je suis !
Il faut remplacer chr$(91) par chr$(39), et apparemment cela donne le même résultat que ta demande.

Évidemment ce n'est valable que dans ce cas.

Citation :

Merci cosmos pour ton aide,

Pas de quoi pour dire n'importe quoi!

Le tri, c'est n'importe quoi. Si on compare les deux méthodes, Panoramic et MsDos (tri de la liste des caractères Ascii de 32 à 255):

Code:

dim f$, f1$, f2$, i%
HEIGHT 0, 900: WIDTH 0, 250
LIST 1: TOP 1, 20: HEIGHT 1, 840: WIDTH 1, 90
LIST 2: TOP 2, 20: HEIGHT 2, 840: LEFT 2, 100: WIDTH 2, 90
PRINT "Tri Panoramic  Tri MsDos"
f1$ = "C:\Temp\Test.txt"
f2$ = "C:\Temp\Tri.tmp"
File_open_write 1, f1$
for i% = 32 TO 255: file_writeln 1, chr$(i%)+" "+str$(i%): next i%
File_Close 1
Font_Name 1, "Courier New": Font_Name 2, "Courier New": FILE_LOAD 1, f1$: FILE_LOAD 2, f1$
MESSAGE "Lancer le tri !"
SORT 1
EXECUTE_WAIT "Cmd.exe /c SORT " + f1$ + " /O " + f2$
FILE_LOAD 2, f2$: FILE_DELETE f2$: FILE_DELETE f1$
end

les résultats sont différents, et aussi faux l'un que l'autre (on devrait retrouver les listes inchangées, puisqu'elles sont déjà classées).

Je suis convaincu que ce n'était pas comme ça autrefois, sous le vrai MsDos, et que c'est l'émulateur Dos de Windows qui déconne.

Bonjour à tous !

@cosmos : L'essentiel c'est de participer !!!

Sinon j'ai peut être un début d'explication (pour un autre language et dans une autre langue...)

Désolé pour le manque de traduction, je suis trop nul pour cela !!
En gros, il peut y avoir également des critères de tri en fct de la langue...
... c'est pas gagné !!!

Citation :

In summary, strcmp() does not necessarily use the ASCII code order of each character like in the 'C' locale, but instead parse each string to match language-specific character entities (such as 'ch' in Spanish, or 'dz' in Czech), whose collation order is then compared. When both character entities have the same collation order (such as 'ss' and '�' in German), they are compared relative to their code by strcmp(), or considered equal by strcasecmp().
The LC_COLLATE locale setting is then considered: only if LC_COLLATE=C or LC_ALL=C does strcmp() compare strings by character code.
Generally, most locales define the following order:
control, space, punctuation and underscore, digit, alpha (lower then upper with Latin scripts; or final, middle, then isolated, initial with Arabic script), symbols, others...
With strcasecmp(), the alpha subclass is ignored and consider all forms of letters as equal.
Note also that some locales behave differently with accented characters: some consider they are the same letter as the unaccented letter (with a minor collation order, e.g. French, Italian, Spanish), some consider they are distinct letters with an independant collation order (e.g. in the C locale, or in Nordic languages).
Finally, the collation string is not considering individual characters but instead groups of characters that form a single letter:
- for example "ch" or "CH" in Spanish which is always after all other strings beginning with 'c' or 'C', including "cz", but before 'd' or 'D';
- 'ss' and '�' in German;
- 'dz', 'DZ' and 'Dz' in some Central European languages written with the Latin script...
- UTF-8, UTF-16 (Unicode), S-JIS, Big5, ISO2022 character encoding of a locale (the suffix in the locale name) first decode the characters into the UCS4/ISO10646 code position before applying the rules of the language indicated by the main locale...
So be extremely careful to what you consider a "character", as it may just mean a encoding byte with no significance in the string collation algorithm: the first character of the string "cholera" in Spanish is "ch", not "c" !

source : voir ici

Bon, autrement dit c'est n'importe quoi, si on ne respecte pas le code Ascii, on ne peut plus se fier à personne !
Il n'y a plus qu'à s'écrire son propre algorithme de tri. C'est pas gagné !

De retour de voyage, j'ai lu l'ensemble des interventions depuis mon dernier post dans ce sujet. Je pense que le message de Nardo26 explique parfaitement le phénomène. Donc, seule solution: remplacer SYSTEMATIQUEMENT le '_' par un chr$(255) (ou similaire), aussi bien dans ta liste de référence (à faire une seule fois) que pour chaque mot-clé à tester. Un simple GOSUB juste avant la dichotomie, et le tout est joué.

Mais ce serait peut-être l'occasion de suggérer à Jack de fournir des fonctions de comparaison de chaînes, retournant -1, 0 ou 1 selon que le résultat est plus petit, égal ou plus grand, avec un paramètre indiquant le mode de comparaison, comme ceci:

Code:

resultat% = strcomp(s1$,s2$[,mode%)])

avec
mode%=0 comparaison standard Windows/Dos (défaut)
mode%=1 comparaison ASCII stricte
mode%=2 ...

Tout à fait d'accord avec toi Klaus !
Il manque queleques instructions pour les chaines.
STRCOMP, RINSTR, etc...

Je continu à faire des recherches concernant cet ordre quand même bizarroïde... le pourquoi du comment...

Concernant la solution, j'ai fait l'inverse dans ma procedure de comparaison :
j'ai remplacé/simulé le code ascii de '_' par un code plus petit de manière à être en concordance avec le tri de la DLIST...

Ou alors pouvoir comparer deux chaînes, ce qu'on pouvait faire en QBasic:
IF a$ > b$ THEN ...

Oui, mais là encore, se pose la question sur quel critère on compare. Valeurs ASCII des caractères ? collection de caractères dépendant de la langue locale ? dependant d' d'un code page su système ? Il faudrait alors ajouter une commande STRING_COMPARE_MODE option% pour pouvoir choisir ce mode, sinon, on aexactement le même dilemme.

Pour moi, j'ai toujours considéré que c'était l'ordre Ascii des caractères, ça m'a toujours paru si évident que je ne me suis jamais posé la question avant !
Mais Nardo a ébranlé mes belles certitudes... et également l'expérience, maintenant...

Désolé JL35...

Ca me parait bien compliqué le STRING_COMPARE_MODE, surtout que l'on s'est jamais posé la question jusqu'à maintenant.

Actuellement, l'ordre de tri est sensiblement le même que l'ordre ASCII, en dehors des caractères spéciaux (+/-*_'"# etc..)

Si Jack nous ajoute des fonctions de comparaison de chaine qui s'appuient sur les même critères que les fonctions SORT des (D)LIST, cela me conviendrai parfaitement...

Ou alors il y a cette solution :

Code:

LABEL strcmp:DIM strcmp_s1$,strcmp_s2$,strcmp
LABEL CreateNewObject

strcmp_s1$="a" : strcmp_s2$="b" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)
strcmp_s1$="FILE_WRITE" : strcmp_s2$="FILEBIN" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')= "+str$(strcmp)
strcmp_s1$="FILEBIN" : strcmp_s2$="FILE_WRITE" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')= "+str$(strcmp)
strcmp_s1$="_" : strcmp_s2$="A" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)
strcmp_s1$="_" : strcmp_s2$="a" :gosub strcmp
print "strcmp('"+strcmp_s1$+"','"+strcmp_s2$+"')="+str$(strcmp)

END

strcmp:
    if Variable("strcmp_list")=0 then dim strcmp_list
    if strcmp_s1$=strcmp_s2$
      strcmp=0
    else 
      GOSUB CreateNewObject:strcmp_list=CreateNewObject
      DLIST strcmp_list
      ITEM_ADD strcmp_list,strcmp_s1$:ITEM_ADD strcmp_list,strcmp_s2$
      SORT strcmp_list
      if (strcmp_s1$=ITEM_READ$(strcmp_list,1)): strcmp=-1: else: strcmp=1 :end_if
      DELETE strcmp_list
    end_if
RETURN

CreateNewObject:
  IF variable("CreateNewObject")=0
    DIM CreateNewObject
  END_IF
  CreateNewObject=1
  WHILE OBJECT_EXISTS(CreateNewObject)=1
    CreateNewObject=CreateNewObject+1
  END_WHILE
return

Intéressante, ta fonction. Tu utilises une DLIST pour comparer deux strings. C'est une bonne solution si l'on cherche l'égalité. Cela peut donc servir à faire une recherche séquentielle dans une DLIST. Mais dans ce cas, on n'a même pas besoin de trier... Mais cela ne peut pas servir dans une mécanique de dichotomie.

Dans le tri des DLIST (et des LIST qui est identique), tous les caractères non-alphanumériques ont un ordre de tri TRES spécial. En règle générale:

- les chiffres précèdent les lettres et sont triés dans leur ordre naturel
- les lettres sont triées dans leur ordre naturel, mais en regroupant toutes les lettres dérivées (signes diacritiques etc)

Mais: quelque fois, les minuscules précèdent les majuscules, quelque fois, c'est l'inverse:
C < c mais d < D !!!
et cela vaut pour les autres caractères, ponctuations etc:
le "moins" < la "virgule" (45) < (44)
etx

Pour visualiser cela, il suffit de reprendre le petit programme que j'ai publié sur la page 2 et regarder attentivement les sections correspondantes de la liste.

On ne peut donc en aucun cas utiliser les LIST ni les DLIST pour trier selon notre représentation intuitive. Dans la situation actuelle, il n'y a que deux solutions:
- oublier le tri et faire une recherche séquentielle dans une liste non triée
- écrire sa propre routine de tri et sa propre routine de comparaison de chaînes de caractères, basées sur la valeur ASCII de chaque caractère

Je pense que pour le problème donné (recherche de monts-clé dans une liste), la première solution est tout aussi viable que la recherche par dichotomie vu la taille réduite de la liste. Mais pour un cas plus général, il y a un vrai manque dans le langage.

C'est vrai, je n'ai pas encore fait l'expérience, mais par exemple on ne peut même pas trier une liste de noms (répertoire par exemple) par ordre alphabétique...

Effectivement. Le tri que fait Windows, par exemple en cliquant sur la colonne "nom" dans l'explorateur de fichiers, se fait portion par portion (répertoire, sous-répertoire, nom, extension etc). C'est comme si l'on avait un tableau avec un certain nombre de colonnes, chaque colonne de gauche à droite servant de critère de tri majeur par rapport à la colonne plus à droite. Ceci est évidemment pas disponible en Panoramic en forme native.

En fait, Panoramic ne connait pas de mécanisme de tri ! Les commandes SORT_ON et SORT_OFF ne font que gérer l'attribut "sorted" des objets Delphi sous-jacents aux objets Panoramic correspondants. Et ce tri est donc soumis aux règles de Delphi qui en fait font ce que j'ai décrit plus haut, selon les préceptes de régionalisation de Windows.

Une vraie commande SORT n_objet%,mode% serait un vrai plus, ou au moins une fonction STR_COMP(s1$,s2£,mode%), pour que nous puissions écrire un vrai mécanisme de tri. Ceci dit, un vrai algorithme de tri, performant sur de grandes cuantités de données en format général, est un vrai défi. Il est facile d'écrire un tri acceptable pour un petit nombre de données, mais le problème de performance et/ou de l'espace de travail explose avec le nombre croissant d'éléments à trier.

Citation :

...Dans le tri des DLIST (et des LIST qui est identique), tous les caractères non-alphanumériques ont un ordre de tri TRES spécial.

Oui ben justement !!
Ma procédure de comparaison est basée sur le même ordre TRES spécial de tri !!
donc cela doit marcher dans tous les cas !

Dans le cas de tri de grande quantité de données, il est clair qu'il ne faut plus passer par des tri à bulles ou toutes sortes de QuickSort...

il existe des systèmes plus adaptés : dans le cas par exemple de centaines de milliers d'objets en va passer par des systèmes à base d'arbres (AVL, bicolore,etc...) au delà, il existe certainement d'autres principes de tri...

Citation :

C'est vrai, je n'ai pas encore fait l'expérience, mais par exemple on ne peut même pas trier une liste de noms (répertoire par exemple) par ordre alphabétique...

Oui c'est d'autant plus vrai que même Crosoft se mélange un peu les pinceaux (voir l'autre post )....ici

Voici une autre méthode de tri, avec VBSCRIPT. Elle place dans l'ordre "_",majuscules, minuscules. Mais c'est vrai: le "_" est toujours devant alors qu'il devrait se trouver entre majuscules et minuscules:

Code:

Const adVarChar = 200
Const MaxCharacters = 255
Const adFldIsNullable = 32
Const ForReading = 1

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "LineText", adVarChar, MaxCharacters, adFldIsNullable
' DataList.Fields.Append "SortCharacter", adVarChar, MaxCharacters, adFldIsNullable
DataList.Open

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:\temp\Test.txt", ForReading)

Do Until objFile.AtEndOfStream
    strLine = objFile.ReadLine

    DataList.AddNew
    DataList("LineText") = strLine
    DataList.Update
Loop

objFile.Close

' DataList.Sort = "SortCharacter, LineText"
DataList.Sort = "LineText"

' Set objFSO = nothing
Set objFSO = CreateObject("Scripting.FileSystemObject")

Set objFile = objFSO.CreateTextFile("C:\temp\Test_sorted.txt", True)
Do Until DataList.EOF
    objFile.writeLine DataList.Fields.Item("LineText")
    DataList.MoveNext
Loop

objFile.close

Bonsoir,
C'est pas ma préoccupation du moment, mais je pose la question, car ça fait plusieurs fois que je me le demande:
Supposons que d'un commun accord, on décide de considérer un caractère de champ pour nous tous, comme je ne sais chr$(20), séparateur.
On veut faire un tri:
On met dans une même chaîne le contenu à trier le contenu d'une liste, dont chaque ligne est séparée par le séparateur, l'un de vous ne peut-il pas faire une dll de tri, et on la récupère, ligne par ligne en se servant du même séparateur. Ainsi on a un tri comme on les aime, et vu que c'est fait par une dll, cela ira beaucoup lus vite, je pense.

Une idée en l'air. Tient cette fois ce sera le:

@Klaus
Ton VBScript mélange encore allègrement les majuscules et minuscules dans un ordre imprévisible, par exemple (dans mon fichier test):
m, m, m, M, m, M, m, m, n, N, n, etc.

Je n'ai pas écrit ce script. Je l'ai trouvé sur le net, comme exemple d'utilisation de streams déconnectés pour trier un texte. Utilisable pour la reconnaissance de mots-clé avec UPPER$, mais le problème teste le "_". Je continue ) creuser.

L'écriture d'une DLL avec une fonction de tri par rapport aux caractères ASCII est possible dans le principe, maie je pense que c'est une solution "dernier recours" car la réalisation d'un algorithme de n'est pas chose aisée.

Sinon j'ai vu ça, chez Microsoft, peut-être intéressant à étudier de plus près, en tout cas ça concerne bien le problème posé: trier d'après les valeurs Ascii:
http://office.microsoft.com/fr-fr/access-help/trier-les-enregistrements-en-distinguant-les-majuscules-des-minuscules-HA010062760.aspx

PS qu'est-ce que tu penses de ça Klaus ? (conversion de chaque chaîne en valeurs hexa, tri, puis reconversion):

Code:

DIM a$, b$, i%, j%, f$
LABEL Trih

HEIGHT 0, 900: WIDTH 0, 840
LIST 1: HEIGHT 1, 800: WIDTH 1, 400
DLIST 2
LIST 3: HEIGHT 3, 800: LEFT 3, 410: WIDTH 3, 400
f$ = "C:\Temp\Test.txt"
FILE_LOAD 1, f$
GOSUB Trih
END

Trih:
FOR i% = 1 TO COUNT(1)
    a$ = ITEM_READ$(1, i%): b$ = ""
    FOR j% = 1 TO LEN(a$)
        b$ = b$ + RIGHT$("0"+HEX$(ASC(MID$(a$, j%, 1))), 2)
    NEXT j%
    ITEM_ADD 2, b$
NEXT i%
SORT 2
FOR i% = 1 TO COUNT(2)
    a$ = ITEM_READ$(2, i%): b$ = ""
    FOR j% = 1 TO LEN(a$) STEP 2
        b$ = b$ + CHR$(HEX(MID$(a$, j%, 2)))
    NEXT j%
    ITEM_ADD 3, b$
NEXT i%
RETURN

Ca ne va pas à la vitesse de l'éclair, mais c'est supportable pour des listes pas trop longues.

En gros:
tu convertis en chaine hexa donc dans la plage de caractères [0-9][A-F] ta chaine de caractère ?
Ca reviens pas au même qu'un tri en fct du "poids" ascii de ta chaine ?