Andreas a essayé Aᵀ (et peut-être Aᴴ ) dans #19344, mais cela n'a pas été très bien reçu. Nous pourrions également jouer sur ^ avec des types d'exposants spéciaux T (et peut-être H ) tels que A^T est transposé, mais c'est plutôt louche aussi. Je ne suis pas sûr qu'il existe de nombreuses autres bonnes options qui ressemblent encore un peu à la notation mathématique.

Je pense en quelque sorte que t(A) pourrait être le meilleur, mais c'est malheureux de "voler" un autre nom d'une lettre.

Déplacer mon commentaire de l'autre problème (pas que cela résout quoi que ce soit, mais ...) :

+1 pour utiliser autre chose que .' .

Je n'ai pas pu trouver de langages avec une syntaxe spéciale pour la transposition, à l'exception d'APL qui utilise le pas si évident ⍉ et Python qui utilise *X (ce qui serait déroutant pour Julia). Plusieurs langages utilisent transpose(X) ; R utilise t(X) . Ce n'est pas joli, mais ce n'est pas pire que .' . Au moins, vous êtes moins tenté d'utiliser ' en le confondant avec .' : il serait clair qu'il s'agit d'opérations très différentes.

Voir le code Rosetta . (BTW, l'exemple de Julia illustre en fait la transposition conjuguée ...)

L'une des autres tiques pourrait-elle être utilisée ? ` ou "

-100 pour changer d'adjoint, car c'est l'une des choses géniales qui rend l'écriture de code Julia aussi claire que l'écriture de mathématiques, et la transposition conjuguée est généralement ce que vous voulez de toute façon, il est donc logique d'avoir une syntaxe abrégée pour cela.

Tant que nous avons la belle syntaxe pour la transposition conjuguée, un opérateur postfixé pour la transposition régulière semble généralement inutile, donc le simple fait d'en faire un appel de fonction régulier me semble bien. transpose fonctionne déjà ; ne pourrions-nous pas simplement utiliser cela? Je trouve le t(x) R-ism malheureux, car son nom ne dit pas clairement ce qu'il est censé faire.

Utiliser une coche différente serait un peu bizarre, par exemple A` peut ressembler beaucoup à A' selon la police, et A" ressemble trop à A'' .

Si nous apportons le changement dans # 20978, alors une transposition postfixée devient en fait plus utile qu'elle ne l'est maintenant. par exemple, si vous avez deux vecteurs x et y et que vous voulez leur appliquer f par paire, vous pouvez faire par exemple f.(x, y.') ... avec #20978 , cela sera applicable aux tableaux de types arbitraires.

Honnêtement, je pense que notre meilleure option est toujours de le laisser tel quel. Aucune des suggestions ne me semble être une nette amélioration. .' a l'avantage d'être familier avec Matlab. Le . est en fait quelque peu conforme à la syntaxe d'appel de points dans des exemples comme f.(x, y.') , et suggère (un peu correctement) que la transposition "fuse" (elle ne produit pas de copie temporaire grâce à RowVector et ses futures généralisations).

En fait, nous pourrions même aller plus loin et faire f.(x, g.(y).') une opération de fusion. c'est-à-dire que nous changeons la transposition de .' pour qu'elle soit non récursive ala #20978 et nous étendons sa sémantique pour inclure la fusion avec d'autres appels de points imbriqués. (Si vous voulez la version sans fusion, vous appelleriez transpose .)

J'aime beaucoup ce plan, @stevengj.

Un hic : vraisemblablement la macro @. ne transforme pas y' en y.' (car ce serait faux). Cela pourrait cependant transformer y' en une sorte d'opération adjointe fusionnée.

Le principal problème est de trouver un moyen propre de faire en sorte que f.(x, g.(y).') ait une sémantique de fusion. Une possibilité serait de le transformer en f.(x, g.(y.')) et donc en broadcast(x,y -> f(x, g(y)), x, y.') ?

Notez que, pour que cela fonctionne correctement, nous devrons peut-être restaurer la méthode de secours transpose(x) = x , auquel cas nous pourrions tout aussi bien laisser la transposition rester récursive.

Je pense que décider si la transposition doit être récursive ou non est orthogonal à la question de savoir si nous la faisons participer à la fusion de la syntaxe à points. Le choix de le rendre non récursif n'est pas motivé par cela.

@StefanKarpinski , si vous restaurez un repli transpose(x) = x , alors la plupart de la motivation pour le changer pour qu'il soit non récursif disparaît.

Quel est le problème si le repli est restauré mais que la transposition est toujours non récursive ?

@jebej , la transposition récursive est plus correcte lorsqu'elle est utilisée comme opération mathématique sur des opérateurs linéaires. Si je me souviens bien, la principale raison de le rendre non récursif était de ne pas avoir à définir le repli transpose(x) = x , plutôt que de lancer une MethodError.

Mais ce ne serait pas terrible d'avoir le repli tout en étant non récursif.

Permettez-moi d'ajouter deux commentaires (j'ai parcouru la discussion précédente et je ne les ai pas remarqués - désolé si j'ai omis quelque chose):

• la documentation pour permutedims indique qu'il s'agit d'une généralisation de la transposition pour les tableaux multidimensionnels. transpose , ce qui n'est pas le cas.
• Comment est-on censé faire une transposée d'un vecteur x=["a", "b"] ? En fait, y=x.' fonctionne et crée une nouvelle variable mais getindex échoue dessus. AFAIK, vous devez utiliser reshape(x, 1, :) ou beaucoup plus lent hcat(x...) pour y parvenir, mais il n'est pas naturel d'avoir une syntaxe différente pour Vector ( permutedims ne fonctionne pas ici ).

Quel est votre cas d'utilisation pour transposer un vecteur de chaînes ?

Considérez le scénario suivant par exemple :

x = ["$(j+i)" for j in 1:3, i in 1:5]
y = ["$i" for i in 5:9]

et je veux ajouter y après la dernière ligne de x . Et le moyen le plus simple est de vcat une transposition de y .

Apparaît en pratique lors de la journalisation incrémentielle de données textuelles dans un Matrix{String} (je pourrais utiliser Vector{Vector{String}} ), mais souvent la matrice est plus utile (ou alors encore une fois il y a une question comment convertir Vector{Vector{String}} à Matrix{String} en concaténant verticalement des éléments consécutifs).

Autre cas d'utilisation : la transposition est le moyen le plus simple de rendre deux vecteurs orthogonaux entre eux afin de diffuser une fonction sur le produit cartésien ( f.(v, w.') ).

Point de données : Hier, j'ai rencontré une partie confuse par l'opérateur postfixé "broadcast-adjoint" et pourquoi il se comporte comme une transposition. Meilleur!

FWIW, je pense fermement que nous devrions nous débarrasser de la syntaxe .' . En tant que personne plus familière avec Julia qu'avec Matlab, je m'attendais à ce que cela signifie adjoint vectorisé et j'ai vraiment trébuché quand ce n'était pas le cas. Julia n'est pas Matlab et ne devrait pas être liée par les conventions de Matlab - si dans Julia, un point signifie la vectorisation de la fonction adjacente, alors cela devrait être cohérent dans tout le langage et ne devrait pas avoir au hasard la seule horrible exception que .' n'est formellement pas lié à ' .

Je pense que c'est bien d'avoir juste transpose sans aucune notation spéciale "tick", puisque la grande majorité du temps, il est appelé sur une matrice de nombres réels, donc ' serait équivalent si vous vraiment envie d'économiser la frappe. Si nous voulons créer une version fusionnée de transpose, alors je ne pense vraiment pas que .' soit la bonne syntaxe.

C'est un bon point. On peut dire que seul l'adjoint a besoin d'une syntaxe super compacte.

Appelons simplement cela transpose et déprécions .' . À l'avenir, nous pourrons considérer si nous voulons .' comme adjoint ponctuel ou si nous voulons simplement le laisser obsolète pour éviter de piéger les utilisateurs de Matlab.

Notez que je viens de parcourir les packages enregistrés et que j'ai trouvé plus de 600 utilisations de .' , donc ce n'est pas très rare. Et avec les appels de points / broadcast (qui n'ont commencé à gérer pleinement les données non numériques qu'en 0.6), le désir de transposer paresseusement des tableaux non numériques (où l'adjoint a moins de sens) deviendra probablement beaucoup plus courant, donc l'argument en faveur d'une syntaxe compacte est quelque peu renforcé.

Ensuite, nous ferions mieux de déprécier .' dès que possible, avant que davantage de code ne soit piégé dans un mauvais modèle d'utilisation.

Pourquoi est-ce mauvais?

Le problème est que .' ne signifie plus ce qu'il semble signifier en tant qu'opérateur pointillé.

Comme je l'ai dit ci-dessus, parce que cela viole le modèle général selon lequel . signifie vectorisation, et semble signifier adjoint vectorisé (en particulier pour quelqu'un qui n'est pas familier avec Matlab).

Je pense que @stevengj fait valoir un bon point - cela est lié au désir d'une simple transposition non récursive.

Je sais que c'était impopulaire, mais je commence à privilégier le #19344 d'Andreas pour ᵀ . À ce stade, je préférerais déprécier l'utilisation de _tous_ les exposants comme identifiants et interpréter _tous_ les exposants de fin comme des opérateurs postfixés. Cela donne également un chemin vers la résolution de certains problèmes autour literal_pow en utilisant des nombres en exposant. Oui, ce serait triste de perdre χ² et autres noms de variables, mais je pense que les avantages l'emporteraient sur les inconvénients.

À ce stade, je préférerais déprécier l'utilisation de _tous_ les exposants comme identifiants et interpréter _tous_ les exposants de fin comme des opérateurs postfixés.

RIP mon code

À ce stade, je préférerais déprécier l'utilisation de tous les exposants comme identifiants

Je ne pense vraiment pas que ce serait nécessaire, alors que nous voulons juste T et peut-être quelques autres choses à l'avenir.

Une constance folle…

Oui, il est légèrement incohérent d'utiliser .' pour la transposition, mais toutes les alternatives proposées jusqu'à présent semblent être pires. Ce n'est pas la pire chose au monde de dire " .' est une transposition, une exception à la règle habituelle concernant les opérateurs point". Vous apprenez cela et passez à autre chose.

Une chose à noter qui peut aider à toute confusion potentielle sur le fait .' n'est pas une diffusion par points est qu'il s'agit d'un opérateur postfixé, alors que la diffusion préfixée est op. et l'infixe est .op . On peut donc dire que . ne veut pas dire diffusé quand c'est postfixé. L'autre utilisation du suffixe . est la recherche de champ, et getfield(x, ') n'a pas de sens, il est donc distinct des autres significations.

(Cela dit, je préfère transpose(x) plutôt que de garder .' .)

@stevengj Je parierais que bon nombre (peut-être la plupart) des plus de 600 utilisations de .' dans les packages enregistrés que vous avez mentionnés ci-dessus pourraient être remplacées par ' sans frais pour la lisibilité, et le code continuerait à travailler.

Peut-être pas populaire, mais il pourrait toujours y avoir des suffixes " et ` ?

utilisations de .' dans les packages enregistrés que vous avez mentionnés ci-dessus pourrait être remplacé par ' sans frais pour la lisibilité, et le code continuerait à fonctionner.

Notez qu'une fois #23424 atterri, nous pourrons utiliser transpose sur des tableaux de chaînes et ainsi de suite, mais pas adjoint . La meilleure pratique pour l'utilisation de l'algèbre linéaire de x.' deviendra très probablement quelque chose comme conj(x') (j'espère que c'est paresseux, c'est-à-dire gratuit). Bien que j'aime utiliser .' pour sa compacité, peut-être que s'en débarrasser forcera les utilisateurs d'algèbre linéaire à utiliser la bonne chose et les utilisateurs de tableaux de données à utiliser transpose épelé.

il pourrait encore y avoir des suffixes " et ` ?

La nouvelle syntaxe pour transpose() semble plutôt prématurée. À mon humble avis, il serait préférable de simplement déprécier .' pour être remplacé comme vous le suggérez par conj(x') et transpose selon les besoins.

