Julia: État des produits intérieurs dans Base

Pourriez-vous expliquer un peu plus votre cas d'utilisation et pourquoi l'avoir dans Base au lieu de simplement le définir dans votre package est avantageux ? Un exemple concret serait le mieux. Vous attendez-vous à plusieurs définitions inner dans des packages chargés simultanément ?

Je pense qu'avoir une interface formelle pour ces espaces mathématiques aidera les utilisateurs à mieux exploiter le système de typage. Par exemple, je m'attendrais à ce que les méthodes de clustering fonctionnent sur n'importe quel espace métrique. Si je pouvais définir mon type avec un produit intérieur, je bénéficierais de Clustering.jl prêt à l'emploi (après que le paquet soit corrigé en conséquence). De nombreux autres algorithmes basés sur la distance ou sur la projection pourraient également être généralisés.

Comme exemple concret, je suis tombé sur cette limitation aujourd'hui en essayant de définir une géométrie pour les données de composition : https://github.com/juliohm/CoDa.jl Je préfère me spécialiser sur une fonction inner bien connue défini dans Base que de définir ma propre interface dont personne d'autre ne sera au courant.

Pourquoi ne pas étendre dot pour vos types d'espace Hilbert ? Je suis à peu près sûr qu'il est conçu pour être le produit intérieur générique à l'esprit.

Le concept de produit scalaire est plus strict que le concept de produit scalaire. Alors que ce dernier est défini pour des espaces généraux, un produit scalaire n'est défini que lorsqu'il y a la notion d'un système de coordonnées défini par une base finie. La sémantique de dot(x,y) est x'*y où x et y représentent les coordonnées des objets dans un monde cartésien. Les manuels mathématiques mentionneront rarement le terme produit scalaire car les auteurs sont généralement intéressés à traiter le matériel dans des espaces plus généraux (pas nécessairement finis ni euclidiens).

Pour distinguer davantage, dans un espace de Hilbert avec un produit intérieur <x,y> (ou inner(x,y) ) les objets peuvent être infinis et la sémantique x'*y ne s'applique pas. Par exemple, dans l'analyse de données fonctionnelles, les objets sont les fonctions f et g et le produit interne est généralement obtenu par intégration numérique : inner(f,g) = quadrature(f*g) . Appeler cette opération un produit scalaire est trompeur.

Un autre exemple, comme je l'ai souligné dans mon package CoDa.jl , concerne les données de composition. Les objets de composition se trouvent dans un monde simplex pour lequel l'opération x'*y n'a aucun sens. Cependant, il existe une transformation isométrique (la transformation log-ratio) que l'on peut utiliser pour mapper des compositions dans une autre géométrie où l'on peut ensuite appliquer le produit scalaire avec des coordonnées. Travailler avec des coordonnées n'est pas nécessaire, mais c'est une pratique courante dans ce domaine. Le résultat peut être retransformé dans l'espace d'origine où les objets existent.

Je ne vois pas d'avantage à maintenir le terme dot dans le langage, mais si l'on demande une rétrocompatibilité, la généralisation inner(x::AbstractVector, y::AbstractVector) = dot(x,y) fonctionne parfaitement.

Pouvez-vous préciser les objections à ce changement ?

Pouvez-vous préciser les objections à ce changement ?

Nous avons généralement besoin d'une bonne quantité de justification pour ajouter de nouvelles fonctions publiques à Base, c'est l'objection. Cela pourrait être fourni par un package InnerProducts . Pourquoi doit-il être intégré au langage lui-même ? C'était la première question que @andreasnoack a posée ci-dessus - elle a reçu une réponse quelque peu vague de "Je pense qu'avoir une interface formelle pour ces espaces mathématiques aidera les utilisateurs à mieux exploiter le système de type". Il n'y a aucune raison pour qu'une interface définie dans un package soit moins formelle qu'une dans Base. Qu'est-ce que le fait d'avoir Base.inner offre que InnerProducts.inner n'offre pas ? C'est une vraie question qui pourrait avoir une réponse convaincante, mais je ne sais pas quelle pourrait être cette réponse, c'est pourquoi la question est posée.

Je ne vois pas de bon argument pour définir un concept mathématique de base comme les produits internes ailleurs qui ne sont pas dans Base. Un langage dont le public principal est l'informatique scientifique bénéficierait d'une terminologie correcte. Pourquoi le concept de norm est défini dans Base.LinAlg et inner , qui appartient à la même cohorte, devrait être défini dans un package ? Outre cette incohérence, le langage a déjà dot , ce qui me fait me demander pourquoi il devrait avoir quelque chose d'aussi spécifique plutôt qu'un concept plus général ?

Donc, vous voulez tous les concepts mathématiques possibles dans le langage de base ? Ne pas avoir quelque chose de défini dans Base n'oblige pas les gens à utiliser la mauvaise terminologie. La fonction norm est exportée depuis LinAlg car elle est définie et utilisée dans LinAlg . Similaire pour dot . Proposez-vous que dot soit renommé inner ?

Donc, vous voulez tous les concepts mathématiques possibles dans le langage de base ?

Je n'ai jamais dit cela.

Ne pas avoir quelque chose de défini dans Base n'oblige pas les gens à utiliser la mauvaise terminologie.

Je suis sûr que non. Promouvoir la mauvaise terminologie est le problème. Les personnes venant d'un milieu moins mathématique adopteront l'utilisation du point parce qu'elles le voient dans Base. L'utilisation du terme produit « scalaire » pour représenter le concept de produit intérieur est incorrecte. C'est également préjudiciable à la communauté mathématique, qui lutte de temps en temps pour réparer ces cicatrices laissées par une mauvaise terminologie. Les étudiants de ma génération doivent constamment se référer à de vieux livres pour obtenir la bonne terminologie, cela ne devrait pas être le cas.

Proposez-vous que le point soit renommé en intérieur

Ce serait déjà une amélioration majeure à mon avis. Voir tous les exemples que j'ai donnés ci-dessus sur les données fonctionnelles et compositionnelles. Les gens de ces communautés n'utiliseraient jamais le terme dot dans leur travail. "point" ressemble plus à un terme informatique qu'autre chose.

Renommer dot en inner est une proposition assez différente de l'ajout de inner à Base en plus de dot . C'est plus une question de « terminologie correcte », que vous et d'autres personnes de linalg devrez résoudre, bien que je me souvienne que nous avons fait un bikeshed une fois et avons conclu que dot était le nom correct pour ce que cette fonction implémente.

Il y a eu une petite discussion à ce sujet dans https://github.com/JuliaLang/julia/issues/22227 et https://github.com/JuliaLang/julia/pull/22220

Renommer le point en intérieur est une proposition assez différente de l'ajout d'inner à Base en plus du point.

C'est ce que j'ai proposé dans mon premier message dans ce fil :

J'aimerais proposer de renommer le point en intérieur, ou peut-être de demander aux utilisateurs de définir intérieur(x,y) comme un produit interne général entre les objets x et y

Je répète que le produit scalaire est le terme incorrect pour l'opération dont je parle ici. Produit intérieur, extérieur, scalaire... ce sont des objets mathématiques. "produit scalaire" est un objet de calcul : il obtient deux séquences de nombres et effectue x1*y1 + x2*y2 + ... xn*yn , une opération inutile dans d'autres espaces mathématiques.

