Gil Cot ✔ a écrit 6119 commentaires

Il me semble que c'est bien une comparaison de points de code qui est faite, et non de glyphes (information qui n'est pas accessible à ce niveau là). Et me semble aussi (faudra que je me replonge dans les specs et docs pour être sûr) que ça tient bien compte du type (i.e. de la famille) d'encodage (UCS-2, UCS-4, UTF-8, UTF-7, ASCII) et des caractérisations Unicode (majuscule/minuscule du même, blanc, chassant, etc.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Exactement ce que je me suis dit en lisant sa réponse, sachant que ces outils sont codés en C. D'ailleurs, petit fun fact : les implémentations GNU disent dans les manuels de certains outils (je pense notamment à tr et grep mais y en a d'autres) que la prise en compte d'Unicode est incomplète ou boguée (notamment pour les équivalence de classes de caractères et collations, [[=foo=]] et [[.foo.]] voire même juste dans certains traitements de [[:foo:]] etc.) Autre chose marrante : les réécritures en Rust ne corrigent pas ces points non plus.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah mais un ortholinéaire n'est pas fondamentalement différent d'un incliné : c'est toujours la même électronique et on peut bien garder le même boitier… D'ailleurs, cela ressort clairement bien dans la norme ISO/CEI 9995 qui s'en fout que la grille soit carrée ou penchée dans un sens ou un autre tant qu'un certain ordre et cohérence est respecté.

Et ça existe (le GK408 3-folding et le B033 3-folding, le Clevy, l'orthopie, l'iclever Rii, entre autres, et plus couramment en matériel/solution professionnel…)

C'est juste que, en plus de faire une grille droite, les fabricants en ont profité pour revoir certaines choses (et faire avancer la/les recherche/essais sur certains points). On se souvient par exemple de : Truly Ergonomic, Plum, Maltron, Kinesis, etc, etc.

[ma vie] J'ai déjà eu ce genre de clavier orthogonaux (i.e. similaire au truc classique) jusqu'à ce que je découvre le TypeMatrix 2020 qui recentrait ces touches trop excentrées et trop utilisées : cette idée de génie (idée présente aussi dans le Truly Ergonomic puis les ErgoDox) a soulagé mon pauvre petit doigt en souffrance, et peu après je suis passé au modèle 2030 qui venait de sortir (je les ai découvert environ un an avant la sortie de celui-ci.)
Quelles combinaisons n'arrives-tu pas à faire et que ne retrouves-tu pas ?

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Le/la vocabulaire/syntaxe du Modèle C4 est vachement plus complexe (i.e. plus élaboré/avancé, avec plus de paramètres, pas plus compliqué…) que celui des Graphes Mermaid je trouve.
Ceci dit, il y a beaucoup de choses communes mais juste avec une syntaxe différente ; sachant que les règles de syntaxe retenues sont communes à tous les types de diagrammes que fait Mermaid (ce qui est appréciable pour les usagers et probablement pour le développement aussi.) Fort de cela, il y a Structurizr qui propose un convertisseur mais on peut faire la même chose manuellement (comme une des premières réponses.) Dans les deux cas il y a une étape intermédiaire (la traduction entre deux langues en somme.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

La plateforme Github se gargarise du support de Mermaid.js comme syntaxe (sauf qu'au lieu de la coloration syntaxique, c'est le rendu du diagramme qui sera fait en utilisant cette bibliothèque https://github.com/mermaid-js/mermaid#readme )

À noter que cela était déjà fait chez Gitlab et que c'est fort loin d'être fait chez Atlassian et Gitea.
Et LinuxFr ? (on me souffle dans l'oreillette que ce n'est pas encore trolldi)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah merci pour la réponse (:

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Je me demandais comment sont calculées/estimées les contributions. Je me souviens par exemple que ChocolatineFlying a eu une excellente note et de bons commentaires.
Je n'ai pas su trouver la réponse dans le wiki si elle y était déjà.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Bof, c'est typiquement le genre d'articles qu'écriraient des usagers de Fenêtre qui se frottent pour la première fois à Nunux et qui ne veulent pas avouer leur incapacité… C'est aussi le genre de chose qu'on écrit quand on cherche à cracher à tout prix sur une distro qui n'est pas la sienne et considérée avec œillères que c'est la seule valable : qui veut noyer l'alternative l'accuse de tout et n'importe quoi. Aujourd'hui c'est VLC qui est à la mode, une autre fois on te dira que Amarok ou Clementine n'est pas installé donc qu'il faut jeter le bain avec le bébé. Texte tellement partisan que l'objectivité fini aux chiottes.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

[3615 mavie]

[…]
suite

Plus de résultats mais pas mal de duplications… Arriver à les anticiper et donc ne pas calculer inutilement (ce qui aurait quand même été le cas si on stockait les résultats pour au final n'en afficher que les occurrences uniques…) C'est une piste d'amélioration qui pourrait impacter positivement le temps d'exécution.

Je ferai un autre topo sur ce point plus tard.

Il faut en fait distinguer deux cas de figure…

Le premier aspect, c'est que pour une même branche/forme, on a par exemple

7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; B3

…qui s'explique par les permutations des nombres  ! Dans l'exemple, on a puis :-D On le voit mieux sur cet autre exemple ( puis ) :

1 + 3 = 4; 4 + 8 = 12; 12 * 2 = 24; B3
3 + 1 = 4; 4 + 8 = 12; 12 * 2 = 24; B3

Comme on ne fait pas le stockage des résultats, il n'y a pas vraiment de correction possible …à moins de trouver une façon de s'assurer qu'on n'a pas de doublon dans les permutations. Sachant que les permutations sont maintenant générées et non plus manuellement listées, faut donc rajouter des tests bien sentis aux bons endroits.

 # initialement
explore_all $1 $2 $3 $4
explore_all $1 $2 $4 $3
explore_all $1 $3 $2 $4
explore_all $1 $3 $4 $2
explore_all $1 $4 $2 $3
explore_all $1 $4 $3 $2
explore_all $2 $1 $3 $4
explore_all $2 $1 $4 $3
explore_all $2 $3 $1 $4
explore_all $2 $3 $4 $1
explore_all $2 $4 $1 $3
explore_all $2 $4 $3 $1
explore_all $3 $1 $2 $4
explore_all $3 $1 $4 $2
explore_all $3 $2 $1 $4
explore_all $3 $2 $4 $1
explore_all $3 $4 $1 $2
explore_all $3 $4 $2 $1
explore_all $4 $1 $2 $3
explore_all $4 $1 $3 $2
explore_all $4 $2 $1 $3
explore_all $4 $2 $3 $1
explore_all $4 $3 $1 $2
explore_all $4 $3 $2 $1

 # maintenant
for i1 in 1 2 3 4
do
    for i2 in 1 2 3 4
    do
        test $i2 -eq $i1 && continue
        for i3 in 1 2 3 4
        do
            test $i3 -eq $i1 && continue
            test $i3 -eq $i2 && continue
            for i4 in 1 2 3 4
            do
                test $i4 -eq $i1 && continue
                test $i4 -eq $i2 && continue
                test $i4 -eq $i3 && continue
                # mettre les test de doublons ici ?
                explore_all "${!i1}" "${!i2}" "${!i3}" "${!i4}"
            done
        done
    done
done

Le second aspect est celui des diverses formes…
J'étais parti dans l'idée d'explorer les différents arbres et comme annoncé, « plusieurs arbres peuvent être équivalent à cause de la commutativité de l'addition et de la multiplication. » C'est le cas ici :

7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; L1
7*7=49; 49-1=48; 48/2=24; L2

Avec la priorité de la multiplication et de la division sur l'addition et la soustraction, mettre la première partie entre parenthèses (L1) revient au même que de ne pas mettre de parenthèses (B3) et faire séquentiellement les autres opérations… Si on met la parenthèse autour des deux premières opérations (L2) on aboutit aussi au même résultat… Ouch !
On ne peut malheureusement pas anticiper les formes égales dans notre approche exploratrice (puisqu'on était parti sur du brute force je le rappelle). Il aurait fallu lister (et catégoriser) toutes les combinaisons possibles (approche dite par tables) : c'est plus fastidieux mais plus efficace et rapide à terme. Je me note d'implémenter cela quand j'aurai un peu de temps (et si le fun y est toujours.) En l'état (approche exploratrice) on n'y peut rien :(

Ayant dit cela, le parcours par formes n'est pas compatible avec l'approche brutale qui aurait juste parcouru les opérations sans se préoccuper des formes : c'est ce que font les autres propositions (en Python et en Prolog pour l'instant), et cela correspond en fait à la forme B3 ! C'est donc la seule que devrait implémenter la variante épurée (code ci-après) et c'est la seule explorée par défaut par la nouvelle monture du script (le reste est laissé, accessible par des options, pour me permettra de satisfaire ma curiosité mathématique …et pour vérifier les cas moins triviaux où on n'a pas de solution B3.)

 # maintenant
for i1 in 1 2 3 4
do
    for i2 in 1 2 3 4
    do
        test $i2 -eq $i1 && continue
        for i3 in 1 2 3 4
        do
            test $i3 -eq $i1 && continue
            test $i3 -eq $i2 && continue
            for i4 in 1 2 3 4
            do
                test $i4 -eq $i1 && continue
                test $i4 -eq $i2 && continue
                test $i4 -eq $i3 && continue
                # ceci remplace le/la bloc/fonction process0
                for o1 in '+' '-' '*'
                do
                    for o2 in '+' '-' '*'
                    do
                        for o3 in '+' '-' '*'
                        do
                            r1=$(( ${!i1} $o1 ${!i2} ))
                            r2=$(( $r1    $o2 ${!i3} ))
                            test $(( $r2  $o3 ${!i4} )) -eq 24 &&
                            echo "${!i1}$o1${!i2}=$r1; $r1$o2 ${!i3}=$r2; $r2$o3${!i4}=24"
                        done
                    done
                done
            done
        done
    done
done

Le script devenant important d'une part (même si à fonctionnement équivalent j'ai réduit le nombre de lignes) et complexe (avec pilotage maintenant par des options) d'autre part, je l'ai déplacé dans un dépôt dédié. https://framagit.org/gilcot/trouve24 Cela me permet également de garder trace des différents essais (et donc de savoir ce qui a déjà été tenté lors des prochaines améliorations.)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est pas vraiment faux, c'est la maîtrise de l'orthographe réformée (90 je crois) donc son word ne souligne pas (et les autres non plus à ma connaissance.) Et pour l'autre ça traduit peut-être qu'ils sont dys ?

Tiens, en lisant la fin de la phrase je me dis que c'est pBpG qui du lui a soufflé…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Mauvais citoyen va. La parti va te retirer des points.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ah… un problème dans le décodage des encodages qui foutait le bronze… Merci pour la notification.

Je passe faire un retour à tout le monde dès que j'ai un créneau dans la semaine.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

…de la part du Jean-Luc Porquet. Tiens, parlant de rassurer (et d'inquiétudes, les deux allant de paire) et d'enfumage ça me donne envie de revoir Horizon Gull quand La France a peur…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Pour moi l'aspect séparé (split) vient en second point ; en premier je place le fait de ne pas avoir les touches quinconces (ce que je qualifie de conçue pour deux mains droites au mieux).
Effectivement, le clavier présenté ici n'a aucune de ces deux caractéristiques…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Euh… Il n'est pas/jamais « revenu aux manettes » et ne l'était d'ailleurs plus bien avant son départ, mais bon…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Vous dites la même chose sans vous comprendre, je pense :)

« string literal » est une suite (séquence) de « multibyte characters » ; et « sizeof » retourne bien la taille du caleçon au sens du nombre de « bytes » et c'est aussi la taille du tableau au sens « array of chars » ;) Mais ça ne retourne pas la taille au sens où on compte souvent l'utiliser : le nombre de caractères ;) Comme qui dirait, selon que tu parles de pointures italiennes ou française vous ne parlez pas des mêmes valeurs ; pareillement taille au sens ASCII-compatible ou au sens encodage multi-octets (qui en plus peut être fixe ou variable) c'est plus la même.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Il faut que t'ailles sur le site essayer le programme ;) Le code de la page utilise bien des décimaux (ou plus exactement des flottants JS)
C'est pour éviter les malentendus et voir large qu'on a fini par parler de fractions… ()

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Les doublons : c'est le premier truc qu'on constate :D En général ça se comprend/pardonne sauf quand on a le même chiffre en plusieurs exemplaires en entrée :-/

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

C'est bien beau de renvoyer au manuel, mais comment fais-tu pour lancer man humour avec un clavier sans voyelles ?

Tant qu'on a les chiffres et certains symboles ça devrait le faire

/?sr/b?n/m?n $(/?sr/b?n/pr?ntf 'h\x75m\x6f\x75r')

(par contre, je ne vois pas de contournement avec les builtins pour lesquels je ne peux pas utiliser l'astuce du globbing)

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

La longueur de TXT vu des années 70 à 90, avant le supra-vodou d'Unicode, quand on codait toujours chaque caractère sur un octet (car strlen renvoie le nombre d'octets …avant le \0 terminal si on veut chipoter)

Sinon, concernant le recalcul à la modification, les langages qui ont cette approche aiment aussi stocker l'information au début de la structure (et mettre à jour à chaque modif) mais le marketing interdit de dire qu'on triche…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

OMG l'hérésie ;D Faut voir si l'u-djc a vraiment une utilité (raison d'être), l'exemple laissant un peu à désirer à mon goût.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

TRSE is created with Qt (C++), and runs as a stand-alone application that contains various tools for developing and deploying projects for these processors. The TRSE suite includes the following stuff:

• A fully functional Pascal parser/compiler/assembler that compiles to various target platform assembler (in text format)
• A built-in assembler for the 6502
• A substantial amount of handy built-in assembler functions optimized for easy-to-use and fast operations (typically memory operations, zero paging, copying, sprite handling, IRQs, clearing screen, drawing to screen, input handling, maths, sprite handling)
• …

Et aussi https://lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/summary-of-trse-syntax/

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

[3615 mavie]

soit 41/30/99 fois plus de temps…
[…]
Plus qu'à l'optimiser.

J'ai pu optimiser un peu en essayant de réduire les calculs qui étaient refaits plusieurs fois : maintenant on stocke ces valeurs (échange d'un peu de temps CPU par un chouia de RAM ahha) et ça porte son fruit.

arguments	real	user	sys
1 2 3 8 old	0’31.546”	0’16.209”	0’26.335”
1 1 3 8 new	2’34.099”	1’15.180”	2’07.548”
1 2 7 7 old	0’31.369”	0’16.186”	0’26.573”
1 2 7 7 new	2’34.225”	1’15.134”	2’07.486”
1 5 7 8 old	0’31.556”	0’16.218”	0’26.919”
1 5 7 8 new	2’34.688”	1’15.529”	2’07.782”
1 4 5 6 old	0’31.442”	0’16.191”	0’26.819”
1 4 5 6 new	2’33.411”	1’15.030”	2’06.635”

À noter que je n'ai pas fait plusieurs exécutions et tiré les moyennes ; je ne suis pas dans un contexte de benchmark mais un contexte d'optimisation de code. Justement, une étape suivante serait de faire du profilage (un vaste débat pour du shell…)
Bien. On note un effondrement des performances… /o\ Pourtant, j'ai réduit les appels à dc :

id	type formule	avant	après
b1	Ax(ByC)zD	2+1	3
b2	(AxB)y(CzD)	2+2	3
b3	AxByCzD	2+1	3
l1	(AxB)yCzD	2+1	3
l2	(AxByC)zD	2+1	3
r1	AxBy(CzD)	2+2	3
r2	Ax(ByCzD)	2+2	3
all	total	24	21

Certes pas de beaucoup… Surtout qu'en contrepartie j'ai augmenté les appels à tr (via une sous-évaluation du shell) :

id	type formule	avant	après
b1	Ax(ByC)zD	1	2*2
b2	(AxB)y(CzD)	0	2*2
b3	AxByCzD	1	2*2
l1	(AxB)yCzD	1	2*2
l2	(AxByC)zD	1	2*2
r1	AxBy(CzD)	0	2*2
r2	Ax(ByCzD)	1	2*2
all	total	5	28

Le mieux est vraiment l'ennemi du bien… /o\ Et comme on dit, faut pas chercher à optimiser trop tôt, et le script évolue encore.
Par ailleurs, j'ai revu les tests de garde-fous et ai viré ce qui n'avait de sens que lorsqu'on travaillait en . Donc on calcule plus de cas qu'avant… (un élément en plus de l'augmentation de consommation de ressource, et je n'ai refait les mesures qu'après avoir fait toutes ces modifications.)

id	type formule	1 2 3 8	1 2 7 7	1 4 5 6	1 5 7 8
b1	Ax(ByC)zD	10/1536	2/1520	0/1536	4/1536
b2	(AxB)y(CzD)	10/1488	0/1480	0/1488	4/1488
b3	AxByCzD	8/1536	2/1536	0/1536	4/1536
l1	(AxB)yCzD	8/1536	2/1536	0/1536	4/1536
l2	(AxByC)zD	8/1536	2/1536	0/1536	4/1536
r1	AxBy(CzD)	10/1536	0/1520	0/1536	4/1536
r2	Ax(ByCzD)	8/1530	0/1520	1/1524	4/1530
all	totaux	62/10698	8/10648	1/10692	28/10698

Et là on a une petite surprise…

Si on prend le cas soumis par le_poney, il n'y a qu'une seule solution qui est trouvée dans deux branches branches mais en deux ou quatre fois pour chacune…

Eh non, il y a une seconde solution…
console
$ trouve24.sh 7 7 1 2
2/7=.28; 7/.28=25.00; 25.00-1=24; B1
7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; L1
7*7=49; 49-1=48; 48/2=24; L2
2/7=.28; 7/.28=25.00; 25.00-1=24; B1
7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; L1
7*7=49; 49-1=48; 48/2=24; L2
Found 8 solutions for 10648 computations.


…qui, un peu similaire à un autre cas, se traduit par 7/(2/7)-1 (forme B1) ou… $$

Bon, faudra peut-être augmenter la précision de calcul ?

$ dc -e '2k2 7/p'
.28
$ dc -e '18k2 7/p'
.285714285714285714

En fait c'est
et on peut sentir que c'est faux même si ça tombe juste malgré les erreurs qui s'annulent (est-ce lié à l'usage de la virgule fixe dans dc ?) En effet,

On ne peut rien contre ce genre de truc à partir du moment où le site lui-même travaille en flottants et non en entiers. C'est marrant/intrigant…

(p.s. Je mettrai à jour le snippet plus tard)

Je l'ai faite hier pour la monture dont je parle présentement (y a eu depuis d'autres améliorations dont je parlerai une autre fois).

Plus de résultats mais pas mal de duplications… Arriver à les anticiper et donc ne pas calculer inutilement (ce qui aurait quand même été le cas si on stockait les résultats pour au final n'en afficher que les occurrences uniques…) C'est une piste d'amélioration qui pourrait impacter positivement le temps d'exécution.

Je ferai un autre topo sur ce point plus tard.

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Ce que beaucoup ne comprennent pas, c'est que le standard au début (89 et 90) n'
a fait qu'entériner un certain nombre de pratiques courantes (histoire que la no
rme de fait devienne un standard de référence pour de nouveaux entrants, et au p
assage graver dans le marbre une spécification qui n'existait pas vraiment… Les
créateurs ont écrit un ouvrage de référence et laissé une implémentation mais ja
mais écrit formellement les spécifications.) En aucun cas le standard n'a jamais
supposé une certaine architecture, contrairement à d'autres compilateurs… Ainsi
, Wikipedia en anglais rappelle clairement :

The actual size of the integer types varies by implementation. The standard re
quires only size relations between the data types and minimum sizes for each dat
a type:

The relation requirements are that the long long is not smaller than long, whi
ch is not smaller than int, which is not smaller than short. As char's size is a
lways the minimum supported data type, no other data types (except bit-fields) c
an be smaller.

The minimum size for char is 8 bits, the minimum size for short and int is 16 bits, for long it is 32 bits and long long must contain at least 64 bits.

The type int should be the integer type that the target processor is most efficiently working with. This allows great flexibility: for example, all types can be 64-bit. However, several different integer width schemes (data models) are popular. Because the data model defines how different programs communicate, a uniform data model is used within a given operating system application interface.

La portabilité du langage est en fait que c'est un macro assembleur (l'usage du C permet de ne pas avoir à se battre avec les différentes syntaxes d'assembleur pour la plupart des cas) dont le code de compilateur est assez petit et adaptable aux diverses plateformes. Si, avec les registres de ton CPU ton int est de 20 bits et ton long de 60 bits pas de souci. :-D

Avec l'évolution, le standard met des barrières à minima…

In practice, char is usually 8 bits in size and short is usually 16 bits in size (as are their unsigned counterparts). This holds true for platforms as diverse as 1990s SunOS 4 Unix, Microsoft MS-DOS, modern Linux, and Microchip MCC18 for embedded 8-bit PIC microcontrollers. POSIX requires char to be exactly 8 bits in size.

C'est là par exemple une des barrières parce-qu'il ont estimé que c'est le minimum auquel on a pu descendre dans les années 80 (on ne parle pas des ALU qui peuvent être de 4 comme sur Saturn ou Zilog 80). Si un fondeur fait moins, il ne pourra pas utiliser le C standard (dont on a là une limite de portabilité) :-D

“It is seldom that liberty of any kind is lost all at once.” ― David Hume

Tu m'as devancé :-) Oui, en général sont bien définis des choses qui sont quasiment sûres d'être présentes partout ; sinon on dépend des spécifications du processeur ciblé…

“It is seldom that liberty of any kind is lost all at once.” ― David Hume