J'ai l'impression que .' est si utile dans matlab principalement en raison de l'insistance de matlab sur le fait que "tout est une matrice" ainsi que du manque de règles de découpage cohérentes telles que vous devez souvent insérer des transpositions aléatoires à divers endroits pour faire fonctionner les choses.

Pour résumer les arguments ici :

1. .' est maintenant le seul opérateur en pointillé qui ne signifie pas "appliquer l'opérateur sans pointillé élément par élément" ; les nouveaux utilisateurs ne venant pas de Matlab trouvent que c'est un piège surprenant.

2. .' est maintenant effectivement ambigu : vouliez-vous dire transpose ou vouliez-vous dire conj(x') ? En principe, chaque utilisation héritée de .' doit être vérifiée pour déterminer s'il s'agit de permuter les indices d'un tableau à 2 dimensions ou s'il s'agit d'un "adjoint non conjugué".

Le premier problème est problématique mais pas fatal en soi ; le deuxième problème est vraiment mauvais - ce n'est plus une seule opération cohérente, mais plutôt elle sera divisée en deux significations distinctes.

Je viens de remarquer que si jamais nous changions .' pour signifier "adjoint élément par élément", alors conj(x') serait à peu près équivalent à x'.' et conj(x)' serait à peu près x.'' qui est tellement proche de x.' 😬.

Peut-être pas populaire, mais il pourrait toujours y avoir des suffixes " et ` ?

Copiez-collez le code dans Slack et voyez que détruire la coloration syntaxique serait...

Pouvoir transposer n'importe quoi est agréable car cela facilite le "produit croisé" via le mécanisme de répartition, et d'autres cas d'utilisation courts et concis comme celui-ci. Le problème de ne pas avoir de solution de repli facile pour ce genre de choses est que, invariablement, le hack que nous verrons consiste simplement à définir des solutions de repli transpose(x) = x (ou sur les types de base, donc le piratage de type dans les packages) pour faire cela genre de chose fonctionne facilement. Cela me fait penser : pourquoi n'est-ce pas Complex l'intrus ? L'adjoint de la plupart des nombres est lui-même, donc l'adjoint du complexe est celui sur lequel se spécialiser : cela ne peut-il pas être étendu au-delà des nombres ?

Je vois ici deux choses très liées :