Je m'étais concentré sur la deuxième option que vous avez proposée, qui semble avoir ajouté Base.inner avec une solution de repli pour appeler Base.dot . L'une ou l'autre option est possible, mais les deux nécessitent une justification : pour ajouter une nouvelle opération, il faut une raison pour laquelle elle ne peut pas simplement être dans un package (ce dont parlait la première partie de cette discussion) ; pour renommer, il faut décider que dot n'est pas le bon nom et inner est le bon (vers quoi la conversation semble s'être tournée).

@juliohm Il vaut probablement la peine de (ré)affirmer qu'il existe actuellement un effort actif pour réduire Base et encourager l'utilisation de packages. Dans ce cas, dot semble être correct pour tous les types participant à l'algèbre linéaire fournis dans Julia standard (c'est-à-dire Number et Array - donc oui, il existe un certain, connu , base finie dans tous les cas - je ne pense donc pas que nous nous soyons trompés de terminologie, bien qu'il puisse y avoir de meilleurs choix). Je ne suis pas contre cette proposition - mais je voulais le signaler pour clarifier pourquoi vous pourriez rencontrer une certaine résistance "latente" au changement.

Il convient également de garder à l'esprit qu'un bon nombre de nouveaux arrivants de Julia peuvent être familiers avec un produit scalaire mais pas avec un produit interne (par exemple, ils ont fait un peu de physique à l'université, mais ne sont pas des majors en mathématiques), il y a donc aussi quelques raisons de gardez dot (sans oublier que nous avons un opérateur infixe auquel il correspond - nous pourrions simplement le mapper à inner je suppose, mais c'est un peu moins évident). Nous n'avons pas non plus de fonction outer , ni une variété d'autres opérations possibles.

Ainsi, il est difficile de démontrer de manière raisonnable en quoi mettre this dans Base (ou LinAlg ) est strictement mieux que de le mettre dans un package utilisateur. La principale raison semble être de fournir une interface qui peut être partagée et étendue par d'autres - est-ce un résumé raisonnable ? L'argument consistant à laisser le code générique de Clustering.jl fonctionner avec votre produit interne semble assez convaincant. De plus, dans le contexte où nous semblons diviser LinAlg dans un package stdlib - je pensais que si je devais créer un package appelé LinearAlgebra , je serais probablement heureux d'inclure un inner fonction que d'autres peuvent étendre.

Merci @andyferris d'avoir partagé vos pensées. Je vois très clairement la résistance, ce qui ne me passionne pas beaucoup. Néanmoins, je suis curieux de savoir comment cette proposition spécifique conduit à une augmentation du code ? Pour moi, cela ressemble à un changement trivial de code avec une amélioration majeure de l'abstraction. L'exemple avec Clustering.jl n'est qu'un parmi tant d'autres, pensez à n'importe quelle méthode basée sur le noyau qui peut être conçue pour fonctionner avec des types Julia arbitraires pour lesquels la notion de produit interne existe. MultivariateStats.jl en a beaucoup.

En ce qui concerne le commentaire sur LinAlg divisé en un package séparé, je suis d'accord que cela semble être un bon endroit pour encapsuler des produits mathématiques. Je suppose que ce paquet LinearAlgebra du futur serait importé dans une session Julia par défaut et donc tous les utilisateurs auraient accès au concept de inner , outer , etc. tout de suite.

Oui, les bibliothèques standard sont toutes construites avec l'image système Julia et disponibles par défaut. Au moins pour la série v1.x, personne n'aura besoin de taper using LinAlg (je ne pense pas qu'il sera renommé LinearAlgbebra , d'ailleurs, je viens de l'inventer comme un concurrent hypothétique) .

Pour clarifier, il serait chargé avec Julia standard afin que vous n'ayez rien à installer, mais vous devriez toujours écrire using LinAlg pour obtenir les noms qu'il exporte.

C'est là que ça devient bizarre, n'est-ce pas, puisque nous aurons les méthodes * et ainsi de suite sans using LinAlg ? (en d'autres termes, LinAlg est un pirate de type).

Oui, c'est essentiellement là que nous devrons tracer la ligne : Base doit définir autant de fonctionnalités d'algèbre linéaire que nécessaire pour que LinAlg ne soit pas un pirate, donc matmul est défini dans Base car Array et * les deux le sont. Les types de matrice funky et les opérations non basiques y vivent cependant.

Permettez-moi de vous donner un exemple concret et de vous demander comment le résoudriez-vous avec l'interface actuelle, peut-être que cela peut clarifier les choses pour moi.

L'objectif est d'effectuer une analyse factorielle avec des données de composition. J'ai un type appelé Composition et un produit interne dans l'espace des compositions. Je collecte de nombreux échantillons (par exemple des échantillons de roche) et je les mets tous dans un gros Vector{Composition} (par exemple, composition = %eau, %grain, %air). Maintenant, je veux appeler un algorithme d'analyse factorielle implémenté dans un autre package (par exemple MultivariateStats.jl) sur ce vecteur de données. Comment implémenteriez-vous cela de manière générique sans avoir un produit inner importé par défaut ?

Ce que j'ai compris des derniers commentaires, c'est que MultivariateStats.jl et CoDa.jl devraient dépendre de LinAlg.jl. La dépendance dans MultivariateStats.jl consiste simplement à apporter le nom inner dans la portée. La dépendance dans CoDa.jl consiste à définir une méthode pour inner qui peut être appelée par MultivariateStats.jl. Est-ce ce que vous suggérez?

Il semble Composition{D} soit un espace vectoriel dimensionnel D sous + et * .

Je serais bien tenté de définir l'espace vectoriel dual.

Ainsi, vous pouvez définir adjoint(::Composition) -> DualComposition et *(::DualComposition, ::Composition) -> scalar (actuellement inner ). DualComposition n'aurait pas à faire grand-chose à part tenir un Composition à l'intérieur.

La première phrase de https://en.wikipedia.org/wiki/Dot_product semble suggérer que dot pourrait être une opération sur deux itérables. Nous pourrions le rendre récursif et le définir pour Number , et définir inner comme la fonction d'algèbre linéaire abstraite, qui se chevauche pour Number et AbstractArray .

Merci @andyferris , j'apprécie vos réflexions sur le double espace. Je préfère cependant ne pas compter sur un nouveau type pour cette tâche. La solution finale est inutilement complexe.

Ce que je veux comprendre, c'est pourquoi quelque chose comme:

inner(x,y) = sum(x.*y)
norm(x) = sqrt(inner(x,x))

export inner, norm

pas les bienvenus à Base ? Je suppose que c'est tout ce qui est nécessaire pour définir les noms de fonction de manière générique pour que les utilisateurs du langage se spécialisent. Gardez à l'esprit que je pose ces questions avec le véritable intérêt de comprendre le point de vue des développeurs principaux. Je tiens à le dire avant que la conversation ne s'engage à nouveau dans la mauvaise direction.

Du point de vue de quelqu'un qui s'intéresse aux mathématiques en général, il ne semble pas naturel que ces concepts ne soient pas exportés par défaut et qu'ils soient définis à l'intérieur de LinAlg . Je pense à LinAlg comme des implémentations de ces concepts de haut niveau pour les types de tableaux. Peut-être que tout mon travail ne nécessite pas d'algèbre linéaire sur les tableaux, mais je pourrais toujours bénéficier du concept de produit interne à travers les packages (par exemple, MultivariateStats.jl, Clustering.jl). De plus, je ne souhaite peut-être pas avoir LinAlg comme dépendance dans mon package, car ce n'est pas le cas.

Si je peux insister davantage, il y a le concept de produit intérieur, qui est indépendant des tableaux. Ce concept est représenté par l'instruction export inner dans Base. Il y a l' implémentation de produits internes pour les objets de type tableau représentant les coordonnées inner(x,y) = sum(x.*y) . Cette opération peut être définie comme une méthode de secours dans Base comme ci-dessus, si nécessaire.

Un autre exemple de cas d'utilisation est celui des méthodes de Krylov. Si vous avez par exemple des espaces fonctionnels avec des produits internes, vous pouvez utiliser les méthodes de Krylov pour approximer un problème linéaire ou un problème propre dans un petit sous-espace de dimension finie de cet espace fonctionnel de dimension infinie.

J'ai aussi mes propres objets qui forment un espace vectoriel/Hilbert mais ne font pas partie de <: AbstractArray . D'après l'analogie qui montre également que les tableaux de rang N>1 forment des espaces vectoriels et peuvent être utilisés comme "vecteurs" dans les méthodes de Krylov, j'en suis venu à m'appuyer sur l'utilisation vecdot et vecnorm étant la notion généralisée de produit interne et de norme. J'ai donc développé un package avec des méthodes Krylov qui utilise des fonctions comme opérateurs linéaires et où les 'vecteurs' peuvent être de n'importe quel type, à condition que les objets de ce type prennent en charge vecdot , vecnorm et quelques d'autres choses ( scale! , zero , ...). Mais peut-être que cela abuse de ce que signifiaient ces concepts dans Base, il serait donc bon de redresser l'interface correcte ici.

À droite - vecdot pourrait être renommé inner .

(Maintenant, je me demande vaguement si norm devrait en fait être appelé matrixnorm pour les matrices avec norm correspondant toujours inner . Il semble qu'il y ait peut-être deux distincts il se passe des choses avec norm ce qui cause quelques difficultés à le généraliser)

En fait, pour les objets généraux de type vectoriel, il est également utile d'interroger la dimension de l'espace vectoriel (par exemple, pour vérifier que la dimension de Krylov ne doit pas être supérieure à la dimension de l'espace complet dans mon exemple de cas d'utilisation). L'exemple des tableaux imbriqués montre que length n'est pas le bon concept ici, c'est-à-dire qu'il faudrait une notion récursive de longueur pour ces cas.

Maintenant, pour l'exemple d'utilisation de tableaux imbriqués comme vecteur général, vecdot et vecnorm ne sont même pas dans certains cas la notion correcte de produit interne et de norme, comme indiqué dans #25093, c'est-à-dire qu'ils sont n'appelant pas récursivement vecdot et vecnorm . Mon interprétation de ces fonctions en tant que produit interne générique et fonction de norme est ce qui a déclenché # 25093, mais il semble que ce ne soit peut-être pas ainsi que ces fonctions étaient destinées (je ne sais pas ce qu'elles étaient censées faire à la place).

Je suis donc d'accord sur le fait que nous avons besoin d'une interface cohérente ici à utiliser sur tous les packages, qui appartiendrait donc à un emplacement central (probablement pas dans Base mais certainement dans une bibliothèque standard, par exemple de telle sorte que l'on doive faire using VectorSpaces ). Quant au nommage, je vois deux options :

Option 1 (mon interprétation jusqu'à présent):
le préfixe vec indique la propriété de cet objet lorsqu'il est interprété comme un vecteur générique, d'où

• vecdot et vecnorm pour les tableaux imbriqués sont corrigés (PR #25093)
• une nouvelle définition veclength est ajoutée

Option 2 (probablement meilleure) : utilisez des noms plus mathématiquement corrects

• inner
• dimension
• Mais que faire de norm ?

Et enfin, envoyez un ping à @stevengj car il aura certainement des commentaires utiles ; mes excuses si cela est gênant.

Le nom est la partie la moins intéressante de tout cela. Je n'ai aucun problème avec l'utilisation de la fonction dot pour faire référence à un produit intérieur général pour des espaces de Hilbert arbitraires. Non seulement il n'y a pas d'autre signification raisonnable pour, par exemple, "produit scalaire de deux fonctions", mais il est assez courant de voir "produit scalaire de fonctions" dans un usage informel, en particulier dans les contextes pédagogiques où l'on essaie de souligner l'analogie avec le vecteur de dimension finie les espaces.

@juliohm , inner(x,y) = sum(x.*y) n'est même pas un produit interne en général, donc ce serait une solution de repli assez terrible à mettre dans la base.

Mais dot ne calcule déjà pas le produit interne correct (en fait, il échoue) pour divers objets de Base qui se comportent comme des vecteurs, par exemple des tableaux de rang N>1 ou des tableaux imbriqués (les vecteurs imbriqués étant le seul cas où il fonctionne correctement). De plus, le nom générique norm devient ambigu pour les matrices, car je suis d'accord avec le choix actuel d'avoir ce retour la norme induite, mais parfois la "norme vectorielle" (norme de Frobenius) est également requise.

Par conséquent, ma proposition la moins impactante serait de laisser tomber la sémantique vecnorm(x) = norm(vec(x)) et d'interpréter plutôt vecnorm(x) comme "pour x étant un objet d'un type générique qui se comporte comme un espace vectoriel, calculez la norme vectorielle correspondante de x " (et similaire avec vecdot ). Bien qu'il s'agisse d'un changement d'interprétation (et donc de documentation), l'implémentation/l'action réelle pour les objets dans Base ne serait pas très différente (PR #25093) et produirait le même résultat dans la plupart des cas (rang N arrays de scalaires ou de vecteurs). Une fonction veclength(x) qui renvoie la dimension d'espace vectoriel correspondante de x compléterait l'interface.

Les packages personnalisés doivent alors apprendre à implémenter ces fonctions lorsqu'ils définissent de nouveaux types qui se comportent comme des vecteurs.

il est assez courant de voir le "produit scalaire de fonctions" dans un usage informel, en particulier dans les contextes pédagogiques où l'on essaie de souligner l'analogie avec les espaces vectoriels de dimension finie

S'il vous plaît, ne dites pas que le nom n'est pas important, car il l'est. Je vais répéter pour la énième fois : produit scalaire et produit scalaire ne sont pas la même chose. Tout matériel sérieux exposant un travail avec des espaces abstraits de Hilbert n'utilisera jamais de "point". Si vous préférez faire confiance à Wikipédia plutôt qu'à mes propos, voici les définitions copiées-collées :

Produit intérieur

En algèbre linéaire, un espace de produit interne est un espace vectoriel avec une structure supplémentaire appelée produit interne. Cette structure supplémentaire associe chaque paire de vecteurs dans l'espace à une quantité scalaire appelée produit scalaire des vecteurs.

Produit scalaire

En mathématiques, le produit scalaire ou produit scalaire est une opération algébrique qui prend deux séquences de nombres de longueur égale (généralement des vecteurs de coordonnées) et renvoie un seul nombre.

Cette résistance à améliorer la terminologie et la cohérence mathématique dans la langue est démotivante. Peu importe le nombre de faits que je vous présente, peu importe le nombre d'exemples et de cas d'utilisation, il n'y a pas d'autre contre-argument que "je suis d'accord avec le point".

@juliohm , la terminologie est une question de convention, pas d'exactitude. Je conviens que dans l'usage formel des espaces de Hilbert, en particulier ceux de dimension infinie, le terme «produit interne» est utilisé à peu près exclusivement. Mais, comme je l'ai dit, si vous recherchez "fonctions de produit par points" sur Google, vous trouverez également de nombreuses utilisations informelles de cette terminologie. Si vous dites "prenez un produit scalaire de deux éléments de cet espace de Hilbert", chaque mathématicien saura que vous faites référence à un produit interne, même pour des espaces de dimension infinie, il n'y a donc pas de réel danger de confusion, car il n'y a pas d'autre généralisation standard du terme "produit scalaire". C'est pourquoi je ne trouve pas que le débat sur l'orthographe entre "point" et "intérieur" soit une question centrale.

Il est important de décider de la sémantique que l'on veut ici, et de l'ensemble des fonctions que les types doivent implémenter s'ils définissent un nouvel espace de Hilbert ou un espace de Banach. Actuellement, si vous souhaitez définir un type représentant un nouvel espace de Hilbert, vous devriez sans doute définir dot et norm (puisque nous manquons actuellement de solution de repli pour ce dernier), et je suppose que adjoint si vous voulez le mappage vers un objet à double espace.

Comme le dit @Jutho , tout cela est compliqué par le cas du tableau de tableaux, car il y a plusieurs choses possibles que l'on pourrait vouloir là-bas. Puisqu'il n'y a pas de noms standardisés pour toutes les sémantiques possibles, il est difficile de trouver des noms/sémantiques qui satisferont tout le monde. Voir le #25093 pour la discussion de la sémantique vecdot . Je n'ai pas de bonne réponse ici, moi-même.

Quelques possibilités ici

1. Somme de x[i]' * y[i] . Actuellement, c'est dot(x,y) . Pas un produit interne pour les vecteurs de matrices (où il donne une matrice), et actuellement pas défini pour les tableaux multidimensionnels.
2. Somme de dot(x[i], y[i]) , y compris pour les tableaux multidimensionnels, et conj(x)*y pour Number . Actuellement, c'est vecdot(x,y) .
3. Certaines fonctions, par exemple inner(x,y) sont définies comme étant toujours un vrai produit interne, et pour les tableaux, faites-en la somme inner(x[i],y[i]) - essentiellement le "vecdot récursif" que @Jutho veut. Mais alors, pour les matrices A , ce produit scalaire est incompatible avec la norme induite norm(A) qui est notre définition actuelle norm . Pour résoudre ce problème, nous devrions modifier norm(A) pour que les matrices adoptent par défaut la norme de Frobenius, ce qui serait potentiellement un changement radical de grande envergure.

Une question (partiellement discutée dans # 25093) est de savoir si nous avons besoin de ces trois éléments dans Base, ou si nous pouvons nous en tirer avec deux (et lesquels deux, et comment les appelons-nous). La proposition de @ Jutho , si je comprends bien, consiste essentiellement à éliminer l'option 2 dans Base, puis à utiliser vecdot et vecnorm pour l'option 3. Nous avons alors un véritable produit interne, mais la terminologie est plutôt unique à Julia, et un peu étrange pour, par exemple, les espaces de Hilbert de dimension infinie. Ce ne serait pas la fin du monde, bien sûr.

Une autre possibilité (quelque peu indépendante de ce que nous faisons avec vecdot ) serait de revenir à exiger que dot soit un véritable produit intérieur. c'est-à-dire éliminer le comportement 1 et rendre dot(x::AbstractVector, y::AbstractVector) égal à sum dot(x[i],y[i]) . Ne le définissez toujours pas pour les tableaux multidimensionnels (pour rester cohérent avec norm ).

Mon penchant personnel actuel serait de définir dot comme un véritable produit intérieur (qui devrait être cohérent avec norm ), en le changeant en somme de dot(x[i],y[i]) pour les vecteurs (c'est-à-dire en changeant le cas du vecteur de matrices), et en continuant à ne pas le définir pour les tableaux multidimensionnels. Définissez ensuite vecdot pour appeler récursivement vecdot comme le suggère @Jutho , avec un repli vecdot(x,y) = dot(x,y) . Enfin, disons que les nouveaux types "Hilbert-space" doivent définir dot et norm . Cela me semble être le changement le moins perturbateur et le plus compréhensible.

(Un repli norm(x) = sqrt(real(dot(x,x))) est également une possibilité, bien qu'il soit quelque peu dangereux car il est vulnérable à un débordement intempestif. Notez que nous ne pouvons pas utiliser sqrt(dot(x,x)) comme repli pour des raisons techniques : nous voulons un résultat Real , pas un résultat Complex .)

Merci @stevengj pour cette réaction informative. Juste un petit commentaire :

avec un repli vecdot(x,y) = dot(x,y) . Enfin, disons que les nouveaux types "Hilbert-space" doivent définir dot et norm .

Il y a deux problèmes avec cela. vecdot(x,y) = dot(x,y) fallback ne peut pas exister, car vecdot accepte déjà les arguments Any pour traiter les itérateurs généraux. Le deuxième problème est que, si dot et norm sont exposés comme étant le véritable produit interne et la norme que tout vecteur comme le type d'utilisateur devrait définir, alors même lors de l'écriture d'un package avec, par exemple, des méthodes Krylov qui devrait fonctionner avec des types de vecteurs complètement génériques, cela ne fonctionnera toujours pas dans le cas où l'utilisateur souhaite utiliser des tableaux imbriqués ou multidimensionnels comme objets de type vecteur. Par conséquent, je dirais que vecdot et vecnorm sont le produit interne général et la norme des objets de type vectoriel. Cela correspond également bien au fait que pour les matrices, la plupart des gens s'attendront en effet à ce que norm soit la norme induite de la matrice/de l'opérateur.

Comme pour un cas d'utilisation réel (pour montrer qu'il ne s'agit pas d'un cas exceptionnel). Les matrices stochastiques ont une valeur propre la plus grande (Perron-Frobenius) pour laquelle le vecteur propre correspondant représente une distribution de probabilité à point fixe. Dans sa généralisation quantique, la distribution de probabilité se généralise à une matrice définie positive (la matrice de densité) et une telle matrice est le point fixe (vecteur propre correspondant à la plus grande valeur propre) d'une carte complètement positive, c'est-à-dire la carte rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) où donc rho est la matrice de densité et A[i] est une matrice pour chaque i (connu sous le nom d'opérateurs de Kraus représentant la carte complètement positive). Pour les grandes dimensions de matrice, une méthode Arnoldi est idéale pour trouver la matrice de densité à point fixe.

Mon inclination personnelle actuelle serait de définir le point comme un véritable produit interne (qui devrait être cohérent avec la norme), en le changeant en somme de point (x [i], y [i]) pour les vecteurs. Enfin, disons que les nouveaux types « d'espace de Hilbert » devraient définir le point et la norme.

C'est déjà une énorme amélioration. Documenter dot pour avoir la sémantique inner dans Base permettra au moins aux utilisateurs de définir leurs propres espaces sans importer de bibliothèques inutiles. Je ne suis pas satisfait de la dénomination, mais au moins la fonctionnalité serait disponible pour ceux qui en ont besoin.

Oui, je pense que ce sera bien d'avoir une interface documentée à implémenter pour les types "Hilbert-space".

Bien sûr, en pensant à cette interface générique pour les espaces vectoriels, si elle inclut norm comme suggéré ci-dessus, cela devrait être la norme de Frobenius pour les matrices (et généraliser pour les tableaux de plus grande dimension, puisque tous les tableaux sont des éléments d'un vecteur espacer). Dans ce cas, nous aurions besoin d'une fonction "norme d'opérateur" distincte pour les matrices ( matnorm ou opnorm ou quelque chose, ou un argument de mot-clé sur norm ...).

@andyferris , veuillez noter mon dernier commentaire. norm et dot ne peuvent pas devenir l'interface spatiale générale de Hilbert, car ils ne fonctionnent même pas sur des objets vectoriels dans Julia, tels que des tableaux de plus grande dimension et des tableaux imbriqués. Par conséquent, vecdot et vecnorm sont un "meilleur" candidat (dans le sens de la moindre rupture) pour cela.

Relancer ce sujet, que je considère tout à fait pertinent pour le type de mathématiques que je compte faire avec la langue dans un avenir proche. Existe-t-il un consensus sur ce qui sera fait pour améliorer la généralité et la sémantique des produits internes ?

Voici la partie de mon ontologie mathématique personnelle concernant le produit.
Si cela pouvait aider à rafraîchir la mémoire / apporter un consensus

• produit scalaire ; synonymes : produit scalaire
• produit intérieur
• produit croisé
• produit tenseur ; synonymes : produit extérieur
• produit en coin ; synonymes : produit extérieur
• produit de tasse
• triple produit

Bonus : pas de références wikipedia

À ce stade, la proposition de @Jutho dans # 25093 semble être le changement le moins perturbateur, même si la terminologie vec* me semble un peu étrange dans ce contexte.

Je suis d'accord que la terminologie vec* est étrange. C'est pourquoi renommer les fonctions pour qu'elles aient des noms standard serait bénéfique pour tous les utilisateurs.

Je suis également d'accord que la terminologie vec* est étrange.

Je suis d'accord, comme alternative à vecdot , nous pourrions introduire une nouvelle méthode inner , mais je ne connais pas de bon nom pour "remplacer" vecnorm . En fait, je ne trouve pas vecnorm si mauvais, la norme vectorielle est un terme bien établi et explicite pour l'opération que nous voulons.

Le problème de base ici concerne les matrices et les tableaux multidimensionnels, pour lesquels le norm(A) habituel ne correspond pas à un produit interne, ainsi qu'avec les tableaux de tableaux comme indiqué ci-dessus. Une désambiguïsation (par exemple vec* ou fro* ) est nécessaire dans ces cas pour indiquer quel produit intérieur est prévu.

Vous pourriez avoir une fonction inner dont la valeur par défaut est vecdot , mais c'est un peu idiot d'avoir deux noms pour la même fonction, et il y a toujours le problème de savoir comment appeler la norme.

Je trouve aussi le nom vecdot étrange, en fait, je ne savais même pas qu'il existait et j'avais créé ma propre fonction pour cela... appelée inner .

Ma compréhension est que nous pouvons simplement déprécier l'étrange vecdot en faveur de inner , et lui donner la sémantique interne du produit pour que les utilisateurs implémentent leurs propres espaces.

Concernant les norm , ça je ne sais pas. J'ai ouvert ce sujet pour discuter des produits internes, peut-être qu'un autre sujet serait approprié pour discuter de l'état des normes dans Base.

Je suppose que nous pourrions avoir inner(x,y) et innernorm(x) = sqrt(inner(x,x)) (avec des cas spéciaux optimisés pour éviter le débordement) au lieu de vecdot et vecnorm . innernorm est légèrement inhabituel mais est raisonnablement clair dans son contexte.

Bravo pour ce changement. Les noms inner et innernorm sont clairs et cohérents avec les concepts. Je souhaite qu'ils puissent arriver à Julia v1.0.

inner et innernorm me semblent corrects.

Je dirais quand même qu'à mon avis, notre fonction norm ne s'intègre pas très bien dans la fonction générique et le système de répartition de Julia et ce que j'appellerais des "interfaces claires" où la répartition ne devrait pas faire des choix sémantiques, juste des choix d'implémentation. Personnellement, je préférerais que nous puissions dire " norm renvoie la norme d'un élément d'un espace vectoriel", où les matrices et les opérateurs linéaires sont toujours des éléments d'espaces vectoriels (vous pouvez les additionner et les multiplier par un scalaire) . Nous pourrions également avoir par exemple " opnorm renvoie la norme d'opérateur d'un opérateur linéaire" (ou matnorm ou autre).

Pour le moment nous avons " norm renvoie la norme d'un élément d'un espace vectoriel, sauf si l'élément est aussi un opérateur linéaire, auquel cas nous vous donnerons la norme de l'opérateur à la place". Je pense personnellement que la dépêche ne devrait jamais être surprenante.

C'est-à-dire que je préférerais une fonction qui fait toujours la norme vectorielle et une autre fonction qui fait toujours la norme de l'opérateur, et aucune fonction qui essaie de faire les deux.

J'aime encore mieux @andyferris :+1: Des normes spécifiques qui ne sont pas les normes induites par le produit intérieur dans l'espace pourraient avoir un nom plus spécifique. Le nom norm signifierait exactement norm(x) = sqrt(inner(x,x)) et pourrait être redéfini selon les besoins pour les types d'utilisateurs.

Personnellement, je préférerais que nous puissions dire " norm renvoie la norme d'un élément d'un espace vectoriel"

La fonction actuelle norm satisfait cette définition. Pour les matrices, il calcule la norme induite (opérateur), qui est une norme parfaitement valide pour un espace vectoriel . (Les espaces vectoriels n'ont pas du tout besoin d'avoir des produits internes ou des normes.)

Vous pouvez être quelque peu confus quant à la définition d'une "norme" si vous pensez que la norme de l'opérateur n'est pas une "norme d'un espace vectoriel".

C'est aussi une distinction utile entre norm et innernorm . Si vous définissez norm , je dirais que cela implique seulement que vous avez un espace de Banach (ou au moins un espace vectoriel normé). Si vous définissez innernorm , cela implique que vous avez un espace de Hilbert (ou au moins un espace de produit intérieur) et que cette norme est cohérente avec inner .

Par exemple, l'intégration numérique adaptative (ala quadgk) est quelque chose qui ne nécessite qu'un espace vectoriel normé, pas un espace de produit interne.

Bien sûr, désolé, j'ai peut-être été un peu trop imprécis avec mon langage. Il existe évidemment de nombreuses normes valides pour un espace vectoriel, y compris diverses normes d'opérateurs.

Je suppose que ce que je veux dire, c'est que je préférerais peut-être que le choix de la norme soit plus explicite qu'implicite ? Et que si vous utilisez la même fonction (sans par exemple des arguments de mots clés supplémentaires), vous obtenez la "même" norme, auquel cas l'Euclidean semble être un choix quelque peu défendable pour AbstractArray .

C'est aussi une distinction utile entre norm et innernorm . Si vous définissez la norme, je dirais que cela implique seulement que vous avez un espace de Banach (ou au moins un espace vectoriel normé). Si vous définissez innernorm , cela implique que vous avez un espace de Hilbert (ou au moins un espace de produit interne) et que cette norme est cohérente avec inner .

Cela semble raisonnable, mais je me demande toujours pourquoi si un objet a un innernorm , il aurait besoin d'un autre norm ? Je proposerais alternativement que l' interface pour l'espace Banach nécessite norm tandis qu'une interface pour les espaces de produits internes fournirait à la fois norm et inner . Ces fonctions peuvent ensuite être utilisées dans du code générique qui attend des objets de Banach ou des espaces de produit interne, selon le cas (EDIT : en pensant que le code qui fonctionne dans les espaces de Banach fonctionnera automatiquement également sur les espaces de produit interne).

Je pense que vous proposez que norm(x) se réfère toujours à une sorte de norme euclidienne élément par élément (c'est-à-dire une norme Frobenius pour les matrices), c'est-à-dire fondamentalement ce que vecnorm est maintenant modulo le cas récursif. Dans ce cas, nous pourrions tout aussi bien redéfinir dot(x,y) comme étant le produit intérieur correspondant ( inner fonctionne aussi, mais dot a l'avantage d'une variante infixe x ⋅ y ).

Je suis d'accord avec cela en principe, mais ce serait un changement radical et il pourrait être un peu tard avant 0,7 pour l'intégrer…

Est-ce que L2 est aussi un bon défaut en haute dimension ?
Cet article parle de distance, mais peut-être concerne-t-il aussi la norme
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

Dans ce cas, nous pourrions tout aussi bien redéfinir dot(x,y) comme étant le produit scalaire correspondant (inner fonctionne aussi, mais dot a l'avantage d'une variante infixe x ⋅ y)

Pouvons-nous nous débarrasser entièrement de dot ? La notation infixe ne doit pas être liée à l'existence d'une fonction appelée dot . Définissez simplement l'infixe avec la méthode inner pour les tableaux Julia. Est-ce possible?

C'est vraiment ce que c'est, le produit scalaire : une notation pratique x ⋅ y pour les produits internes entre les vecteurs x et y dans R^n avec la géométrie euclidienne.

@stevengj Je pense que c'est un bon résumé, oui.

@o314 L2 est-il un bon défaut en haute dimensionnalité ? Peut-être pas, mais je détesterais vraiment ça si, par exemple, la norme choisie par norm(v::AbstractVector) dépendait de length(v) :) Je n'aimerais pas non plus qu'il devine si ma matrice ou un tableau de dimension supérieure est "trop ​​grand pour L2" - je suggérerais que cela devrait peut-être être explicitement marqué par l'utilisateur ?

@juliohm C'est tout à fait possible, même si, comme mentionné, ce sont des changements de rupture que nous suggérons. (Encore une fois, modulo ce qu'il faut faire dans le cas récursif et les discussions précédentes sur les différences possibles entre inner et dot ).

@stevengj , mon interprétation de ce que @andyferris impliquait est que, à cause du typage de canard, il est difficile de décider si un utilisateur veut interpréter un objet comme un vecteur (et utiliser un vecteur correspondant p -norm) ou en tant qu'opérateur (et calculer une p -norme induite). Je pense donc qu'il n'y a pas d'autre choix que de spécifier explicitement quel comportement est recherché. L'approche actuelle est un peu étrange dans le sens où norm essaie de deviner implicitement s'il faut choisir la norme vectorielle ou la norme induite en fonction de l'entrée, et vecnorm est un moyen de spécifier explicitement que vous voulez la norme vectorielle (c'est aussi pourquoi je ne trouve pas vecnorm un si mauvais nom). Un changement plus radical serait de faire en sorte que norm toujours par défaut la norme vectorielle, et de spécifier explicitement quand vous voulez la norme induite, en utilisant un argument (mot-clé) ou une fonction complètement différente.

D'un autre côté, cela ne me dérange pas non plus le nom innernorm , qui est explicite en ce qu'il s'agit d'une norme basée sur un produit interne (c'est-à-dire toujours p=2 dans le cas euclidien). J'ai du mal à juger si pour les objets personnalisés (vec)norm devrait prendre en charge un argument optionnel p dans le cadre de l'interface, puisque dans certains de mes cas d'utilisation, seulement p=2 est facile à calculer.

C'est vraiment ce que c'est, le produit scalaire : une notation pratique x ⋅ y pour les produits internes entre les vecteurs x et y dans R^n avec la géométrie euclidienne.

Je suis d'accord avec cela, dans le sens où je ne me souviens pas avoir jamais vu la notation x ⋅ y dans le contexte d'espaces vectoriels généraux (par exemple complexes). Je pense que seule la notation mathématique (x,y) ou la notation de Dirac < x | y > est utilisée dans de tels cas. En électromagnétisme, on utilise souvent E ⋅ B pour les vecteurs dans l'espace euclidien tridimensionnel, et même si l'on utilise une notation complexe (c'est-à-dire des phaseurs), cela n'implique pas de conjugaison complexe. Si nécessaire, la conjugaison complexe est notée explicitement dans de tels cas. Donc, cela ne me dérangerait pas si dot devenait simplement sum(x_i * y_i) sans conjugaison complexe ou hermitienne, et que inner devenait le produit interne correct pour les espaces de produits internes généraux. Malheureusement, cela ne peut probablement pas être fait en un seul cycle de publication.

L2 est-il un bon défaut en haute dimensionnalité ? Peut-être pas, mais je détesterais vraiment ça si, par exemple, la norme choisie par norm(v::AbstractVector) dépendait de length(v) :) Je n'aimerais pas non plus qu'il devine si ma matrice ou mon tableau de dimension supérieure est "trop ​​gros pour L2" - Je suggérerais que cela devrait peut-être être explicitement marqué par l'utilisateur ?

Je travaille dans le monde du BIM où l'on gère du 2d et du 3d, mais aussi du 4d, du 5d, du 6d voire du 7d. Nous n'allons jamais plus loin. A tout moment nous savons dans quelles dimensions nous travaillons, et quel algo est impliqué. C'est largement suffisant.

Je ne peux pas exprimer le pov des gens qui travaillent dans le ML, la recherche d'information etc. Là, peut être norminf c'est mieux. Ce qui est important dans mon point de vue, c'est la possibilité de deviner et la stabilité. Je ne serais pas du tout choqué si les gens de ML avaient besoin de différents paramètres par défaut pour leurs affaires. S'il n'y a pas de confusion. Par exemple. il est décidé explicitement et statiquement au moment de la compilation. C'est même du luxe s'il reste stable et consistant lors de l'application d'algos.

Inspiré de array:similar Pas entièrement implémenté et testez-le.

norm2 = x -> x |> inner |> sqrt
norminf = ...
NMAX = 10
for N in 1:NMAX
    <strong i="13">@eval</strong> begin norm(a::Array{T,N}) where {T} = norm2 end
end
norm(a::Array{T,n}) where {T} = norminf

Pouvons-nous nous débarrasser entièrement du point ? La notation infixe ne doit pas être liée à l'existence d'une fonction appelée point. Définissez simplement l'infixe avec la méthode interne pour les tableaux Julia. Est-ce possible?

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L498
vecdot(x::Number, y::Number) = conj(x) * y # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L657
dot(x::Number, y::Number) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L659
function dot(x::AbstractVector, y::AbstractVector) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L677

# Call optimized BLAS methods for vectors of numbers
dot(x::AbstractVector{<:Number}, y::AbstractVector{<:Number}) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L698

Point / vecdot implique d'utiliser le conjugué et de décider quand aller à BLAS. cela doit être géré quelque part. Mais cela devrait être gérable dans un seul espace de noms.

L2 est-il un bon défaut en haute dimensionnalité ? Peut-être pas

L2 est également la norme la plus courante pour les espaces de dimension infinie (par exemple les fonctions). Je pense que c'est une valeur par défaut raisonnable à attendre pour tout espace vectoriel.

De toute évidence, vous souhaitez également disposer d'autres normes. Si nous redéfinissons norm(x) pour qu'il soit élément par élément L2 dans la mesure du possible, alors norm(x, p) serait élément par élément Lₚ, et nous aurions besoin d'une autre fonction (par exemple opnorm ) pour le induit/ correspondant normes de l'opérateur.

Je suis d'accord avec cela, dans le sens où je ne me souviens pas avoir jamais vu la notation x ⋅ y dans le contexte d'espaces vectoriels généraux (par exemple complexes).

J'ai donné plusieurs citations dans un autre fil, IIRC (par exemple, BLAS utilise dot pour un produit scalaire complexe, et vous pouvez trouver des sources pédagogiques même en utilisant le terme pour les produits internes des fonctions). Le terme même de "produit interne" est généralement introduit comme "une généralisation d'un produit scalaire". Je ne pense pas que quiconque sera trop surpris par la notation de dot pour un produit interne euclidien, et il est pratique d'avoir un opérateur infixe.

Nous pourrions garder dot tel quel et introduire inner , bien sûr, mais je pense que cela créerait une dichotomie déroutante — dans les cas les plus courants, les fonctions seraient équivalentes, mais dans des cas impairs (par exemple, des tableaux de matrices), ils seraient différents.

Mais encore une fois, il est peut-être un peu tard pour les changements de rupture, nous devrons donc peut-être recourir à innernorm et inner . Dans tous les cas, quelqu'un aurait besoin de créer un PR dès que possible.

Si une mesure raisonnable de consensus se forme, je pourrai peut-être consacrer une certaine bande passante à l'exploration de la mise en œuvre sur une échelle de temps pertinente (courte), changements de rupture potentiels inclus. J'apprécie la volonté de clarifier la sémantique de ces opérations et de leur donner des noms explicites. Meilleur!

Je vois deux options principales :

• Incassable, ajoute une fonctionnalité : inner(x,y) et innernorm(x) . Remplace vecdot et vecnorm , et récursif pour les tableaux de tableaux.

• Rupture : changez norm(x,p=2) pour qu'il soit toujours élément par élément et récursif, en remplaçant vecnorm , et introduisez une nouvelle fonction opnorm pour l'opérateur/norme induite. Faites dot(x,y) le produit scalaire élément par élément correspondant, en remplaçant vecdot . (Alternative : renommer en inner , mais c'est bien d'avoir un opérateur infixe, et c'est ennuyeux d'avoir à la fois dot et inner .)

Si je concevais des choses à partir de zéro, je préférerais 2, mais cela pourrait être trop perturbateur pour changer silencieusement la signification de norm .

Une option intermédiaire serait de définir inner et innernorm (dépréciant vecdot et vecnorm ), et de déprécier norm(matrix) en opnorm . Puis, en 1.0, réintroduisez norm(matrix) = innernorm(matrix) . De cette façon, les gens peuvent éventuellement utiliser simplement inner et norm , et nous laissons dot comme la bête étrange actuelle pour les vecteurs de tableaux (coïncidant avec inner pour les vecteurs de nombres).

Une bizarrerie à propos innernorm est que vous voulez un moyen de spécifier les normes L1 ou Linf "élément par élément", mais aucune de celles-ci ne correspond à un produit interne, donc innernorm(x,p) est un peu impropre.

J'aime votre option intermédiaire.

Comme indiqué ci-dessus, j'aime le nom innernorm(x) car il implique p=2 et il ne devrait pas y avoir de deuxième argument . J'ai des objets pour lesquels je ne sais que calculer la norme du produit interne. Mais avec l'actuel (vec)norm , il n'est pas clair pour moi si l'argument p fait partie de l'interface de base supposée, et donc je ne sais pas s'il faut omettre le deuxième argument ou prendre en charge mais vérifie explicitement p != 2 et génère une erreur.

Mais je vois le problème de ne pas avoir de moyen non obsolète de faire vecnorm(matrix, p!=2) pendant l'étape intermédiaire de votre proposition.

J'aime aussi l'option intermédiaire - nous voulons vraiment passer par un cycle approprié de dépréciation des normes plutôt que de faire un changement immédiat. (En tant qu'utilisateur, les changements de rupture me font peur, mais je vois que la correction des obsolescences dans mon code pour la v1.0 est comme un investissement dans un code propre et clair pour l'avenir).

Aurions-nous réellement besoin innernorm ou pourrions-nous simplement utiliser vecnorm pour l'instant (et déprécier vecnorm au profit de norm plus tard) ?

En fait, je ne vois aucun tollé potentiel en remplaçant simplement dot par inner ... Je pense aussi qu'il est assez clair que le produit interne est censé être une généralisation des produits scalaires.

Les changements pourraient être mis en œuvre dans deux PR distincts :

1. Remplacez dot par inner et donnez-lui le sens général. Facultativement, faites pointer la notation infixe \cdot vers l'intérieur entre les tableaux Julia.
2. Plus de cycles de discussion et de dépréciation autour des variantes de normes et de la terminologie.

Je crois comprendre que PR 1 pourrait être fusionné avant Julia v1.0. Il ne casse pas.

Remplacer dot par inner serait toujours en panne car dot n'est actuellement pas un véritable produit interne pour les tableaux de tableaux - vous modifieriez donc le sens, pas seulement le renommage. Je suis pour changer le sens d'être un vrai produit intérieur, mais si vous changez le sens (en le définissant comme le vrai produit intérieur), je ne vois pas le problème de continuer à l'épeler comme dot .

Ainsi, nous pourrions faire ce qui suit en 0.7 :

1. Déprécier norm(matrix) à opnorm(matrix) et norm(vector of vectors) à vecnorm .
2. Déprécier dot([vector of arrays], [vector of arrays]) pour un appel à sum .
3. Dites que vecdot(x,y) et vecnorm(x, p=2) sont des produits/normes intérieurs euclidiens (pour p=2 ), et rendez-les récursifs (ce qui est légèrement cassant, mais en pratique probablement pas un gros problème) .

Puis, en 1.0 :

1. Déprécier vecnorm à norm et vecdot à dot . (Vous ne savez pas si cela est autorisé par les règles de la version 1.0, @StefanKarpinski ?)

(Notez que la fonction numpy.inner , étonnamment, n'est pas toujours un produit interne. Mais la terminologie de NumPy sur inner et dot est bizarre depuis un moment.)

Les raisons pour lesquelles je préfère continuer à l'épeler comme dot :

• C'est bien d'avoir une orthographe infixe.
• Pour les non-mathématiciens opérant sur des espaces vectoriels ordinaires de dimension finie, dot est un nom plus familier pour le produit scalaire euclidien. (Les mathématiciens s'adapteront facilement à l'utilisation du nom dot pour la fonction de produit interne sur des espaces de Hilbert arbitraires - "produit scalaire" n'a pas d'autre signification possible pour de tels espaces.)
• Avoir à la fois inner et dot serait déroutant, car ils coïncideraient dans certains cas mais peut-être pas dans d'autres (si nous gardons la signification actuelle dot ).
• En dehors de l'algèbre linéaire, inner a beaucoup d'autres significations potentielles en informatique, et il est donc quelque peu ennuyeux d'exporter ce nom depuis Base.

Pouvez-vous préciser votre opposition au nom intérieur ? je ne comprends toujours pas
c'est pourquoi vous préférez aller à l'encontre d'une terminologie que tout le monde sur ce fil semble
être d'accord?

Le mar. 15 mai 2018, 05:13 Steven G. Johnson [email protected]
a écrit:

(Notez que le numpy.inner
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
la fonction, étonnamment, n'est pas toujours un produit intérieur.)

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
.

Aucune des raisons ne m'impose :

>

• C'est bien d'avoir une variante infixe.

Oui, et la notation infixe peut toujours exister quel que soit le changement de nom
intérieur comme expliqué ci-dessus.

>

• Pour les non-mathématiciens opérant sur la dimension finie ordinaire
  espaces vectoriels, le point est un nom plus familier pour l'intérieur euclidien
  produit. (Les mathématiciens s'adapteront facilement à l'utilisation du point de nom pour
  la fonction de produit interne sur des espaces de Hilbert arbitraires - "produit scalaire" n'a pas
  autre signification possible pour de tels espaces.)

Cet argument n'est pas bon : enseignons aux gens ordinaires le mal
terminologie parce qu'ils sont paresseux et ne peuvent pas apprendre un nouveau mot approprié,
et forcer les mathématiciens à utiliser la mauvaise terminologie contre leur gré.

>

• Avoir à la fois intérieur et point serait déroutant, car ils
  coïncident dans certains cas mais peut-être pas dans d'autres (si nous gardons le point actuel
  signification).

Nous n'avons pas besoin des deux, débarrassez-vous du nom moins général, qui, nous en convenons, est
point à ce stade.

>

• En dehors de l'algèbre linéaire, inner a beaucoup d'autres potentiels
  significations en informatique, et il est donc quelque peu ennuyeux de
  exporter ce nom depuis Base.

En dehors de l'algèbre linéaire, je peux trouver de nombreuses utilisations pour le point. Encore plus pour le
notation infixe par points signifiant des choses complètement différentes.

>

Je reposte le dernier post de @juliohm avec une mise en forme fixe.

Aucune des raisons ne m'impose :

C'est bien d'avoir une variante infixe.

Oui, et la notation infixe peut toujours exister quel que soit le changement de nom en interne comme expliqué ci-dessus.

Pour les non-mathématiciens opérant sur des espaces vectoriels de dimension finie ordinaires, le point est un nom plus familier pour le produit interne euclidien. (Les mathématiciens s'adapteront facilement à l'utilisation du nom point pour la fonction de produit interne sur des espaces de Hilbert arbitraires - "produit scalaire" n'a pas d'autre signification possible pour de tels espaces.)

Cet argument n'est pas bon : enseignons aux gens ordinaires la mauvaise terminologie parce qu'ils sont paresseux et ne peuvent pas apprendre un nouveau mot approprié, et forçons les mathématiciens à utiliser la mauvaise terminologie contre leur gré.

Avoir à la fois intérieur et point serait déroutant, car ils coïncideraient dans certains cas mais peut-être pas dans d'autres (si nous gardons la signification actuelle du point).

Nous n'avons pas besoin des deux, débarrassez-vous du nom moins général, dont nous convenons qu'il s'agit d'un point à ce stade.

En dehors de l'algèbre linéaire, inner a beaucoup d'autres significations potentielles en informatique, et il est donc quelque peu ennuyeux d'exporter ce nom depuis Base.

En dehors de l'algèbre linéaire, je peux trouver de nombreuses utilisations pour le point. Encore plus pour la notation infixe par points signifiant des choses complètement différentes.

Oui, et la notation infixe peut toujours exister quel que soit le changement de nom en interne comme expliqué ci-dessus.

Vous pouvez certainement définir const ⋅ = inner , mais votre terminologie est alors incohérente. Je pensais que vous n'aimiez pas utiliser le "produit scalaire" comme produit interne général ?

forcer les mathématiciens à utiliser la mauvaise terminologie contre leur gré

Les mathématiciens savent que la terminologie n'est ni bonne ni mauvaise, elle est seulement conventionnelle ou non conventionnelle (et peut-être cohérente ou incohérente). (Et la plupart des gens ne se lancent pas dans les mathématiques parce qu'ils ont une passion pour l'orthographe prescriptive.) D'après mon expérience, si vous dites aux mathématiciens qu'en mécanique quantique, un vecteur s'appelle un "état", l'adjoint s'appelle "poignard", et un double vecteur s'appelle un "soutien-gorge", ils sont sublimement insouciants. De même, je ne pense pas qu'un mathématicien expérimenté clignera des yeux plus d'une fois si vous lui dites que dans Julia, un produit intérieur s'écrit dot(x,y) ou x ⋅ y , d'autant plus que les termes sont déjà compris comme étant synonymes dans de nombreux contextes. (Je doute que vous trouviez un mathématicien qui ne sache pas instantanément que vous faites référence à un produit interne si vous dites "prenez le produit scalaire de deux fonctions dans cet espace fonctionnel".)

D'un autre côté, pour les personnes qui ne sont pas des mathématiciens formés et qui n'ont pas été exposées à des espaces abstraits de produits internes (c'est-à-dire la majorité des utilisateurs), mon expérience est que la terminologie inconnue est plus un obstacle. "Comment puis-je prendre un produit scalaire de deux vecteurs dans Julia?" deviendra une FAQ.

Il n'y a vraiment aucune difficulté mathématique ici à résoudre en dehors du choix de la sémantique. La question d'orthographe est purement une question de commodité et d'usage.

En dehors de l'algèbre linéaire, je peux trouver de nombreuses utilisations pour le point. Encore plus pour la notation infixe par points signifiant des choses complètement différentes.

Sauf que Julia et de nombreux autres langages de programmation ont eu dot pendant des années et cela n'a pas été un problème. inner serait une nouvelle casse.

En fin de compte, l'orthographe de cette fonction (ou de toute autre) est une question mineure par rapport à la sémantique et au chemin de dépréciation, mais je pense que l'équilibre penche en faveur de dot .

Vous pouvez certainement définir const ⋅ = inner, mais alors votre terminologie est incohérente. Je pensais que vous n'aimiez pas utiliser le "produit scalaire" comme produit interne général ?

Je pense que tu ne comprends toujours pas. Il n'y a aucune incohérence à appeler point un produit scalaire. C'est un produit intérieur, très spécifique et inutile pour beaucoup d'entre nous. Rien de plus que sum(x.*y) .

Si le terme dot se retrouve dans Julia ayant la sémantique de inner , ce sera un désastre historique dont je peux vous garantir que beaucoup se sentiront agacés. Je peux prévoir des professeurs dans une salle de classe expliquant des choses comme : "Vous savez, nous allons maintenant définir le produit interne de notre espace, mais dans Julia, quelqu'un (@stevengj) a décidé de l'appeler point."

Je m'assurerai de capturer ce fil pour référence future si cela finit par se produire.

Vous êtes le seul @stevengj à insister sur la terminologie dot , personne d'autre ne s'y est opposé. Ce serait bien si vous pouviez reconsidérer ce fait avant de prendre une décision.

C'est un produit intérieur, très spécifique et inutile pour beaucoup d'entre nous. Rien de plus que sum(x.*y).

Si vous pensez que "produit scalaire" ne peut faire référence qu'au produit intérieur euclidien dans ℝⁿ, alors vous ne devriez pas définir const ⋅ = inner , vous ne devriez définir que ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) .

Vous ne pouvez pas jouer dans les deux sens : soit inner peut utiliser ⋅ comme synonyme infixe (auquel cas l'opérateur infixe est à la fois "faux" dans votre langage et la dénomination est incohérente) ou il n'a pas de synonyme infixe (sauf dans un cas particulier).

Je peux prévoir des professeurs dans une salle de classe expliquant des choses comme : "Vous savez, nous allons maintenant définir le produit interne de notre espace, mais dans Julia, quelqu'un (@stevengj) a décidé de l'appeler point."

Ha ha, je suis prêt à prendre la chaleur de ce professeur outragé imaginaire. Sérieusement, vous devez regarder autour de vous si vous pensez que le terme "produit scalaire" n'est jamais utilisé que dans ℝⁿ, ou que les mathématiciens sont scandalisés si le terme est utilisé dans d'autres espaces de Hilbert.

ce sera une catastrophe historique

Sérieusement?

Cette discussion semble s'éroder au-delà de ce que l'on pourrait considérer comme un environnement accueillant, civil et constructif . Les opinions et les antécédents diffèrent, mais veuillez vous abstenir de faire des attaques personnelles ou de blâmer qui que ce soit et supposez que toutes les parties débattent de leur point de vue de bonne foi.

Je peux prévoir des professeurs dans une salle de classe expliquant des choses comme : "Vous savez, nous allons maintenant définir le produit interne de notre espace, mais dans Julia, quelqu'un (@stevengj) a décidé de l'appeler point."

Il peut également être utile de noter ici que Steven _est_ professeur. :clin d'œil:

Je suis également sur le point de supprimer dot en faveur de inner . Le terme dot est assez largement utilisé, et ne pas avoir la fonction dans Julia, alors qu'elle est en Python et MATLAB serait surprenant. Cependant, j'aime aussi le terme inner , étant donné qu'il est plus approprié pour les espaces vectoriels non ℝⁿ, et en particulier les matrices.

Incidemment, pendant que je testais ce que les méthodes faisaient dans Julia, j'ai remarqué que dot ne fonctionne que sur de vrais vecteurs/matrices. Est-ce intentionnel ?

Avoir à la fois intérieur et point serait déroutant, car ils coïncideraient dans certains cas mais peut-être pas dans d'autres (si nous gardons la signification actuelle du point).

@stevengj Serait-il complètement ridicule de remplacer vecdot par inner , et de conserver également dot ? À l'heure actuelle, ce problème exact que vous décrivez existe déjà, juste avec vecdot au lieu de inner .

OK... j'ai hâte, quelles sont les suggestions en direct ? Sont-ils :

• Adoptez dot comme produit interne générique pour un plus large éventail de types. C'est déjà correctement récursif sur les vecteurs de vecteurs, mais nous le ferions fonctionner sur les matrices, etc. ( @jebej Je ne pense pas qu'avoir à la fois dot et inner soit si utile, et comme Steven dit, nous utilisons au moins familièrement dot pour signifier produit interne assez souvent, et ce n'est pas incorrect - c'est juste de la terminologie).
• Envisagez de rendre norm un peu plus cohérent avec les dot ci-dessus et sur tous les AbstractArray , en introduisant éventuellement par exemple opnorm pour les normes d'opérateur (sur AbstractMatrix ) et ayant (en notation nouvelle à ancienne) norm(matrix) == vecnorm(matrix) après les dépréciations appropriées. À ce stade, nous n'avons peut-être plus besoin vecdot et vecnorm ?

Est-ce correct? Je pense que cela nous amènerait au moins à une histoire d'algèbre linéaire relativement cohérente avec des interfaces "propres", où le code générique peut utiliser dot et norm comme une paire fiable pour travailler avec des espaces de produits internes indépendant du genre.

@andyferris , oui, je pense que si nous apportons ce changement, nous n'avons besoin que dot et norm (qui sont maintenant les opérations euclidiennes récursives sur des tableaux ou des tableaux de tableaux de n'importe quelle dimensionnalité, bien que pour la norme, nous définissons également norm(x,p) comme étant la norme p) et opnorm , et n'avons plus vecdot ou vecnorm .

Notez que le passage à dot est un changement de rupture car dot n'est actuellement pas un véritable produit interne pour les vecteurs de matrices (#22392), ce qui a été longtemps débattu dans #22220 ( à quel point l'élimination vecdot n'était pas considérée comme IIRC). Cependant, cela a été introduit dans la version 0.7, donc cela ne casse aucun code réellement publié. En fait, dot en 0.6 est déjà le produit scalaire euclidien sur les tableaux à dimensionnalité arbitraire, un peu par accident (#22374). Le changement suggéré ici restaurerait et étendrait ce comportement 0.6 et changerait norm pour être cohérent avec lui.

Une question est de savoir si norm(x,p) appellerait norm(x[i]) ou norm(x[i],p) récursivement. Les deux sont des comportements potentiellement utiles. Je penche pour le premier parce qu'il est plus général - x[i] peut être un espace vectoriel normé arbitraire qui ne définit que norm mais pas la norme p. Appeler norm manière récursive est également ce que vecnorm fait maintenant, donc c'est cohérent avec la dépréciation vecnorm à norm .

@jebej , dot sur master et 0.6 fonctionne pour moi sur des tableaux complexes : dot([3im],[4im]) renvoie correctement 12+0im , par exemple.

Un autre bon point à propos de changer norm(matrix) pour être la norme Frobenius est que c'est beaucoup moins cher. Il est courant d'utiliser simplement norm(A-B) pour avoir une idée de l'importance de la différence entre deux matrices, mais sans trop se soucier du choix spécifique de la norme, mais de nombreux utilisateurs ne se rendront pas compte que la valeur par défaut actuelle norm(matrix) nous oblige à calculer la SVD.

Merveilleux de voir un consensus se former autour de plusieurs points majeurs ! :) (À moins que quelqu'un ne me devance (veuillez le faire si vous avez de la bande passante !) ou qu'une balise alpha apparaisse auparavant, je donnerai une chance à la mise en œuvre des points de consensus actuels après l'expédition # 26997.) Meilleur !

Un autre lien pour référence future : https://math.stackexchange.com/a/476742

Pour illustrer la mauvaise dénomination qui est adoptée ici consciemment , et la mauvaise décision imposée par un seul esprit. Les produits scalaires et internes ont des propriétés mathématiques différentes. Vous forcez toute une communauté contre ce qui est bien connu dans la littérature mathématique.

Et pour les futurs lecteurs, qu'aurait-il fallu faire à la place si nous avions eu une décision collective :

# make dot what it is, a NOTATION
⋅(x::AbstractVector, y::AbstractVector) = sum(x[i]*y[i] for i in indices(x))

# replace the name dot by the more general inner
inner(x, y) = # anything

Je suppose que nous serons simplement les premières personnes dans l' univers à employer le terme "produit scalaire" pour un produit intérieur sur autre chose que ℝⁿ. C'est une bonne chose que j'ai pu imposer ma volonté à ce fil (principalement en faisant chanter les autres développeurs) pour forcer cette innovation dans le monde ! Le produit scalaire ne sera plus relégué à une simple "notation": il s'agira plutôt d'un symbole qui signifie un produit interne (comme chacun devrait le savoir, attribuer des significations aux symboles est le contraire de la "notation").

Très bonne prise de décision :clap: c'était définitivement un consensus. Lisez les commentaires ci-dessus et vous verrez comment tout le monde était d'accord. :+1:

Ou peut-être devrais-je citer quelques commentaires afin qu'il soit très clair en quoi il s'agissait d'un consensus :

>

Droit - vecdot pourrait être renommé inner

par @andyferris

Option 2 (probablement meilleure) : utilisez des noms plus mathématiquement corrects

intérieur
dimension
Mais que faire de la norme ?

par @Jutho

Je suis d'accord, comme alternative à vecdot, nous pourrions introduire une nouvelle méthode interne

par @Jutho

Je trouve aussi le nom de vecdot étrange, en fait, je ne savais même pas qu'il existait et j'avais créé ma propre fonction pour cela... appelée inner.

par @jebej

Et beaucoup plus...

Les gens peuvent débattre avec véhémence les uns avec les autres et soulever de nombreux points de désaccord, mais arrivent toujours à un consensus (mais pas toujours à l'unanimité) en étant persuadés et en équilibrant le pour/le contre. (Je suis d'accord qu'il y a des avantages et des inconvénients de chaque option ici.) Je suis désolé que le résultat qui semble (provisoirement !) Se gélifier ici ne soit pas le résultat que vous avez préféré, mais je ne sais pas comment vous pensez J'ai « imposé » ma volonté.

(Pas qu'une décision finale ait été prise, bien sûr - il n'y a même pas encore de relations publiques, et encore moins quelque chose de fusionné.)

Je souhaite seulement que nous puissions prendre une décision basée sur le public de la langue. Si quelqu'un choisit Julia comme outil, je suis sûr que la personne a au moins entendu parler du terme produit inner . C'est un concept assez populaire et loin d'être exotique. Les choses exotiques incluent "l'homologie persistante", la "théorie quantique", qui sont moins répandues, et je serais contre l'inclusion de ce type de terminologie.

Après tout, je veux juste avoir un langage qui soit le meilleur langage pour le calcul scientifique, les mathématiques, etc.

@juliohm , tous les arguments ont été basés sur les besoins de qui nous pensons que le public est, et nous essayons tous de faire de Julia une langue aussi bonne que possible. Les personnes raisonnables peuvent arriver à des conclusions différentes sur la terminologie, puisque les mathématiques ne déterminent pas l'orthographe.

Premièrement, comme mentionné ci-dessus, je peux certainement être d'accord avec la proposition actuelle de @stevengj et m'en tenir à dot comme nom général pour le produit interne. De plus, je n'aime pas la façon dont cette discussion se déroule et j'aimerais certainement être cité correctement. @juliohm , la deuxième citation que vous m'attribuez n'est pas la mienne.

Cela étant dit, je voudrais mentionner ce qui suit comme matière à réflexion dans l'examen des avantages et des inconvénients. Les éléments suivants sont principalement des inconvénients, mais je suis d'accord avec les avantages mentionnés par @stevengj. Il pourrait facilement y avoir des cas d'utilisation distincts pour avoir dot signifie simplement sum(x[i]*y[i] for i ...) . Dans les cas où la notation infixe par points est la plus utilisée en mathématiques, c'est en effet typiquement le sens. En tant que produit interne, la notation infixe par points est généralement (mais certainement pas exclusivement) réservée aux espaces vectoriels réels. D'autres cas d'utilisation incluent l'activation de choses comme σ ⋅ n avec σ un vecteur de matrices de Pauli et n un vecteur de scalaires. C'était l'une des motivations derrière la façon dont dot est actuellement implémenté, comme cela m'a été signalé dans un autre fil. Le fait que BLAS ait décidé de n'utiliser que dot pour les vecteurs réels et de faire une distinction entre dotu et dotc pour les vecteurs complexes est un autre problème à considérer. Les personnes ayant des antécédents BLAS peuvent se demander si, ayant des vecteurs complexes, elles veulent calculer dot(conj(u),v) ou dot(u,v) alors qu'elles veulent le vrai produit interne (c'est-à-dire dotc ). De plus, ils pourraient chercher un moyen de faire dotu sans d'abord faire une copie conjuguée du vecteur en question.

@Jutho la citation est la vôtre, votre commentaire complet est copié ci-dessous :

Je suis d'accord, comme alternative à vecdot, nous pourrions introduire une nouvelle méthode inner, mais je ne connais pas de bon nom pour "remplacer" vecnorm. En fait, je ne trouve pas vecnorm si mauvais, la norme vectorielle est un terme bien établi et explicite pour l'opération que nous voulons.

En tout cas, la citation est destinée à montrer quel est le désir de beaucoup ici (au moins comme une première pensée naturelle) quand on réfléchit à ce sujet. Si vous avez changé votre désir au fil du temps, c'est une autre histoire. Moi-même, je ne sortirais jamais le terme "point" de ma tête lors d'une modélisation avec des espaces de Hilbert. Cela semble anormal et incompatible avec ce que j'ai appris.

@Jutho : De plus, ils pourraient chercher un moyen de faire dotu sans d'abord faire une copie conjuguée du vecteur à portée de main.

La possibilité d'exporter une fonction dotu est apparue de temps en temps (voir par exemple #8300). Je suis d'accord que c'est parfois une fonction utile: un "produit interne" euclidien non conjugué (qui n'est plus vraiment un produit interne) qui est une forme symétrique bilinéaire (non sesquilinéaire) dotu(x,y) == dotu(y,x) (non conjuguée) même pour des espaces vectoriels complexes . Mais l'utilité de cette opération ne se limite pas à ℂⁿ - par exemple, ce type de produit apparaît souvent dans des espaces vectoriels de dimension infinie (fonctions) pour les équations de Maxwell en raison de la réciprocité (essentiellement: l'opérateur de Maxwell dans les matériaux typiques avec perte est analogue à une «matrice à symétrie complexe» - symétrique sous le «produit interne» non conjugué). Donc, si nous définissons dot(x,y) comme étant le produit intérieur euclidien général (avec le premier argument conjugué), il serait tout à fait naturel de définir une fonction dotu(x,y) pour le produit euclidien non conjugué sur n'importe quel espace vectoriel où cela a du sens. Cependant, je ne vois pas la possibilité d'une fonction dotu comme argument contre dot . Dans la majorité des cas, lorsque vous travaillez avec des espaces vectoriels complexes, vous voulez le produit conjugué, c'est donc le bon comportement par défaut.

Mais je suis d'accord qu'une possibilité serait de définir dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) , qui est la façon dont il est actuellement défini dans master (pas 0.6), et de définir inner(x,y) comme le vrai produit scalaire. Ceci a l'avantage de fournir les deux fonctions, qui peuvent toutes deux être utiles dans certains cas. Cependant, nous avons alors deux fonctions qui coïncident presque toujours à l'exception des tableaux de matrices, et je soupçonne qu'il serait un peu déroutant de décider quand utiliser l'une ou l'autre. Beaucoup de gens écriraient dot quand ils voulaient dire inner , et cela fonctionnerait bien pour eux dans la plupart des cas, mais leur code ferait alors quelque chose d'inattendu s'il passait un tableau de matrices. Je soupçonne que dans 99 % des cas, les gens veulent le véritable produit interne, et la version "somme du produit" peut être laissée à un package, si en effet elle est nécessaire (par opposition à simplement appeler sum ).

@juliohm , j'ai mal lu votre message car je pensais que les noms étaient au-dessus (au lieu d'en dessous) des citations respectives, donc je pensais que vous m'attribuiez la citation de @jebej . Mes excuses pour cela.

@stevengj , je ne pensais certainement pas avoir dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) comme valeur par défaut raisonnable. Dans le cas comme σ ⋅ n , la conjugaison complexe/hermitienne du premier ou du deuxième argument n'est pas nécessaire. Donc, ce que je disais, c'est que, dans de nombreux cas (mais pas tous) où la notation infixe par points est utilisée dans les formules scientifiques, sa signification coïncide avec dotu , c'est-à-dire sum(x[i]*y[i] for i = 1:length(x)) sans conjugaison, soit comme produit interne sur des espaces vectoriels réels ou comme une construction plus générale.

Donc si je devais faire une proposition alternative (bien que je ne la préconise pas forcément), c'est d'avoir deux fonctions :

• dot(x,y) = sum(x[i]*y[i] for i...) , qui est toujours le produit interne correct pour les vecteurs réels (ce qui est probablement le cas d'utilisation des personnes qui connaissent moins ou ne connaissent pas le terme produit interne) mais permet également des constructions plus générales comme σ ⋅ n , et est donc la fonction correspondant à la notation infixe

• inner(x,y) étant le produit interne toujours valide, avec conjugaison et récursivité, qui sera utilisé par des personnes dans des contextes plus généraux et techniques.

Je ne défends pas cela comme un bon choix à adopter dans la langue Julia, mais je pense que c'est ainsi qu'il est utilisé dans une grande partie de la littérature. Lorsque le point infixe est utilisé, c'est soit comme un produit interne dans le contexte de vecteurs réels, soit dans une construction plus générale où cela signifie simplement une contraction. Lorsqu'un produit interne général sur des espaces vectoriels arbitraires est prévu, la plupart de la littérature scientifique (mais vous avez certainement montré des contre-exemples) passe à <u,v> ou <u|v> (où dans la première notation il y a encore une discussion qui des deux arguments est conjugué).

Je pourrais vivre avec cette proposition, mais je pourrais tout aussi bien vivre avec seulement dot comme produit interne général. Au final, il s'agit d'avoir une bonne documentation, et moi non plus je n'arrive pas à croire que quelqu'un trébucherait sur ce choix "design".

@Jutho , je suis d'accord qu'il n'est pas rare de définir dot pour signifier simplement contraction. Certes, on peut trouver des exemples dans les deux sens. Par exemple, dans les langages de programmation et les bibliothèques populaires :

• Non conjugué : Numpy dot (et, bizarrement, inner ), Mathematica's Dot , Maxima . , BLAS dotu

• Conjugué : Matlab's dot , Fortran's DOT_PRODUCT , Maple's DotProduct , Petsc's VecDot , Numpy vdot , BLAS dotc (notez que le manque de la surcharge dans Fortran 77 rendait impossible d'appeler ce dot même s'ils le voulaient), le point d'Eigen

D'une part, le produit interne conjugué est généralement introduit dans les manuels comme l' extension "naturelle" de la notion de "produit scalaire" aux vecteurs complexes - la version non conjuguée est en quelque sorte une extension "non naturelle", en ce sens qu'elle n'est généralement pas ce que tu veux. (Considérez le fait que, parmi les langages qui fournissent une fonction conjuguée dot dans leurs bibliothèques standard - Matlab, Fortran, Julia, Maple - seul Maple fournit une variante non conjuguée, ce qui indique un manque de demande.) d'autre part, une fonction dotu non conjuguée est pratique (en complément) dans certains cas particuliers (dont certains que j'ai mentionnés ci-dessus).

Si nous avons à la fois dot et inner , je soupçonne que beaucoup de gens finiront par utiliser dot par accident alors qu'ils veulent vraiment inner pour que leur code soit générique. (Je parierais que inner de Numpy n'est pas conjugué à cause d'un tel accident - ils l'ont implémenté avec de vrais tableaux à l'esprit, et n'ont pas pensé au cas complexe jusqu'à ce qu'il soit trop tard pour changer alors ils ont ajouté le maladroitement nommé vdot .) Alors que si nous avons dot et (éventuellement) dotu , il sera plus clair que dot est le choix par défaut et dotu est la variante spéciale.

(Je suis d'accord que ⟨u,v⟩ , ⟨u|v⟩ ou (u,v) sont des notations plus courantes pour les produits internes sur des espaces de Hilbert arbitraires - ce sont ce que j'utilise généralement moi-même - mais ces notations sont un non démarreur pour Julia. Il y a eu des discussions sur l'analyse des parenthèses Unicode en tant qu'appels de fonction/macro, par exemple # 8934 et # 8892, mais cela n'est jamais allé nulle part et cela semble peu susceptible de changer bientôt.)

Je suis entièrement d'accord avec votre évaluation @stevengj .

Moi aussi.

Je soupçonne qu'il est temps pour l'un de nous de jouer avec l'une ou l'autre des implémentations dans un PR et de voir comment cela se passe.

@Jutho J'ai toujours vu le produit scalaire avec les matrices de Pauli comme un raccourci pour une contraction sur des tenseurs d'ordre supérieur ... l'un des espaces vectoriels est réel, 3D.

Je suis d'accord que ⟨u,v⟩, ⟨u|v⟩ ou (u,v) sont des notations plus courantes pour les produits internes sur des espaces de Hilbert arbitraires - ce sont ce que j'utilise généralement moi-même - mais ces notations sont un non-démarrage pour Julia.

Il serait en fait possible de faire fonctionner ⟨u,v⟩ .

@StefanKarpinski : Il serait en fait possible de faire fonctionner ⟨u,v⟩.

Absolument, et soutenir cette notation précise a été suggérée dans #8934, mais elle n'est jamais allée nulle part. (Notez également que les crochets angulaires ont d'autres utilisations courantes, par exemple ⟨u⟩ désigne souvent une moyenne quelconque.) Il est incassable et pourrait encore être ajouté à un moment donné, mais il ne semble pas raisonnable de s'attendre dans un proche terme. Il est également assez lent de taper \langle<tab> x, y \rangle<tab> , donc ce n'est pas très pratique du point de vue de la programmation pour une opération élémentaire.

et nous ne pouvons pas surcharger <> pour cela, n'est-ce pas ?

Non

Je ne peux pas dire que j'ai lu tous les commentaires sur ce fil énorme, mais je veux juste souligner quelques points, dont certains ont déjà été faits :

• La distinction entre le point et l'intérieur semble trop pédante. En effet à mes oreilles cela semble un non sens car en français il n'y a qu'un seul terme - "produit scalaire" - et il est difficile de faire la différence entre des choses qui pour moi portent le même nom ;-)
• Lorsque vous venez de numpy et que vous travaillez avec des tableaux complexes, avoir dot conjugué par défaut est la meilleure chose qui soit. Pas de point de décision ici, je voulais juste dire à quel point je suis heureux de ne plus avoir à faire ces conj(dot()) s !
• Avoir deux fonctions qui ont le même comportement dans la plupart des cas mais qui diffèrent parfois est une mauvaise conception, et a et causera de la confusion, avec du code qui devrait appeler l'une appelant en fait l'autre, simplement parce que l'utilisateur ne sait pas mieux. C'est particulièrement ennuyeux avec norm : si vous codez un algorithme d'optimisation et que vous voulez vous arrêter à chaque fois que norm(delta x) < eps , vous allez écrire norm . Mais ensuite, vous voulez optimiser une image ou quelque chose, vous exécutez votre code, et il se lance soudainement dans un SVD impossible à tuer (parce que BLAS) d'un grand tableau. Ce n'est pas académique, cela a causé des problèmes dans Optim.jl, et sans doute dans d'autres packages également. Personne ne saura que vecnorm existe à moins d'avoir une raison précise de le rechercher.
• Sur la base du point précédent, toute solution qui fusionne dot et vecdot , et norm et vecnorm est bonne, même si elle enlève un peu de flexibilité dans cas de tableaux de tableaux. Pour les normes, j'ajouterais que souvent lorsque vous travaillez avec des éléments sur lesquels plusieurs normes sont définies (par exemple, des matrices), ce que l'utilisateur veut, c'est appeler norm pour obtenir une norme, sans se soucier particulièrement de laquelle. Les normes induites sont le plus souvent d'intérêt théorique plutôt que pratique en raison de leur caractère intraitable par les calculs. Ils sont également spécifiques à l'interprétation du tableau 2D en tant qu'opérateur plutôt qu'à celle du tableau 2D en tant que stockage (une image est un tableau 2D, mais ce n'est pas un opérateur dans un sens utile). C'est bien d'avoir la possibilité de les calculer, mais ils ne méritent pas d'être les norm par défaut. Des valeurs par défaut raisonnables, simples et bien documentées qui ont des alternatives détectables valent mieux qu'une tentative d'intelligence (si l'utilisateur veut faire une chose intelligente, laissez-le le faire explicitement).

Par conséquent, +1 sur @stevengj 's

oui, je pense que si nous apportons ce changement, nous n'avons besoin que de point et de norme (qui sont maintenant les opérations euclidiennes récursives sur des tableaux ou des tableaux de tableaux de n'importe quelle dimensionnalité, bien que pour la norme nous définissions également la norme (x, p) comme étant la p-norm) et opnorm, et n'ont plus vecdot ou vecnorm.

Une alternative plus "julienne" à norm/opnorm pourrait être d'avoir un type Operator, qui pourrait envelopper un tableau 2D, sur lequel norm fait opnorm. Cela peut se faire au niveau des packages (dont plusieurs existent déjà)

Je préfère de loin taper opnorm(matrix) plutôt que norm(Operator(matrix)) …

Je vais intervenir de la galerie des cacahuètes ici et dire que j'aime où cela se passe vecnorm et vecdot m'ont toujours dérangé. Devoir demander explicitement la norme de l'opérateur - qui m'a toujours semblé assez spécialisé - semble beaucoup plus sain que de devoir demander une norme beaucoup plus rapide et plus facile à calculer (par exemple la norme de Frobenius). Écrire opnorm semble être une bonne interface pour demander la norme d'opérateur relativement spécialisée.

Je pense également qu'avoir une distinction subtile entre dot et inner est susceptible de conduire à la confusion et à une utilisation abusive généralisée. Faire la leçon aux utilisateurs sur la fonction qu'ils sont _supposés_ utiliser lorsque les deux fonctions font ce qu'ils veulent et que l'une d'elles est plus facile a tendance à ne pas très bien fonctionner. Mon impression est qu'il est relativement rare dans le code générique que sum(x*y for (x,y) in zip(u,v)) soit en fait ce que vous voulez quand un vrai produit interne ⟨u,v⟩ existe réellement. Quand c'est vraiment ce qu'on veut, c'est assez facile, clair et efficace (parce que Julia est ce que c'est) d'écrire quelque chose comme ça pour le calculer.

Que ce soit pour appeler la fonction u⋅v dot ou inner semble être la partie la moins conséquente de tout cela. Je suis à peu près sûr qu'aucun de ces choix ne serait considéré comme un désastre par les historiens - bien que l'idée que les historiens s'en soucient est certainement flatteuse. D'une part, si nous acceptons de conserver la signification du "véritable produit interne" de u⋅v alors oui, inner est le terme mathématique le plus correct. D'autre part, lorsqu'il existe une syntaxe avec un nom de fonction correspondant, cela a tendance à moins confondre les utilisateurs lorsque le nom correspond à la syntaxe. Étant donné que la syntaxe ici utilise un point, cette règle empirique prend en charge l'orthographe de cette opération sous la forme dot . Peut-être que cela pourrait être un cas raisonnable pour définir const dot = inner et exporter les deux ? Ensuite, les gens peuvent utiliser ou étendre le nom qu'ils préfèrent puisqu'il s'agit de la même chose. Si quelqu'un veut utiliser l'un ou l'autre nom pour quelque chose d'autre, il le peut, et l'autre nom restera disponible avec sa signification par défaut. Bien sûr, cela ferait trois noms exportés pour la même fonction — dot , inner et ⋅ — ce qui semble un peu excessif.

Est-il possible de supprimer le symbole ⋅ ou de le remplacer par <u,v> ?

Commentaires:

• Cela rend l'intention claire. Comparez ces deux exemples :

<u,v> * M * x

vs.

u ⋅ v * M * x

• La syntaxe <u,v> implique une association : nous opérons d'abord sur u et v , puis le reste de l'expression suit.

• Si un utilisateur a fait l'effort de taper <u,v> , il est très peu probable qu'il ait en tête un simple sum(x[i]*y[i]) . Le symbole ⋅ est facile à ignorer avec les yeux et a de nombreuses autres connotations. En particulier, en algèbre linéaire, pour un espace vectoriel V sur un champ F, le produit d'un scalaire α ∈ F avec un vecteur v ∈ V est noté α ⋅ v dans divers manuels.

• La suppression ou le remplacement de ⋅ éliminerait également le problème de l'exportation de plusieurs noms. Il faudrait seulement exporter inner et <,> pour les produits internes généraux, avec l'implémentation par défaut pour les tableaux correspondant à la sémantique de sommation itérable.

• Si l'on a besoin de définir un produit scalaire par vecteur comme décrit ci-dessus pour un espace vectoriel V sur un champ F, il/elle pourrait définir la notation ⋅ pour cela. L'espace vectoriel serait alors entièrement défini avec une belle syntaxe courte et pourrait être étendu à un espace de Hilbert en définissant davantage <u,v> .

Nous ne pouvons définitivement pas utiliser la syntaxe <u,v> ; la syntaxe que nous pourrions utiliser est ⟨u,v⟩ — notez les crochets Unicode, pas les signes inférieur à et supérieur à, < et > . Nous avons également u'v comme syntaxe pour quelque chose qui est soit un produit scalaire, soit un produit interne ? (je ne sais pas lequel...)

Oui, désolé, la version unicode de celui-ci. Ce serait très clair à lire. Cela résoudrait également ce problème avec plusieurs noms et libérerait ⋅ à d'autres fins.

Je ne pense pas que nous voulions utiliser ⋅ à d'autres fins, ce serait déroutant.

Imaginez à quel point ce serait merveilleux de pouvoir écrire du code qui ressemble à :

⟨α ⋅ u, v⟩ + ⟨β ⋅ w, z⟩

pour les vecteurs abstraits (ou types) u,v,w,z ∈ V et les scalaires α, β ∈ F .

u'v est un produit interne (et un produit scalaire, si vous suivez la convention conjuguée) uniquement pour les tableaux 1d, pas pour les matrices, par exemple. (C'est une autre raison pour laquelle il est inutile de limiter le point infixe aux tableaux 1d, puisque nous avons déjà une notation laconique pour ce cas.)

Stefan, "terme mathématique correct" est une erreur de catégorie - l'exactitude mathématique n'est pas un concept qui s'applique à la terminologie/notation. (Remplacez "conventionnel" par "correct". Mais alors le souci devient moins urgent,)

Plus de cas d'utilisation : https://stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

Et une dérivation formelle des produits internes booléens en utilisant la notation ⟨,⟩ : https://arxiv.org/abs/0902.1290

EDIT : lien fixe vers le papier

Que pensez-vous de la proposition de syntaxe des chevrons ? Résoudrait-il les problèmes soulevés ici ?

Alors quelle est votre proposition exactement ? C'est à peu près ça :

1. Déprécier dot à inner
2. Déprécier u⋅v à ⟨u,v⟩

Alors il n'y aurait pas de fonction dot ni d'opérateur ⋅ ?

Ce changement serait-il quelque chose de raisonnable?

Désolé pour le délai de réponse, je suis à une conférence avec un accès limité à internet.

Et juste pour plus de clarté et d'exhaustivité, quelle est la contre-proposition ici ? Ne fais rien?

Pour clarifier encore plus la proposition, un changement sémantique est impliqué : les produits internes généralisés.

Attention : nous en avons maintenant débattu au point où il y a un risque réel qu'il n'atteigne pas 0,7-alpha. Cela ne signifie pas qu'il ne peut pas être changé après l'alpha, mais il y aura beaucoup plus de réticence à changer les choses après cela.

Oui, j'aurais aimé avoir les compétences nécessaires pour soumettre un PR il y a longtemps. C'est au-delà de mes capacités d'y arriver, même si je trouve que c'est une caractéristique extrêmement importante.

Même en écartant la question de la syntaxe de l'opérateur, il y a toujours une certaine complexité avec l'occultation des noms et les dépréciations en plusieurs étapes pour chaque ensemble de concepts sémantiques (actuels dot et vecdot et actuels norm et vecnorm ).

Pour le côté dot , il semble que tout l'espace d'options (encore une fois les opérateurs à prix réduit) soit :

I. Cassez silencieusement dot sur les vecteurs de tableaux en changeant le comportement dans 0.7 en un produit interne sans depwarn standard (bien que vous puissiez avertir que le comportement est modifié). Déprécier vecdot à dot en 0.7 également.
II. En 0.7, déprécier vecdot sur toutes les entrées à inner .
III. En 0.7, déconseillez dot sur les vecteurs de tableaux à sa définition, et dot sur les autres entrées et vecdot sur toutes les entrées à inner .
IV. Dans la version 0.7, déconseillez dot et vecdot sur les vecteurs de tableaux vers les fonctions non exportées ou vers leurs définitions, et vecdot sur toutes les autres entrées vers dot . Dans la version 1.0, ajoutez dot sur les vecteurs de tableaux avec une sémantique de produit interne.

Pour le côté de la norme, il y a un certain consensus autour d'un seul chemin (en 0.7, déprécier norm sur les matrices à opnorm et éventuellement déprécier vecnorm à innernorm ; en 1.0 , ajoutez norm sur les matrices avec la sémantique vecnorm actuelle), mais cela entraîne également un nom supplémentaire dans la version 1.0 (soit vecnorm soit innernorm ); encore une fois, un moyen d'éviter cela pourrait être de rendre obsolète vecnorm en 0.7 à sa définition ou à une fonction non exportée comme Base.vecnorm plutôt qu'à un nom exporté.

...Je pense. J'espère que je n'ai pas rendu les choses plus musclées qu'elles ne l'étaient déjà.

Quelqu'un qui connaît la base de code peut-il soumettre un PR pour le changement ?

Pouvons-nous séparer les éléments de norme sur lesquels tout le monde semble être d'accord et faire au moins cela ? Le bit dot contre inner est un peu plus controversé, mais ne laissons pas cela contrecarrer la partie qui ne l'est pas.

@StefanKarpinski , notez qu'ils sont quelque peu couplés : pour les types où vous avez à la fois un produit scalaire (intérieur) et une norme, ils doivent être cohérents.

Ok, je ne me soucie pas vraiment de la façon dont cela se passe. Celui qui fait le travail décide.

J'avais un PR ( #25093 ) pour que vecdot se comporte comme un vrai produit intérieur (et vecnorm comme la norme correspondante), en les rendant récursifs. Cela pourrait être utile comme point de départ pour savoir à quoi devraient ressembler les futurs dot et norm . Malheureusement, mon manque de compétences en git m'a fait bousiller ce PR, alors je l'ai fermé, prévoyant d'y revenir une fois la nouvelle syntaxe d'itération terminée.

Cependant, le fait d'être devenu père pour la deuxième fois il y a quelques jours signifie qu'il n'y a actuellement aucun créneau "temps libre" dans mon calendrier.

vient de devenir papa pour la deuxième fois il y a quelques jours

Félicitations Jutho ! 🎉

Oui, félicitations !

Il semble qu'il pourrait y avoir un consensus autour de l'idée d'avoir à la fois dot et inner , où :

1. inner est un vrai produit interne récursif
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) conjugué ou non, et se chevaucherait donc avec dot pour Vector{<:Number} ou Vector{<:Real}

Concernant:

Beaucoup de gens écriraient point quand ils voulaient dire intérieur, et cela fonctionnerait bien pour eux dans la plupart des cas, mais leur code ferait alors quelque chose d'inattendu s'il passait un tableau de matrices.

Je ne crois pas que ce serait un problème. Comme il s'agit d'une opération assez rare, je m'attendrais à ce que les gens l'essaient au moins pour voir ce qu'elle fait et/ou qu'ils consultent la documentation.

Je pense que ce qui précède serait un grand changement, et pas très perturbateur puisque la sémantique de dot n'est pas modifiée dans la plupart des cas.

Il semble qu'il pourrait y avoir un consensus autour de l'idée d'avoir à la fois dot et inner

Au contraire, la discussion de https://github.com/JuliaLang/julia/issues/25565#issuecomment -390069503 semble privilégier l'un ou l'autre mais pas les deux, comme par exemple indiqué dans https://github. com/JuliaLang/julia/issues/25565#issuecomment -390388230 et bien soutenu avec des réactions.

Peut-être que inner (et aussi dot ) devraient être des produits internes/dot/scalaires récursifs et l'ancien comportement pourrait être implémenté dans des fonctions telles que dotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x)) et dotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x)) ? Les noms dotu et dotc correspondraient aux noms BLAS correspondants.

(Je suis d'accord que ⟨u,v⟩, ⟨u|v⟩ ou (u,v) sont des notations plus courantes pour les produits internes sur des espaces de Hilbert arbitraires - ce sont ce que j'utilise généralement moi-même - mais ces notations sont un non-démarrage pour Julia Il y a eu quelques discussions sur l'analyse des parenthèses Unicode en tant qu'appels de fonction/macro, par exemple #8934 et #8892, mais cela n'est jamais allé nulle part et cela semble peu susceptible de changer bientôt.)

@stevengj , lorsque vous avez ajouté vous-même ce paragraphe à un commentaire précédent, vous vouliez dire que la syntaxe ⟨u,v⟩ est difficile à implémenter dans le langage ?

Y a-t-il une chance que cette fonctionnalité soit disponible dans Julia v1.0 ? J'ai tellement d'idées et de packages qui dépendent de la notion de produits intérieurs généraux. Veuillez me faire savoir si je dois réduire mes attentes. Désolé pour le rappel constant.

Vous n'avez pas vu #27401 ?

Merci @jebej et merci @ranocha d'avoir pris les devants :coeur:

lorsque vous avez ajouté vous-même ce paragraphe à un commentaire précédent, vous vouliez dire que la syntaxe ⟨u,v⟩ est difficile à implémenter dans le langage ?

Pas techniquement difficile à ajouter à l'analyseur, mais il s'est avéré difficile de parvenir à un consensus sur la manière (et si) de représenter les parenthèses personnalisées dans le langage. Voir la discussion au # 8934, qui n'est allée nulle part il y a 4 ans et n'a pas été relancée depuis. (Ajoutez cela au fait que dans différents domaines, les gens utilisent les mêmes crochets pour de nombreuses choses différentes, par exemple ⟨u⟩ est utilisé pour les moyennes d'ensemble en physique statistique.) Un autre problème, soulevé dans # 8892, est la similitude visuelle de nombreux Unicode différents supports.

Merci @stevengj , j'apprécie les clarifications. Je suis déjà très enthousiaste à l'idée que nous allons standardiser les produits intérieurs généraux sur tous les packages. :100: Peut-être que la notation entre crochets pourrait briller dans un autre cycle de publication à l'avenir. Pas aussi important, mais assez pratique pour pouvoir écrire du code qui ressemble littéralement aux mathématiques de nos publications.

Si ⟨args...⟩ est une syntaxe valide pour appeler l'opérateur anglebrackets ou quelque chose (comment appeler la fonction que cette syntaxe appelle est en fait assez délicat puisque nous n'avons aucun précédent), alors les gens pourraient optez pour la signification qu'ils veulent pour la syntaxe.

@StefanKarpinski , l'argument dans # 8934 était qu'il devrait s'agir d'une macro. Je ne pense pas que nous soyons parvenus à un consensus.

(Si nous décidons dans Base que anglebrackets(a,b) signifie inner(a,b) , cela découragera les gens de "choisir le sens qu'ils veulent" car la décision aura déjà été prise.
Ce n'est pas un choix terrible, bien sûr, mais il peut être inutile de lui attribuer une signification dans Base tant qu'ils sont analysés.)

Je ne me souviens pas des détails de cette discussion, mais faire une macro me semble évidemment une mauvaise idée.

Avec # 27401, je pense que nous pouvons considérer que les produits intérieurs ont été pris au sérieux.

Traditionnellement, un problème n'est clos que lorsque le PR concerné est fusionné...

Bien sûr, nous pouvons le laisser ouvert, je suppose. Je voulais juste le retirer de l'étiquette de triage.

Cela devrait-il être fermé puisque #27401 est fusionné maintenant ?