1) x' ne fonctionne pas pour les types non numériques, nous voulons donc un moyen de le faire facilement pour d'autres données
2) transpose(x) n'est pas aussi simple que x.' . C'est surtout pour les cas de (1), puisque les cas d'utilisation pour transposer des matrices complexes sont beaucoup plus rares.

Mais au lieu de descendre (2), pourquoi ne pas essayer de faire une correction raisonnable pour (1) ?

Peut-être qu'une solution raisonnable est juste une macro qui fait que ' signifie transposition au lieu d'adjoint ?

Mais au lieu de descendre (2), pourquoi ne pas essayer de faire une correction raisonnable pour (1) ?

Nous avons déjà parcouru ce chemin et plusieurs adjacents. Il y a eu une grande quantité de discussions qui en ont résulté que quelqu'un d'autre peut peut-être distiller, mais en résumé, cela ne fonctionne pas bien. Fondamentalement, l'opération mathématique adjoint n'a pas de sens sur des choses qui ne sont pas des nombres. Utiliser ' sur des non-nombres simplement parce que vous aimez la syntaxe concise est mauvais - c'est le pire type de calembour d'opérateur et il ne devrait pas être surprenant que de mauvaises choses découlent de ce type d'abus de sens. La fonction adjoint ne doit être définie que sur des choses dont il est logique de prendre l'adjoint et ' ne doit être utilisé que pour signifier cela.

Rappelez-vous que .' tel qu'il est actuellement utilisé est fondamentalement deux opérations différentes : la transposition de tableau et l'adjoint non conjugué. Le problème de transposition récursive met en évidence le fait que ce sont des opérations différentes et que nous avons donc besoin de différentes façons de les exprimer. Les matheux semblent catégoriques sur le fait que l'opération adjointe non conjuguée est (a) importante et (b) différente du simple échange de dimensions. En particulier, pour être correct, l'adjoint non conjugué doit être récursif. D'autre part, l'échange des dimensions d'un tableau générique ne doit clairement pas être récursif. Ces opérations doivent donc être écrites différemment et les utilisations existantes de .' doivent être désambiguïsées comme ayant une signification ou une autre. Déprécier .' est un moyen de forcer cela.

Enfin, même si je suis convaincu que permutedims(x, (2, 1)) est définitivement trop gênant pour échanger les dimensions d'un tableau 2d, je trouve l'argument selon lequel transpose(x) est trop gênant peu convaincant. Cette opération est-elle si courante qu'avoir un nom de fonction simple et clair est trop? Vraiment? L'échange des dimensions d'un tableau est - il beaucoup plus courant ou important que toutes les autres choses dans le langage pour lesquelles nous utilisons les noms de fonction et la syntaxe d'appel de fonction ? La notation de chef de ménage rend adjoint assez spécial puisque nous voulons écrire des choses comme v'v , v*v' et v'A*v . C'est pourquoi adjoint obtient une très belle syntaxe. Mais échanger les dimensions d'un tableau ? Cela ne justifie pas un opérateur à mon avis.

Pas un argument solide, mais j'utilise souvent l'opérateur ' pour imprimer des tableaux de manière plus compacte (lorsqu'il est utilisé comme de simples conteneurs), par exemple lorsque je veux voir le contenu de quelques vecteurs en même temps sur mon écran ( et invariablement frustré quand il échoue parce que les éléments ne peuvent pas être transposés). Donc, une courte syntaxe pour le REPL est vraiment pratique. (En outre, cela permet aux personnes habituées aux tableaux majeurs de lignes d'avoir un moyen simple de "changer l'ordre", en particulier lors du portage d'algorithmes sur julia à l'aide de tableaux 2d; mais ce n'est certainement pas un argument solide non plus). Juste pour dire que c'est une belle syntaxe concise qui n'est pas seulement utile aux algébristes linéaires.

J'avais commenté quelques idées de syntaxe sur https://github.com/JuliaLang/julia/pull/19344#issuecomment -261621763, en gros c'était :

julia> const ᵀ, ᴴ = transpose, ctranspose;

julia> for op in (ᵀ, ᴴ)
           <strong i="7">@eval</strong> Base.:*(x::AbstractArray{T}, f::typeof($op)) where {T<:Number} = f(x)
       end

julia> A = rand(2, 2)
2×2 Array{Float64,2}:
 0.919332  0.651938
 0.387085  0.16784

julia>  Aᵀ = (A)ᵀ    # variable definition and function application are both available!
2×2 Array{Float64,2}:
 0.919332  0.387085
 0.651938  0.16784

julia> Aᴴ = (A)ᴴ
2×2 Array{Float64,2}:
 0.919332  0.387085
 0.651938  0.16784

Mais sans le hack bien sûr, juste l'idée qu'il peut y avoir une sorte "d'application de fonction postfixée" et qu'elle exige des parenthèses (x)f , les versions pointillées pourraient être comme ça (x).f ( xf serait un identifiant, même si f est un exposant).

Cet exemple de hack fonctionnait sur 0.6 mais maintenant :

julia> Aᵀ = (A)ᵀ               
ERROR: syntax: invalid operator

julia> Aᵀ = (A)transpose       
2×2 Array{Float64,2}:          
 0.995848  0.549117            
 0.69401   0.908227            

julia> Aᴴ = (A)ᴴ               
ERROR: syntax: invalid operator

julia> Aᴴ = (A)ctranspose      # or adjoint or whatever
2×2 Array{Float64,2}:          
 0.995848  0.549117            
 0.69401   0.908227            

Ce qui est triste, je voulais à l'origine faire ça pour les pouvoirs:

julia> square(n) = n^2; cube(n) = n^3;

julia> Base.:*(n, f::typeof(square)) = f(n)

julia> Base.:*(n, f::typeof(cube)) = f(n)

julia> const ² = square    # why?
syntax: invalid character "²"

julia> const ³ = cube    # why?
syntax: invalid character "³"

Ce que je pensais naïvement permettrait une syntaxe comme: n² = (n)² et n³ = (n)³ Mais tout identifiant numérique est interdit d'être en première position, cependant (A)⁻¹ a également fonctionné, où ⁻¹ était const ⁻¹ = inv .

J'ai implémenté un hack similaire pour InfixFunctions.jl .

En tant qu'utilisateur, je pourrais simplement faire un package PostfixFunctions.jl et être satisfait de ce que vous trouverez de mieux ici. Mais actuellement, ces restrictions de syntaxe :

• l'utilisation de superindices numériques au début d'un identifiant n'est pas autorisée
• superindex x * ᶠ en suffixe (multiplication implicite dans le hack) (x)ᶠ non autorisé

Cela me semble un peu trop à mon humble avis, j'aimerais au moins pouvoir définir des identifiants qui peuvent commencer par des exposants numériques, ou plus généralement, interdire uniquement les caractères numériques réels 0-9 avec la sémantique numérique, au début d'un identifiant, ce serait génial. 😄

Acclamations!

Voir #10762 pour une discussion sur les autres caractères numériques comme identifiants.

L'autre problème est lié à #22089, les suffixes d'opérateurs. +ᵀ est maintenant un opérateur valide, qui (probablement accidentellement) interdit les identifiants consistant uniquement à combiner des caractères dans des contextes où un opérateur pourrait être attendu. Cela me semble être un bug. Il est également un peu étrange que ᵀ soit un identifiant valide mais que -ᵀ ne fasse pas -(ᵀ) . Cependant, ce n'est pas la fin du monde, et la résolution de l'OMI ne vaudrait pas la peine de perdre d'autres utilisations possibles de ᵀ .

Notez que l'utilisation .' comme opérateur de transposition postfixé n'est même pas sur la table ici (malgré ce que dit le sujet du problème), la considération est en fait de savoir si nous devrions garder .' comme opérateur postfixé pour l'adjoint non conjugué, qui serait récursif. Il s'agit souvent de la même chose que la transposition, mais ce n'est généralement pas la même opération. Si les gens de l'algèbre linéaire sont prêts à laisser .' signifie transposer un tableau générique, c'est une autre histoire, mais j'ai l'impression que ce n'est pas acceptable.

@Ismael-VC, je peux voir autoriser (x)ᵀ comme syntaxe de fonction postfixée pour les exposants - car qu'est-ce que cela signifierait d'autre? Je pense que là où votre proposition commence à frotter les gens dans le mauvais sens, c'est de permettre à n'importe quel identifiant d'être appliqué en tant que fonction dans la syntaxe postfixée. Je le limiterais aux exposants.

@StefanKarpinski , je pensais que le consensus était précisément d'autoriser .' signifie une transposition de tableau non récursive et non conjuguée (si nous avons cet opérateur), tandis que ' est le récursif, conjugué opération adjointe.

Je déteste vraiment, vraiment l'idée d'utiliser ᵀ pour un opérateur de transposition postfixé. Il est bien trop utile d'avoir un exposant dans les noms de variables, comme aᵀa ou LᵀDL = ltdlfact(A) . (Outre le fait qu'utiliser uniquement ᵀ pour un opérateur alors que d'autres exposants sont valides dans les identifiants serait bizarre.)

Ce n'était pas du tout ma compréhension - je pensais que les gens linalg étaient en faveur de garder a.' tel quel, c'est-à-dire conj(a)' . Garder .' mais changer sa signification en transposition de tableau est assez différent - je ne suis pas sûr de ce que je ressens à ce sujet. Je suis d'accord qu'avoir seulement ᵀ comme opérateur postfix serait ennuyeux et incohérent. J'aime plutôt la proposition (a)ᵀ @Ismael-VC, qui n'empêcherait pas d'utiliser aᵀ comme nom.

Mon souvenir de ces discussions reflète celui de Steven. La transposition récursive non conjuguée est rare et généralement assez étrange. Résumé décent ici : https://github.com/JuliaLang/julia/issues/20978#issuecomment -316141984.

Je pense que nous sommes tous d'accord sur le fait que le suffixe ' est adjoint et devrait rester.
Je pense que nous sommes tous d'accord sur le fait que le suffixe .' est une syntaxe sous-optimale.
Je pense que la plupart conviennent que la transposition non récursive (structurelle) est plus utile qu'une transposition récursive.

Ok, donc les points sur lesquels tout le monde semble être d'accord :

1. Utilisez a' pour adjoint(a)
2. Utilisez conj(a)' ou conj(a') pour l'adjoint (non-)conjugué.

Donc, le seul point de discorde est de savoir comment écrire la transposition du tableau :

• Comme a.' ou
• Comme transpose(a) ou
• Comme (a)ᵀ .

Cette évaluation est-elle correcte ?

Oui, je pense que oui (où la "transposition de tableau" est non récursive).

De plus, si je comprends bien, tout le monde convient que transpose(a) devrait définitivement être une syntaxe valide (et non récursive), et les seuls points de désaccord sont de savoir si .' et/ou (a)ᵀ doit être une syntaxe valide alternative (complètement équivalente).

Approche (1) de https://github.com/JuliaLang/julia/issues/20978#issuecomment -315902532, qui a reçu un bon support (par exemple https://github.com/JuliaLang/julia/issues/20978# issuecomment-316080448), reste une possibilité. J'ai une branche réalisant cette approche (présentant flip(A) ) que je peux publier.

Pour ce que ça vaut, je soutiens la dépréciation .' . La confusion et l'ambiguïté dans ce fil est un argument fort pour le faire en soi. Meilleur!

Je crois que tant que nous aurons le suffixe ' , les gens voudront l'utiliser pour diffuser f sur un produit cartésien de vecteurs avec f.(v, w') . Et les gens voudront l'utiliser pour remodeler un vecteur de chaînes en un vecteur ligne d'en-têtes pour une structure de type table. Il est donc impératif pour moi d'avoir un remplacement simple et facile à utiliser vers lequel nous pouvons les diriger.

Voici une option que nous n'avons pas envisagée : A*' — un nouveau bigraphe. La notation mathématique typique pourrait interpréter cela comme conj(A)' , ce qui est en fait assez proche de ce que nous voulons. Il était disponible sur la version 0.6, mais sur la version 0.7, nous autorisons l'utilisation * pour concaténer des caractères… toujours utilisable, cependant.

Je ne crois pas que les suffixes " et ` soient disponibles en raison de l'analyse littérale de chaîne personnalisée au-delà de la fin d'une ligne. Postfix * seul est également indisponible pour la même raison. Le suffixe prime A′ est probablement l'un des identifiants Unicode les plus couramment utilisés, c'est donc encore plus que Aᵀ .

Honnêtement, après avoir regardé mon code, je n'utilise pas du tout .' , donc transpose(a) est probablement bien.

Notez que je viens de parcourir les packages enregistrés et que j'ai trouvé plus de 600 utilisations de .', donc ce n'est pas très rare.

Cet endroit a-t-il été vérifié pour voir si .' n'a pas été utilisé là où ' aurait été correct ? Je commence à penser que cela pourrait être vrai plus souvent qu'autrement. Sinon, le seul endroit où j'ai vu une utilisation légitime de .' était avant que les étiquettes Plots.jl n'autorisent un vecteur (au lieu de cela, je voulais un vecteur ligne de chaînes), mais cela a été changé. Pour les codes où j'en ai vraiment besoin souvent, je pense que je commencerais à faire T = transpose localement, ou lancerais une macro pour changer ' en transpose .

<strong i="17">@transpose</strong> A = A'*A*B'*B*C'*C

serait très bien avec moi pour ce cas rare.

les gens voudront l'utiliser pour diffuser f sur un produit cartésien de vecteurs avec f.(v, w'). Et les gens voudront l'utiliser pour remodeler un vecteur de chaînes en un vecteur ligne d'en-têtes pour une structure de type table. Il est donc impératif pour moi d'avoir un remplacement simple et facile à utiliser vers lequel nous pouvons les diriger.

S'il n'apparaît qu'une seule fois dans une instruction, n'est-il pas acceptable d'utiliser simplement transpose ?

La syntaxe a*' pour conjugué-adjoint est plutôt sympa, bien qu'il ne semble pas vraiment que ce soit l'opération pour laquelle nous ayons besoin d'une meilleure syntaxe. &a sera bientôt disponible et suggère d'échanger des choses, bien que ce soit assez différent des notations traditionnelles pour cela.

Peut-être est-il temps pour un sondage de paille?

Comment devrions-nous épeler la transposition structurelle ?

(à peu près dans l'ordre de proposition ; pas de jugement sur les noms d'emoji ici)

• 👍 : A.' — changez simplement le sens, gardez la même syntaxe
• 👎 : transpose(A) — pas de syntaxe spéciale
• 😄 : t(A) ou tr(A) — pas de syntaxe spéciale, mais exporte un nom plus court
• 🎉 : Aᵀ — avec seulement ᵀ et peut-être un ou deux exposants en casse spéciale à partir des identifiants
• 😕 : (A)ᵀ — avec tous les exposants séparés des identifiants se comportant comme des opérateurs suffixés
• ❤️ : A*' – glose juste au-dessus de cette étrange vallée, cela signifie une transposition structurelle
• Si vous préférez &A , jetez un 🎉 sur le message de Stefan juste au-dessus (nous n'avons plus d'emoji)

Les discussions de LinAlg ont en effet parlé de donner .’ à une utilisation de transposition non récursive, puisque conj(x’) est relativement rare. Cependant, ᵀ est une syntaxe mathématique et devrait vraiment prendre le sens mathématique (le cas échéant).

S'opposent très fortement à ce tr(A) signifie une transposition matricielle - tout le monde va penser que cela signifie une trace matricielle : https://en.wikipedia.org/wiki/Trace_ (linear_algebra)

Si ce n'est pas le cas, déprécier les exposants en tant qu'identifiant (ce qui doit probablement être considéré sérieusement avant la version 1.0), alors ᵀ(A) est également une possibilité.

En ce qui concerne la suggestion (A)ᵀ , mes excuses pour avoir légèrement fait dérailler cette discussion avec la remarque suivante :

Je ne me suis jamais beaucoup soucié d'avoir √ disponible comme opérateur unaire, d'autant plus que vous finirez de toute façon par taper √(...) dès que vous voudrez l'appliquer à une variable qui est plus qu'un un ou plusieurs personnages. De plus, j'ai toujours trouvé la différence de fonctionnement entre a² et √a très artificielle. Cela a probablement du sens si vous connaissez les classes Unicode, etc., mais pour quelqu'un d'autre, cela doit sembler absurde. Bien sûr, il est utile d'avoir a² comme nom de variable valide, mais de même √a pourrait être un nom de variable utile pour stocker la racine carrée de a si vous avez besoin de l'utiliser plusieurs fois. Ou des expressions plus compliquées comme a²b et sa racine carrée a√b , où le premier est un identifiant valide et le second non. Par-dessus tout, j'aime la cohérence.

Donc, pour des raisons de cohérence, j'aime la proposition d'avoir des opérateurs postfixés lors de l'utilisation de parenthèses (A)ᵀ , (a)² , en combinaison avec la suppression de l'opérateur unaire Unicode √ (et ses parents) afin que il peut également être utilisé dans les identificateurs (tout en restant accessible en tant qu'appel de fonction normal √(a) ).

Je suis d'accord à 100% avec ce que @Jutho a dit et j'y ai pensé à plusieurs reprises. Cela vous dérangerait-il d'ouvrir un problème, @Jutho ? Proposition : autoriser √ dans les noms d'identifiant, exiger √(x) pour appeler en tant qu'op.

question suivante -> qu'en est-il de 2 |> √ ?

Discutons de √ dans un autre fil, mais en bref 2 |> √ signifie √(2) .

Une autre alternative, qui ne nécessiterait aucun changement d'analyseur et serait facile à taper, serait A^T pour la transposition (en définissant T comme étant un type singleton avec une méthode ^ ). … oh, je vois que @mbauman a eu cette idée aussi. C'est un peu moche, mais pas plus que A.' .

Je n'ai pas d'expertise, mais je suis très investi dans le résultat de cette discussion car qui tapera probablement des milliers de lignes contenant des expressions matricielles au cours de mon travail.

transpose(A) # with no special syntax remporte le vote ci-dessus, mais me fait mal aux yeux et aux doigts.

En python, l'utilisation courante est probablement avec numpy et beaucoup de choses qui ressemblent à ce qui suit et qui ne sont pas si mal :

import numpy as np
# define matrix X of n columns, with m rows of observations
error = X.dot(Theta.T) - Y
gradient = (1 / m) * (X.dot(Theta.T) - Y).T.dot(X)

Je ne voudrais pas avoir à faire :

grad = 1/m * transpose(X * transpose(Theta) - Y)) * X

Cela change totalement la conception mentale de la transposition par rapport à la convention sur laquelle la notation mathématique s'est établie, qui est un signifiant postfixé, généralement Aᵀ ou Aᵗ .

Personnellement, je suis très content de A' qui fonctionne dans Julia v.0.6, avant qu'il ne soit pris par adjoint. L'adjoint est-il très souvent utilisé ?

Voici mes commentaires dans un tableau :

Aᵀ or Aᵗ    if the world won't accept unicode operators, let them use transpose(A)
A'          close to math notation, easy to type and *especially* easy to read
A^'         this could signal `^` not to be parsed as Exponentiation.
A.'         conflicts with dotted operator syntax, but at face value OK
A^T or A^t  these are pretty good, but what if variable `T` is meant to be an exponent? 
A.T         same as numpy, same dotted operator collision
t(A)        nesting reverses semantics, 3 keystrokes and two of them with shift key.
transpose(A) with no special syntax     # please don't do this.

Personnellement, je suis très content de A' qui fonctionne dans Julia v.0.6, avant qu'il ne soit pris par adjoint. L'adjoint est-il très souvent utilisé ?

Je ne comprends pas, A' a toujours été l'adjoint de A . Nous avions l'habitude d'appeler la fonction sous-jacente ctranspose pour la transposition conjuguée, mais nous l'avons renommée en terme équivalent adjoint sans changement de fonctionnalité.

Si vous faites de l'algèbre linéaire, vous êtes beaucoup plus susceptible de vouloir une transposition conjuguée de toute façon, donc vous taperez A' plutôt que transpose(A) . La popularité de ne pas définir de syntaxe spéciale pour les transpositions non conjuguées est (vraisemblablement) due en partie au fait qu'il n'est vraiment pas si courant pour la plupart des utilisations algébriques linéaires de vouloir la transposition non conjuguée.

Si vous faites de l'algèbre linéaire, alors ...

Si votre outil est un marteau alors ... :)

... vous devez penser à la possibilité que Julia puisse évoluer vers un langage de programmation général.

Peut-être pas, peut-être que cela restera comme un argot d'algèbre linéaire - ce qui est une possibilité à laquelle doivent penser les programmeurs comme moi. :)

@mahiki , vous êtes un exemple NumPy :

import numpy as np
# define matrix X of n columns, with m rows of observations
error = X.dot(Theta.T) - Y
gradient = (1 / m) * (X.dot(Theta.T) - Y).T.dot(X)

s'écrirait littéralement en Julia comme suit :

error = X*Θ' - Y
gradient = (1/m) * (X*Θ' - Y)' * X

ou en supposant que les vecteurs sont des lignes dans cet exemple NumPy et seraient des colonnes dans Julia :

error = X'Θ - Y
gradient = (1/m) * (X'Θ - Y) * X'

qui semble à peu près aussi clair et mathématique que possible. Si vos données sont réelles, alors l'adjoint et la transposition sont la même opération, ce qui explique peut-être pourquoi vous utilisez la transposition ci-dessus - mais mathématiquement l'adjoint est la bonne opération. Comme @ararslan l' a dit, X' a toujours signifié adjoint dans Julia (et dans Matlab également). Il s'appelait auparavant ctranspose abréviation de « transposition conjuguée » mais ce nom était un abus de langage puisque la propriété déterminante de l'opérateur est que

dot(A*x, y) == dot(x, A'y)

qui est la propriété déterminante de l' adjoint hermitien mais qui est satisfaite par la transposée conjuguée lorsque A est une matrice complexe. C'est pourquoi "adjoint" est le bon terme générique pour cet opérateur.

Cela dit, j'ai voté ci-dessus pour transpose(a) et a.' car je pense que ce serait bien pour a.' de signifier une transposition structurelle. Cela fonctionnerait comme prévu, et même s'il ne serait pas récursif et donc pas "mathématiquement correct" dans certains codes génériques, le faire fonctionner comme prévu semble assez bon. Et dire aux gens d'envisager d'utiliser conj(a') dans du code générique semble être une chose éducative plutôt que quelque chose dont nous avons vraiment besoin pour frapper les gens par-dessus la tête.

@mahiki Si, pour une raison quelconque, vous avez vraiment besoin d'utiliser transpose au lieu de adjoint plusieurs fois dans votre code, vous pouvez définir une macro plus courte comme @t qui alias transpose (bien que je sache que cette solution n'est pas idéale, surtout si vous écrivez votre code avec d'autres personnes).

vous devez penser à la possibilité que Julia puisse évoluer vers un langage de programmation général.

@ Liso77 C'est déjà le cas. À titre d'exemple parmi tant d'autres, Nanosoldier exécute un serveur Web qui écoute les événements GitHub et exécute des tests de performance à la demande, le tout dans Julia. C'est une digression cependant, et je ne veux pas que ce fil sorte du sujet.

Si vous transposez une matrice quelconque avec des données non numériques, ce qui est un cas d'utilisation tout à fait valable, la notation de transposition mathématique semble en fait être un mauvais jeu de mots. Dans ce cas, je pense qu'il serait préférable d'être plus explicite sur ce que vous demandez, par exemple transpose (ou même permutedims , selon vos besoins spécifiques).

Si vous transposez une matrice quelconque avec des données non numériques, ce qui est un cas d'utilisation tout à fait valable, la notation de transposition mathématique semble en fait être un mauvais jeu de mots.

Étant donné que A.' n'est pas vraiment une "notation de transposition mathématique" au sens habituel, je ne vois pas si c'est un argument pour ou contre.

Je pense que @ararslan ne s'oppose pas à l'existant .' mais plutôt à l'introduction d'une syntaxe T en exposant. J'ai tendance à être d'accord - si vous voulez dire le concept d'algèbre linéaire d'adjoint, alors vous devriez utiliser ' (même si votre matrice est réelle). Et si vous avez une matrice de données non numériques, alors il est bien sûr parfaitement légitime de permuter les deux indices, mais cette opération n'est pas vraiment la "transposition" comme on le pense habituellement, et utiliser la notation mathématique en exposant-T est probablement plus susceptibles de confondre que de clarifier. La seule situation où une notation en exposant-T serait vraiment appropriée est si vous avez une matrice numérique dont vous voulez permuter les indices, mais vous ne voulez vraiment pas l'opérateur linéaire adjoint. De telles situations existent certainement, mais peuvent être trop rares pour justifier l'introduction d'une nouvelle syntaxe.

Réf. https://github.com/JuliaLang/julia/issues/20978#issuecomment -315902532. Meilleur!

... mais cette opération n'est pas vraiment la "transposition" comme on a l'habitude de la penser, ...

Si c'est si inhabituel, pourquoi ararslan et bien d'autres votent pour l'orthographe de la transposition structurelle comme transpose(A) ?

Merci @StefanKarpinski @ararslan @ttparker. J'ai dû revenir à mon texte d'algèbre linéaire et redécouvrir l'adjoint, c'est bien là-dedans. J'ai pris cela avant l'analyse complexe, probablement pourquoi je n'en ai pas tenu compte.

j'adore pouvoir faire ça
gradient = (1/m) * (X'Θ - Y) * X'

Ma confusion provient de l'utilisation généralisée de 'transposer' (en exposant T) dans les documents de référence, les articles, les manuels, etc., par exemple les notes de cours stanford CS229 d'Andrew Ng , où le code Julia correspondant utiliserait adjoint comme dans l'exemple épuré de @StefanKarpinski ci-dessus. C'est parce que l'adjoint et la transposition sont équivalents en ℝ (n'est-ce pas ?) . mise à jour : oui

Maintenant, ma notation préférée pour la transposition est simplement tout ce qui est logiquement cohérent. Il est clair .' n'est pas à cause d'un conflit avec la syntaxe de l'opérateur pointillé, et je n'ai aucune objection à ce que transpose(A) sans syntaxe spéciale, car aucune syntaxe spéciale sensée ne semble disponible, à l'exception d'un exposant unicode.

J'aime la solution @ttparker si je me retrouve à écrire beaucoup de transposition, macro @t qui alias transpose .

Encore une fois, je me suis trompé en disant :

transpose(A) with no special syntax # please don't do this.

Merci d'avoir pris mes commentaires au sérieux malgré ma faible facilité avec les mathématiques de niveau universitaire.

(Du discours .)

J'aimerais que ' soit un opérateur post-fixe qui mappe f' à '(f) où Base.:'(x::AbstractMatrix) = adjoint(x) et l'utilisateur est libre d'ajouter d'autres méthodes qui ont rien à voir avec les adjoints. (Par exemple, certaines personnes pourraient aimer que f' fasse référence à df/dt.)

Avec les suffixes d'opérateurs introduits dans la version 0.7, il serait alors naturel que f'ᵃ corresponde à 'ᵃ(f) , et ainsi de suite, permettant à l'utilisateur de définir ses propres opérateurs postfixés. Cela permettrait d'avoir Base.:'ᵀ(x::AbstractMatrix) = transpose(x) et Base.:'⁻¹(x::Union{AbstractMatrix,Number}) = inv(x) , etc.

Écrire A'ᵀ n'est peut-être pas aussi propre que Aᵀ , mais cela ne nécessiterait pas de déprécier les noms de variables se terminant par ᵀ .

À première vue, cela ressemble à une fonctionnalité incassable. C'est un compromis très astucieux. Je l'aime bien.

Cela me semble raisonnable. Le plus difficile est de trouver un nom pour la fonction ' — la syntaxe de préfixe ne fonctionne pas dans ce cas.

Le plus dur est de trouver un nom pour la fonction '

apostrophe ? Peut-être trop littéral...

Est-il possible de faire fonctionner la syntaxe de préfixe (par exemple, avec une syntaxe (')(A) explicite ?) ? Sinon, c'est un problème car cela enfreindrait la règle if-you-can-define-the-symbol-name-then-you-can-override-its-syntax introduite par https://github.com/JuliaLang /julia/pull/26380.

Edit : semble être disponible :

julia> (')(A)


ERROR: syntax: incomplete: invalid character literal

julia> (')(A) = 2


ERROR: syntax: incomplete: invalid character literal

Malheureusement, ' est l'un des caractères les plus difficiles à utiliser comme nom d'identifiant, car il introduit un autre type d'atome (caractères), qui a une priorité très élevée (égale à la priorité des identifiants eux-mêmes). Par exemple, (')' est-il une application de ' à lui-même, ou une parenthèse ouverte suivie d'un littéral ')' ?

Une option qui n'est pas pratique à court terme consiste à déclarer que les littéraux de caractères ne valent pas ' et à utiliser une macro de chaîne comme c"_" la place.

Que diriez-vous si ' est analysé comme un identifiant lorsqu'il est précédé d'un point-deux-points, de sorte que Base.:' fonctionnerait ?

Bien sûr, (@__MODULE__).:'(x) = function_body peut être un peu lourd à écrire, mais (x)' = function_body devrait fonctionner de la même manière. Edit : Non, puisque (x)' devrait correspondre à l'appel de ' dans Base . Définir une fonction ' dans le module actuel serait fastidieux, mais il n'y aurait aucune raison de le faire non plus.

Ou que diriez-vous de laisser '' analyser comme identifiant ' alors qu'il aurait autrement été analysé comme un littéral de caractère vide (ce qui est actuellement une erreur au niveau de l'analyse). De même, ''ᵃ serait analysé comme l'identifiant 'ᵃ , etc.

Tout ce qui n'est pas actuellement une erreur de syntaxe serait toujours analysé comme avant (par exemple 2'' est le suffixe ' appliqué deux fois à 2 ), mais 2*'' le serait maintenant analyser comme deux fois ' .

Il semble déroutant que nous ayons a'' === a mais ''(a) === a' . Il semble préférable d'utiliser Base.apostrophe comme nom à la place (ou quelque chose comme ça).

Serait-il préférable de diviser cette discussion en un nouveau problème Github, puisqu'il s'agit d'une syntaxe ' qui n'est pas directement liée à la transposition de la matrice ?

Existe-t-il un moyen automatisé de diviser les problèmes, ou dois-je simplement en ouvrir un nouveau et créer un lien vers la discussion ici ?

Le dernier

La seule situation où une notation en exposant-T serait vraiment appropriée est si vous avez une matrice numérique dont vous voulez permuter les indices, mais vous ne voulez vraiment pas l'opérateur linéaire adjoint. De telles situations existent certainement, mais peuvent être trop rares pour justifier l'introduction d'une nouvelle syntaxe.

Je suppose que je suis beaucoup trop tard pour la discussion, mais j'aimerais souligner une utilisation qui, à mon avis, mérite d'être mentionnée : appliquer la différenciation en étapes complexes à une fonction à valeur réelle qui a transpose à l'intérieur de ce. (J'ai personnellement compris que j'avais besoin .' dans MATLAB et Julia pour cette raison particulière.)

Je vais donner un exemple avec plusieurs occurrences de transpose (peut-être que je pourrais éviter de le faire de cette façon ?)

using LinearAlgebra

# f : Rⁿ → R
#     x  ↦ f(x) = xᵀ * x / 2
f(x) = 0.5 * transpose(x) * x

# Fréchet derivative of f
# Df : Rⁿ → L(Rⁿ, R)
#      x  ↦ Df(x) : Rⁿ → R (linear, so expressed via multiplication)
#                   h  ↦ Df(x)(h) = Df(x) * h
Df(x) = transpose(x) 

# Complex-step method version of Df
function CSDf(x) 
    out = zeros(eltype(x), 1, length(x))
        for i = 1:length(x)
        x2 = copy(x) .+ 0im
        h = x[i] * 1e-50
        x2[i] += im * h
        out[i] = imag(f(x2)) / h
    end
    return out
end

# 2nd Fréchet derivative
# D2f : Rⁿ → L(Rⁿ ⊗ Rⁿ, R)
#       x  ↦ D2f(x) : Rⁿ ⊗ Rⁿ → R (linear, so expressed via multiplication)
#                     h₁ ⊗ h₂ ↦ D2f(x)(h₁ ⊗ h₂) = h₁ᵀ * D2f(x) * h₂
D2f(x) = Matrix{eltype(x)}(I, length(x), length(x))

# Complex-step method version of D2f
function CSD2f(x)
    out = zeros(eltype(x), length(x), length(x))
    for i = 1:length(x)
        x2 = copy(x) .+ 0im
        h = x[i] * 1e-50
        x2[i] += im * h
        out[i, :] .= transpose(imag(Df(x2)) / h)
    end
    return out
end 

# Test on random vector x of size n
n = 5
x = rand(n)
Df(x) ≈ CSDf(x)
D2f(x) ≈ CSD2f(x)

# test that the 1st derivative is correct Fréchet derivative
xϵ = √eps(norm(x))
for i = 1:10
    h = xϵ * randn(n) # random small y
    println(norm(f(x + h) - f(x) - Df(x) * h) / norm(h)) # Fréchet check
end

# test that the 2nd derivative is correct 2nd Fréchet derivative
for i = 1:10
    h₁ = randn(n) # random h₁
    h₂ = xϵ * randn(n) # random small h₂
    println(norm(Df(x + h₂) * h₁ - Df(x) * h₁ - transpose(h₁) * D2f(x) * h₂) / norm(h₂)) # Fréchet check
end
# Because f is quadratic, we can even check that f is equal to its Taylor expansion
h = rand(n)
f(x + h) ≈ f(x) + Df(x) * h + 0.5 * transpose(h) * D2f(x) * h

Le point étant que f et Df doivent être définis en utilisant transpose et ne doivent pas utiliser l'adjoint.

Je ne pense pas que la méthode des étapes complexes soit super pertinente dans julia. N'est-ce pas un hack / une solution de contournement pour obtenir une différenciation automatique dans les cas où un langage prend en charge des nombres complexes intégrés efficaces, mais un type de nombre Dual efficace de manière équivalente ne peut pas être défini? Ce n'est pas le cas dans julia, qui a de très belles bibliothèques de différenciation automatique.

Je suis d'accord sur l'utilisation de numéros doubles au lieu de la méthode des étapes complexes et c'est un très bon point que vous soulevez (personnellement, j'ai déjà remplacé toutes mes évaluations de la méthode des étapes complexes par des évaluations à deux numéros dans Julia). Cependant, je pense qu'il s'agit toujours d'un cas d'utilisation valable, à des fins de démonstration, d'enseignement d'astuces (voir, par exemple, Nick Higham parlant de la méthode des étapes complexes à Julia Con 2018 ) et de portabilité (en d'autres termes, je crains que La version MATLAB du code ci-dessus utilisant des nombres complexes serait plus propre).

Venant du monde des ingénieurs et peut-être des physiciens qui utilisent des tableaux complexes plus que de vrais tableaux, ne pas avoir d'opérateur de transposition est un peu pénible. (La représentation de phaseur complexe pour une dépendance temporelle harmonique est omniprésente dans notre domaine.) Personnellement, je préférerais la syntaxe numpy de xH et xT, bien que ma seule considération soit la concision.

La densité de l'opérateur de transposition par rapport à la transposition hermitienne est d'environ 1 à 1 dans mon code. Donc la transposition non conjuguée est tout aussi importante pour moi. Une grande partie de l'utilisation de la transposition consiste à créer des produits externes et à dimensionner correctement les tableaux pour l'interfaçage avec un autre code ou pour la multiplication matricielle.

J'ai l'intention pour l'instant de simplement fournir une macro ou une fonction de caractère pour l'opération, mais quel est l'équivalent correct de l'ancienne fonctionnalité, transpose() ou permutedims() ?

transpose est destiné à l'algèbre linéaire et est récursif, et permutedims est destiné à l'arrangement non récursif de données de tout type.

Il est intéressant que vous disiez que vous utilisez autant la transposition que l'adjoint. J'avais l'habitude d'être le même, mais surtout parce que j'avais tendance à faire des erreurs là où mes données étaient réelles, donc j'avais tendance à transposer mais en fait l'adjoint était l'opération correcte (généralisé au cas complexe - l'adjoint était la bonne opération pour mon algorithme). Il y a (de nombreuses) exceptions valables, bien sûr.

Dans tout ce qui concerne l'électrodynamique, vous utilisez souvent des vecteurs de type spatial et souhaitez utiliser des opérations vectorielles dans R^n (généralement n=3), c'est-à-dire transpose en particulier, même si vos vecteurs sont à valeurs complexes parce que vous 'ai pris une transformée de Fourier. Il semble que @mattcbro parle de ce genre d'applications.

Cela étant dit, lorsque je lis des discussions sur la syntaxe, je pense souvent que pour moi, personnellement, je ne peux pas imaginer qu'une syntaxe légèrement plus détaillée soit ce qui ralentit ma vitesse ou mon efficacité de programmation. Penser à l'algorithme lui-même et à la manière la plus naturelle/efficace de l'implémenter prend beaucoup plus de temps.

Dans tout ce qui concerne l'électrodynamique, vous utilisez souvent des vecteurs de type spatial et souhaitez utiliser des opérations vectorielles dans R^n (typiquement n = 3), c'est-à-dire transposer en particulier, même si vos vecteurs sont à valeurs complexes car vous avez pris un Fourier transformer.

Pas nécessairement. Souvent, vous voulez des quantités moyennes dans le temps à partir des amplitudes de Fourier, auquel cas vous utilisez le produit scalaire complexe, par exemple ½ℜ[𝐄*×𝐇] est le flux de Poynting moyen dans le temps des composantes de Fourier complexes et ¼ε₀|𝐄|² est un densité d'énergie du vide moyenne dans le temps. D'autre part, puisque l'opérateur de Maxwell est (typiquement) un opérateur à symétrie complexe ("réciproque"), vous utilisez souvent un "produit intérieur" non conjugué pour l'algèbre (de dimension infinie) sur les champs 𝐄(𝐱) etc. sur tout l'espace.

C'est vrai, j'avais souvent le mot dans la première phrase, mais je l'ai apparemment supprimé :-).

Eh bien, si vous voulez y aller, les quantités électromagnétiques sont écrites de manière encore plus concise dans une formulation algébrique de Clifford, souvent appelée algèbre géométrique. Ces algèbres ont de multiples automorphismes et antiautomorphismes qui jouent un rôle critique dans la formulation de la théorie, en particulier lorsque l'on considère des problèmes de diffusion.

Ces algèbres ont généralement une représentation matricielle concise et ces morphismes sont souvent facilement calculés via une transposition complexe, une transposition hermitienne et une conjugaison.

Néanmoins, comme je l'ai dit plus tôt, mon utilisation principale de la transposition est souvent d'organiser mes tableaux pour qu'ils s'interfacent avec d'autres tableaux, d'autres codes et pour que la multiplication matricielle fonctionne par rapport à la dimension correcte d'un tableau aplati.

Personnellement, je préférerais la syntaxe numpy de xH et xT

Facile à implémenter maintenant en 1.0, et devrait être efficace :

function Base.getproperty(x::AbstractMatrix, name::Symbol)
    if name === :T
        return transpose(x) 
    #elseif name === :H # can also do this, though not sure why we'd want to overload with `'`
    #    return adjoint(x)
    else
        return getfield(x, name)
    end
end 

C'est étonnamment facile et plutôt soigné. L'inconvénient semble être que les utilisations orthogonales de getproperty ne se composent pas les unes avec les autres. Ainsi, toute personne implémentant getproperty sur son type de matrice spécifique devra implémenter le comportement générique à la main.

les utilisations orthogonales de getproperty ne composent pas

Hmm. Je me demande si cela implique que xT "devrait" avoir été abaissé à getproperty(x, Val(:T)) . Je frémis de penser à ce que cela ferait au pauvre compilateur.

Je suis sûr que tout le monde a son opinion - mais pour moi, c'est presque une fonctionnalité qu'il est difficile de créer une interface générique à partir de la syntaxe à points. Ne vous méprenez pas, c'est une fonctionnalité vraiment géniale et merveilleuse pour définir des structures nommées de type tuple, etc.

(Il est également possible d'ajouter assez facilement une couche de répartition Val à vos types).

Le code de @c42f fonctionne comme un charme. Malheureusement pour moi, j'essaie d'écrire du code qui fonctionne sur les versions 0.64 et supérieures, ce qui m'oblige à utiliser soit la transposition, soit ma propre fonction définie T(A) = transpose(A). Peut-être qu'une macro aurait été un peu plus propre et légèrement plus efficace.

Pour être clair, je ne suggère pas que définir ce getproperty particulier soit une bonne idée pour le code utilisateur. C'est juste susceptible de casser les choses à plus long terme ;-) Bien qu'un jour nous aurons peut-être une bonne idée des conséquences que nous pourrions avoir x.T défini dans Base .

Mais d'une manière générale, je me demande pourquoi ce type d'utilisation de propriété pour définir des "getters" dans des interfaces génériques est en fait mauvais. Par exemple, les fonctions getter de champs génériques ont actuellement un énorme problème d'espace de noms qui est simplement résolu par une utilisation judicieuse de getproperty . Il est bien plus agréable d'écrire x.A que d'écrire MyModule.A(x) , un nom de fonction plus long comme get_my_A(x) , ou d'exporter le nom extrêmement générique A d'un utilisateur module. Le seul problème tel que je le vois, est la possibilité attendue de remplacer la signification de .B pour les sous-types indépendamment du fait que .A soit défini de manière générique sur un super type. D'où le commentaire à moitié sérieux sur Val .

Idée amusante :

julia> x'̄
ERROR: syntax: invalid character "̄"

Le caractère ressemble un peu à un T mais c'est en fait un ' avec une barre dessus. Pas sûr que ce soit sérieux...

Ouais, ça me ressemble aussi sur GitHub. Mais c'est un overbar. Copiez et collez dans mon terminal montre:

Trop malin et mignon. J'aime toujours les caractères combinés, cependant, et je pense que 'ᵀ est bien.

-100 pour changer d'adjoint, car c'est l'une des choses géniales qui rend l'écriture de code Julia aussi claire que l'écriture de mathématiques, et la transposition conjuguée est généralement ce que vous voulez de toute façon, il est donc logique d'avoir une syntaxe abrégée pour cela.

Il y a une certaine arrogance dans une déclaration comme celle-ci. Considérez qu'une proportion finie de développeurs explicitement _ne veulent pas_ adjoint() mais _ont besoin_ transpose() .

Cas et point pour nous de travailler avec des calculs symboliques pour modéliser l'opérateur ' par défaut entraînerait par exemple le pseudo-inverse (A'*A)\(A *b) ou une forme quadratique v'*A*v pour revenir par erreur des résultats longs et complexes qui ne peuvent être réduits.

Peut-être que la solution est une sorte de directive du compilateur déclarant la signification de ' .