Julia: Zustand der inneren Produkte in Base

Könnten Sie Ihren Anwendungsfall ein wenig näher erläutern und warum es vorteilhaft ist, ihn in Base zu haben, anstatt ihn nur in Ihrem Paket zu definieren? Am besten wäre ein konkretes Beispiel. Erwarten Sie mehrere gleichzeitig geladene inner -Definitionen über Pakete hinweg?

Ich denke, eine formale Schnittstelle für diese mathematischen Räume wird den Benutzern helfen, das Typensystem besser auszunutzen. Zum Beispiel würde ich erwarten, dass Clustering-Methoden in jedem metrischen Raum funktionieren. Wenn ich meinen Typ mit einem inneren Produkt definieren könnte, würde ich von Clustering.jl out of the box profitieren (nachdem das Paket entsprechend fixiert wurde). Viele andere entfernungsbasierte oder projektionsbasierte Algorithmen könnten ebenfalls verallgemeinert werden.

Als konkretes Beispiel bin ich heute auf diese Einschränkung gestoßen, als ich versuchte, eine Geometrie für Kompositionsdaten zu definieren: https://github.com/juliohm/CoDa.jl Ich würde mich lieber auf eine bekannte inner -Funktion spezialisieren in Base definiert, als meine eigene Schnittstelle zu definieren, die sonst niemandem bekannt ist.

Warum erweitern Sie nicht dot für Ihre Hilbert-Raumtypen? Ich bin mir ziemlich sicher, dass es darauf ausgelegt ist, das generische Innenprodukt zu sein.

Das Konzept des Punktprodukts ist strenger als das Konzept des inneren Produkts. Während letzteres für allgemeine Räume definiert ist, ist ein Skalarprodukt nur definiert, wenn es den Begriff eines Koordinatensystems gibt, das durch eine endliche Basis definiert ist. Die Semantik von dot(x,y) ist x'*y , wobei x und y die Koordinaten der Objekte in einer kartesischen Welt darstellen. In mathematischen Lehrbüchern wird der Begriff Punktprodukt selten erwähnt, da die Autoren normalerweise daran interessiert sind, das Material in allgemeineren (nicht unbedingt endlichen oder euklidischen) Räumen zu behandeln.

Zur weiteren Unterscheidung können Objekte in einem Hilbert-Raum mit innerem Produkt <x,y> (oder inner(x,y) ) unendlich sein und die Semantik x'*y trifft nicht zu. Beispielsweise sind die Objekte in der funktionalen Datenanalyse die Funktionen f und g und das Skalarprodukt wird normalerweise durch numerische Integration erhalten: inner(f,g) = quadrature(f*g) . Diese Operation als Skalarprodukt zu bezeichnen, ist irreführend.

Ein weiteres Beispiel, auf das ich in meinem CoDa.jl -Paket hingewiesen habe, sind Kompositionsdaten. Kompositionsobjekte liegen in einer Simplex-Welt, für die die Operation x'*y keinen Sinn macht. Es gibt jedoch eine isometrische Transformation (die Log-Verhältnis-Transformation), die man verwenden kann, um Kompositionen in eine andere Geometrie abzubilden, wo man dann das Skalarprodukt mit Koordinaten anwenden kann. Das Arbeiten mit Koordinaten ist nicht notwendig, aber in diesem Bereich gängige Praxis. Das Ergebnis kann in den ursprünglichen Raum zurücktransformiert werden, in dem die Objekte existieren.

Ich sehe keinen Vorteil darin, den Begriff dot in der Sprache beizubehalten, aber wenn man nach Abwärtskompatibilität fragt, funktioniert die Verallgemeinerung inner(x::AbstractVector, y::AbstractVector) = dot(x,y) einwandfrei.

Können Sie die Einwände gegen diese Änderung erläutern?

Können Sie die Einwände gegen diese Änderung erläutern?

Wir verlangen im Allgemeinen eine angemessene Begründung für das Hinzufügen neuer öffentlicher Funktionen zu Base, das ist der Einwand. Dies könnte durch ein InnerProducts -Paket bereitgestellt werden. Warum muss es in die Sprache selbst eingebaut werden? Dies war die erste Frage, die @andreasnoack oben gestellt hat – sie erhielt eine etwas vage Antwort: „Ich denke, eine formale Schnittstelle für diese mathematischen Räume zu haben, wird Benutzern helfen, das Typsystem besser auszunutzen“. Es gibt keinen Grund dafür, dass eine in einem Paket definierte Schnittstelle weniger formal ist als eine in Base. Was bietet Base.inner , was InnerProducts.inner nicht bietet? Dies ist eine echte Frage, die eine überzeugende Antwort haben könnte, aber ich weiß nicht, wie diese Antwort lauten könnte, weshalb die Frage gestellt wird.

Ich sehe kein gutes Argument, um ein grundlegendes mathematisches Konzept wie innere Produkte an anderer Stelle zu definieren, das nicht in Base enthalten ist. Eine Sprache, deren Hauptpublikum Leute des wissenschaftlichen Rechnens sind, würde von einer korrekten Terminologie profitieren. Warum das Konzept von norm in Base.LinAlg definiert ist und inner , das sich in derselben Kohorte befindet, in einem Paket definiert werden sollte? Abgesehen von dieser Inkonsistenz hat die Sprache bereits dot , weshalb ich mich frage, warum sie etwas so Spezifisches und kein allgemeineres Konzept haben sollte?

Sie möchten also alle möglichen mathematischen Konzepte in der Ausgangssprache? Etwas nicht in Base definiert zu haben, zwingt die Leute nicht dazu, die falsche Terminologie zu verwenden. Die Funktion norm wird aus LinAlg exportiert, da sie in LinAlg definiert und verwendet wird. Ähnlich für dot . Schlagen Sie vor, dot in inner ?

Sie möchten also alle möglichen mathematischen Konzepte in der Ausgangssprache?

Ich habe das nie gesagt.

Etwas nicht in Base definiert zu haben, zwingt die Leute nicht dazu, die falsche Terminologie zu verwenden.

Ich bin sicher, dass es nicht so ist. Die Förderung der falschen Terminologie ist das Problem. Leute mit einem weniger mathematischen Hintergrund werden die Verwendung von Punkt übernehmen, weil sie es in Base sehen. Die Verwendung des Begriffs „Punktprodukt“ zur Darstellung des Konzepts des inneren Produkts ist falsch. Es ist auch schädlich für die mathematische Gemeinschaft, die hin und wieder darum kämpft, diese Narben zu reparieren, die falsche Terminologie hinterlassen hat. Studenten meiner Generation müssen ständig auf alte Bücher zurückgreifen, um die Terminologie richtig zu verstehen, das sollte nicht der Fall sein.

Schlagen Sie vor, dass dot in inner umbenannt werden soll?

Das wäre meiner Meinung nach schon eine große Verbesserung. Siehe alle Beispiele, die ich oben zu Funktions- und Zusammensetzungsdaten gegeben habe. Menschen in diesen Gemeinschaften würden niemals den Begriff dot in ihrer Arbeit verwenden. "Punkt" ist eher ein Begriff aus der Informatik als alles andere.

Das Umbenennen dot in inner ist ein ganz anderer Vorschlag als das Hinzufügen inner zu Base zusätzlich zu dot . Das ist eher eine Frage zur "korrekten Terminologie", die Sie und andere Linalg-Leute klären müssen, obwohl ich mich zu erinnern scheine, dass wir dies einmal mit dem Fahrrad abgestellt haben und zu dem Schluss gekommen sind, dass dot der richtige Name für das ist, was diese Funktion implementiert.

Es gab eine kleine Diskussion darüber in https://github.com/JuliaLang/julia/issues/22227 und https://github.com/JuliaLang/julia/pull/22220

Das Umbenennen von dot in inner ist ein ganz anderer Vorschlag als das Hinzufügen von inner zu Base zusätzlich zu dot.

Folgendes habe ich in meiner ersten Nachricht in diesem Thread vorgeschlagen:

Ich würde gerne vorschlagen, dot in inner umzubenennen oder vielleicht Benutzer anzuweisen, inner(x,y) als ein allgemeines inneres Produkt zwischen den Objekten x und y zu definieren

Ich wiederhole Punktprodukt ist der falsche Begriff für die Operation, die ich hier bespreche. Inneres, äußeres, Skalarprodukt... das sind mathematische Objekte. "Punktprodukt" ist ein Rechenobjekt: Es erhält zwei Zahlenfolgen und führt x1*y1 + x2*y2 + ... xn*yn aus, eine nutzlose Operation in anderen mathematischen Räumen.

Ich hatte mich auf die zweite von Ihnen vorgeschlagene Option konzentriert, bei der anscheinend Base.inner mit einem Fallback hinzugefügt wurde, um $#$1$# Base.dot anzurufen. Beide Optionen sind möglich, aber beide erfordern eine Begründung: Um eine neue Operation hinzuzufügen, braucht man einen Grund, warum sie nicht einfach in einem Paket sein kann (worum es im ersten Teil dieser Diskussion ging); um umzubenennen, muss entschieden werden, dass dot der falsche Name und inner der richtige ist (wozu sich das Gespräch anscheinend gedreht hat).

@juliohm Es lohnt sich wahrscheinlich (erneut) darauf hinzuweisen, dass derzeit aktiv versucht wird, Base zu verkleinern und die Verwendung von Paketen zu fördern. In diesem Fall scheint dot für alle Typen korrekt zu sein, die an der linearen Algebra teilnehmen, die in Standard-Julia bereitgestellt werden (dh Number und Array - also ja, es gibt eine bestimmte, bekannte , endliche Basis in allen Fällen - daher glaube ich nicht, dass wir einen Fehler in der Terminologie gemacht haben, obwohl es möglicherweise bessere Möglichkeiten gibt). Ich bin nicht gegen diesen Vorschlag - wollte aber darauf hinweisen, um zu verdeutlichen, warum Sie möglicherweise einen "latenten" Widerstand gegen Änderungen erfahren.

Denken Sie auch daran, dass eine ganze Reihe von Julia-Neulingen vielleicht mit einem Punktprodukt, aber nicht mit einem inneren Produkt vertraut ist (sagen wir, sie haben ein bisschen Physik an der Universität studiert, aber keine Mathematik im Hauptfach), also gibt es auch einige Gründe dafür Behalten Sie dot (ganz zu schweigen davon, dass wir einen Infix-Operator haben, dem es entspricht - wir könnten es einfach inner zuordnen, nehme ich an, aber das ist etwas weniger offensichtlich). Wir haben auch keine outer -Funktion oder eine Vielzahl anderer möglicher Operationen.

Daher ist es schwierig, vernünftig zu argumentieren, dass es besser ist, dies in Base (oder LinAlg ) zu packen, als es in ein Benutzerpaket zu packen. Der Hauptgrund scheint zu sein, eine Schnittstelle bereitzustellen, die von anderen geteilt und erweitert werden kann - ist das eine vernünftige Zusammenfassung? Das Argument, generischen Code aus Clustering.jl mit Ihrem inneren Produkt arbeiten zu lassen, scheint ziemlich überzeugend. Auch in dem Kontext, in dem wir LinAlg in ein stdlib-Paket aufzuteilen scheinen, dachte ich, dass ich wahrscheinlich gerne ein inner einfügen würde, wenn ich ein Paket namens LinearAlgebra schreiben würde inner Funktion zur Erweiterung durch andere.

Danke @andyferris für das Teilen deiner Gedanken. Ich sehe den Widerstand sehr deutlich, was mich nicht sehr begeistert. Trotzdem bin ich neugierig, wie dieser spezifische Vorschlag zu einer Code-Erhöhung führt? Für mich scheint es eine triviale Codeänderung mit einer erheblichen Verbesserung der Abstraktion zu sein. Das Beispiel mit Clustering.jl ist nur eines von vielen, denken Sie an jede Kernel-basierte Methode, die dazu gebracht werden kann, mit beliebigen Julia-Typen zu arbeiten, für die der Begriff des inneren Produkts existiert. MultivariateStats.jl hat viele davon.

In Bezug auf den Kommentar zu LinAlg , das in ein separates Paket aufgeteilt wurde, stimme ich zu, dass es ein guter Ort zu sein scheint, um mathematische Produkte zu kapseln. Ich gehe davon aus, dass dieses LinearAlgebra -Paket der Zukunft standardmäßig in eine Julia-Session importiert wird und somit alle Benutzer Zugriff auf das Konzept von inner , outer usw. haben sofort.

Ja, die Standardbibliotheken werden alle zusammen mit dem Julia-Systemabbild erstellt und sind standardmäßig verfügbar. Zumindest für die v1.x-Serie muss niemand using LinAlg eingeben (ich glaube nicht, dass es in LinearAlgbebra umbenannt wird, übrigens, ich habe das nur als hypothetischen Konkurrenten erfunden) .

Zur Verdeutlichung würde es mit Standard-Julia geladen werden, sodass Sie nichts installieren müssten, aber Sie müssten trotzdem using LinAlg schreiben, um die exportierten Namen zu erhalten.

Hier wird es seltsam, richtig, da wir die * Methoden und so weiter ohne using LinAlg bekommen? (mit anderen Worten, LinAlg ist eine Art Pirat).

Ja, das ist im Grunde der Punkt, an dem wir die Grenze ziehen müssen: Base muss so viel lineare Algebra-Funktionalität definieren, wie nötig ist, um LinAlg nicht zu einem Piraten zu machen, also ist Matmul in Base definiert, weil Array und * beide sind. Funky Matrix-Typen und Nicht-Basisoperationen leben dort jedoch.

Lassen Sie mich Ihnen ein konkretes Beispiel geben und Sie fragen, wie Sie es mit der aktuellen Schnittstelle lösen würden, vielleicht kann dies die Dinge für mich klären.

Ziel ist es, eine Faktorenanalyse mit Zusammensetzungsdaten durchzuführen. Ich habe einen Typ namens Composition und ein inneres Produkt im Raum der Kompositionen. Ich sammle viele Proben (zB Gesteinsproben) und lege sie alle in ein großes Vector{Composition} (zB Zusammensetzung = %Wasser, %Getreide, %Luft). Jetzt möchte ich einen Faktoranalysealgorithmus aufrufen, der in einem anderen Paket (z. B. MultivariateStats.jl) für diesen Datenvektor implementiert ist. Wie würden Sie das generisch implementieren, ohne dass standardmäßig ein inner -Produkt importiert wird?

Was ich aus den letzten Kommentaren verstanden habe, ist, dass sowohl MultivariateStats.jl als auch CoDa.jl von LinAlg.jl abhängen müssten. Die Abhängigkeit in MultivariateStats.jl besteht lediglich darin, den Namen inner in den Geltungsbereich zu bringen. Die Abhängigkeit in CoDa.jl besteht darin, eine Methode für inner zu definieren, die von MultivariateStats.jl aufgerufen werden kann. Ist es das, was Sie vorschlagen?

Es scheint, dass Composition{D} ein D dimensionaler Vektorraum unter + und * ist.

Ich wäre ziemlich versucht, den dualen Vektorraum zu definieren.

Sie könnten also adjoint(::Composition) -> DualComposition und *(::DualComposition, ::Composition) -> scalar (aktuell inner ) definieren. DualComposition müsste nicht viel tun, außer ein Composition darin zu halten.

Der erste Satz in https://en.wikipedia.org/wiki/Dot_product scheint darauf hinzudeuten, dass dot eine Operation für zwei beliebige Iterables sein könnte. Wir könnten es rekursiv machen und es für Number definieren und inner als abstrakte Funktion der linearen Algebra definieren, die sich zufällig für Number und AbstractArray überschneidet.

Danke @andyferris , ich schätze deine Gedanken zum dualen Raum. Ich würde mich für diese Aufgabe jedoch lieber nicht auf einen neuen Typ verlassen. Die endgültige Lösung ist unnötig komplex.

Was mich interessiert zu verstehen ist, warum so etwas wie:

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

export inner, norm

nicht willkommen in Base? Ich gehe davon aus, dass dies alles ist, was erforderlich ist, um die Funktionsnamen generisch zu definieren, damit sich Benutzer der Sprache spezialisieren können. Denken Sie daran, dass ich diese Fragen mit dem aufrichtigen Interesse stelle, die Sichtweise der Kernentwickler zu verstehen. Ich will das sagen, bevor das Gespräch wieder in die falsche Richtung geht.

Aus der Perspektive von jemandem, der sich allgemein für Mathematik interessiert, fühlt es sich unnatürlich an, diese Konzepte nicht standardmäßig zu exportieren und stattdessen innerhalb von LinAlg zu definieren. Ich denke an LinAlg als Implementierungen dieser High-Level-Konzepte für Array-Typen. Vielleicht erfordert meine gesamte Arbeit keine lineare Algebra auf Arrays, aber ich könnte dennoch vom Konzept des inneren Produkts über Pakete hinweg profitieren (z. B. MultivariateStats.jl, Clustering.jl). Außerdem möchte ich möglicherweise nicht LinAlg als Abhängigkeit in meinem Paket haben, da dies nicht der Fall ist.

Wenn ich es weiter betonen darf, gibt es das Konzept des inneren Produkts, das unabhängig von Arrays ist. Dieses Konzept wird durch die Anweisung export inner in Base dargestellt. Es gibt die Implementierung innerer Produkte für Array-ähnliche Objekte, die die Koordinaten inner(x,y) = sum(x.*y) darstellen. Diese Operation kann bei Bedarf wie oben als Fallback-Methode in Base definiert werden.

Ein weiteres Beispiel für einen Anwendungsfall sind Krylov-Methoden. Wenn Sie zB Funktionsräume mit inneren Produkten haben, dann könnten Sie Krylov-Methoden verwenden, um ein lineares Problem oder Eigenproblem in einem kleinen endlichdimensionalen Unterraum dieses unendlichdimensionalen Funktionsraums zu approximieren.

Auch ich habe meine eigenen Objekte, die einen Vektor/Hilbert-Raum bilden, aber nicht Teil von <: AbstractArray sind. Aus der Analogie, dass auch Arrays mit dem Rang N>1 Vektorräume bilden und als 'Vektoren' in Krylov-Methoden verwendet werden können, bin ich auf die Verwendung vecdot und vecnorm angewiesen ist der verallgemeinerte Begriff des inneren Produkts und der Norm. Also habe ich ein Paket mit Krylov-Methoden entwickelt, das Funktionen als lineare Operatoren verwendet und bei dem die Vektoren jeden Typs haben können, vorausgesetzt, Objekte dieses Typs unterstützen vecdot , vecnorm und einige mehr andere Dinge ( scale! , zero , ...). Aber vielleicht missbraucht das, was mit diesen Konzepten in Base gemeint war, also wäre es gut, hier die richtige Schnittstelle zu korrigieren.

Richtig - vecdot könnte in inner umbenannt werden.

(Jetzt frage ich mich vage, ob norm eigentlich matrixnorm für Matrizen mit norm heißen sollte, die immer mit inner übereinstimmen. Es scheint, dass es vielleicht zwei verschiedene gibt Dinge, die mit norm , was einige Schwierigkeiten bei der Verallgemeinerung verursacht)

Tatsächlich ist es für allgemeine vektorähnliche Objekte auch nützlich, die Dimension des Vektorraums abzufragen (z. B. um zu überprüfen, ob die Krylov-Dimension in meinem Anwendungsbeispiel nicht größer sein sollte als die Dimension des gesamten Raums). Das Beispiel von verschachtelten Arrays zeigt, dass length hier nicht das richtige Konzept ist, dh für diese Fälle müsste ein rekursiver Längenbegriff vorhanden sein.

Nun zum Beispiel der Verwendung von verschachtelten Arrays als allgemeinem Vektor: vecdot und vecnorm sind in einigen Fällen nicht einmal die korrekte Vorstellung von innerem Produkt und Norm, wie in #25093 diskutiert, dh sie sind es vecdot und vecnorm nicht rekursiv aufrufen. Meine Interpretation dieser Funktionen als generisches inneres Produkt und Normfunktion hat #25093 ausgelöst, aber es scheint, dass diese Funktionen möglicherweise nicht so beabsichtigt waren (nicht sicher, was sie stattdessen tun sollten).

Ich stimme also zu, dass wir hier eine konsistente Schnittstelle brauchen, die paketübergreifend verwendet werden kann, die daher an eine zentrale Stelle gehören würde (wahrscheinlich nicht in Base, aber sicherlich in eine Standardbibliothek, z. B. so, dass man using VectorSpaces machen muss ). Bei der Benennung sehe ich zwei Möglichkeiten:

Option 1 (meine bisherige Interpretation):
das Präfix vec gibt die Eigenschaft dieses Objekts an, wenn es als generischer Vektor interpretiert wird, daher

• vecdot und vecnorm für verschachtelte Arrays wurden behoben (PR #25093)
• eine neue veclength -Definition wird hinzugefügt

Option 2 (wahrscheinlich besser): Verwenden Sie mathematisch korrektere Namen

• inner
• dimension
• Aber was tun mit norm ?

Und schließlich pingen Sie einfach @stevengj an, da er sicherlich einige nützliche Kommentare haben wird; Ich entschuldige mich, wenn dies unpraktisch ist.

Der Name ist der am wenigsten interessante Teil von all dem. Ich habe keine Probleme damit, die Funktion dot zu verwenden, um auf ein allgemeines inneres Produkt für beliebige Hilbert-Räume zu verweisen. Es gibt nicht nur keine andere vernünftige Bedeutung für zB "Punktprodukt zweier Funktionen", es ist ziemlich üblich, "Punktprodukt von Funktionen" im informellen Gebrauch zu sehen, insbesondere in pädagogischen Umgebungen, wo man versucht, die Analogie zum endlichdimensionalen Vektor hervorzuheben Räume.

@juliohm , inner(x,y) = sum(x.*y) ist im Allgemeinen nicht einmal ein inneres Produkt, daher wäre dies ein ziemlich schrecklicher Fallback, um ihn in die Basis einzufügen.

Aber dot berechnet bereits nicht das richtige innere Produkt (tatsächlich scheitert es) für verschiedene Objekte in Base, die sich als Vektoren verhalten, zB Arrays mit dem Rang N>1 oder verschachtelte Arrays (verschachtelte Vektoren sind der einzige Fall). wo es richtig funktioniert). Darüber hinaus wird der generische Name norm für Matrizen mehrdeutig, da ich der aktuellen Wahl zustimme, dass dies die induzierte Norm zurückgibt, aber gelegentlich auch die "Vektornorm" (Frobenius-Norm) erforderlich ist.

Daher wäre mein Vorschlag mit der geringsten Auswirkung, die Semantik vecnorm(x) = norm(vec(x)) loszulassen und vecnorm(x) stattdessen als „für x als ein Objekt eines generischen Typs zu interpretieren, das sich wie ein verhält Vektorraum, berechnen Sie die entsprechende Vektornorm von x " (und ähnlich mit vecdot ). Während dies eine Verschiebung der Interpretation (und damit der Dokumentation) ist, wäre die tatsächliche Implementierung/Aktion für Objekte in Base nicht sehr unterschiedlich (PR #25093) und würde in den meisten Fällen zum gleichen Ergebnis führen (Rang N Arrays von Skalaren oder Vektoren). Eine Funktion veclength(x) , die die entsprechende Vektorraumdimension von x zurückgibt, würde die Schnittstelle vervollständigen.

Benutzerdefinierte Pakete sollten dann lernen, diese Funktionen zu implementieren, wenn sie neue Typen definieren, die sich als Vektoren verhalten.

Es ist ziemlich üblich, das "Punktprodukt von Funktionen" im informellen Gebrauch zu sehen, insbesondere in pädagogischen Umgebungen, in denen versucht wird, die Analogie zu endlichdimensionalen Vektorräumen hervorzuheben

Sagen Sie bitte nicht, der Name sei unwichtig, denn das ist er. Ich wiederhole es zum n-ten Mal: ​​Skalarprodukt und Skalarprodukt sind nicht dasselbe. Jedes ernsthafte Material, das Arbeiten mit abstrakten Hilbert-Räumen aufdeckt, wird niemals "Punkt" verwenden. Wenn Sie lieber Wikipedia vertrauen als meinen Worten, hier sind die Definitionen kopiert und eingefügt:

Innenprodukt

In der linearen Algebra ist ein innerer Produktraum ein Vektorraum mit einer zusätzlichen Struktur , die als inneres Produkt bezeichnet wird. Diese zusätzliche Struktur ordnet jedem Vektorpaar im Raum eine skalare Größe zu, die als inneres Produkt der Vektoren bekannt ist.

Skalarprodukt

In der Mathematik ist das Punktprodukt oder Skalarprodukt eine algebraische Operation , die zwei gleich lange Zahlenfolgen (normalerweise Koordinatenvektoren) nimmt und eine einzelne Zahl zurückgibt.

Dieser Widerstand gegen die Verbesserung der Terminologie und der mathematischen Konsistenz in der Sprache ist demotivierend. Egal wie viele Fakten ich Ihnen präsentiere, egal wie viele Beispiele und Anwendungsfälle es gibt, es gibt kein anderes Gegenargument als „ich komme mit dot klar“.

@juliohm , Terminologie ist eine Frage der Konvention, nicht der Korrektheit. Ich stimme zu, dass im formalen Gebrauch für Hilbert-Räume, insbesondere für unendlich dimensionale, der Begriff "inneres Produkt" ziemlich ausschließlich verwendet wird. Aber wie gesagt, wenn Sie „Punktproduktfunktionen“ googeln, werden Sie auch viele informelle Verwendungen dieser Terminologie finden. Wenn Sie sagen "nehmen Sie ein Punktprodukt zweier Elemente dieses Hilbert-Raums", weiß jeder Mathematiker, dass Sie sich auf ein inneres Produkt beziehen, selbst für unendlich dimensionale Räume, sodass keine wirkliche Verwechslungsgefahr besteht, da es kein anderes gibt Standardverallgemeinerung des Begriffs "Punktprodukt". Deshalb finde ich die Rechtschreibdebatte „Punkt“ vs. „inner“ nicht so zentral.

Es ist wichtig, sich für die Semantik zu entscheiden, die man hier haben möchte, und für die Menge der Funktionen, die Typen implementieren sollten, wenn sie einen neuen Hilbert-Raum oder Banach-Raum definieren. Wenn Sie derzeit einen Typ definieren möchten, der einen neuen Hilbert-Raum darstellt, sollten Sie wohl dot und norm definieren (da uns derzeit ein Fallback für letzteres fehlt), und ich schätze, adjoint , wenn Sie die Zuordnung zu einem Objekt mit zwei Leerzeichen wünschen.

Wie @Jutho sagt, wird dies alles durch den Array-of-Arrays-Fall kompliziert, da es mehrere mögliche Dinge gibt, die man dort haben möchte. Da es keine standardisierten Namen für alle möglichen Semantiken gibt, ist es schwierig, Namen/Semantiken zu finden, die alle zufrieden stellen. Siehe #25093 für die Diskussion der vecdot -Semantik. Ich selbst habe hier keine gute Antwort.

Einige Möglichkeiten hier

1. Summe von x[i]' * y[i] . Derzeit sind dies dot(x,y) . Kein inneres Produkt für Vektoren von Matrizen (wo es eine Matrix ergibt) und derzeit nicht alle für mehrdimensionale Arrays definiert.
2. Summe von dot(x[i], y[i]) , einschließlich für mehrdimensionale Arrays, und conj(x)*y für Number . Derzeit sind dies vecdot(x,y) .
3. Einige Funktionen, z. B. inner(x,y) , sind so definiert, dass sie immer ein echtes inneres Produkt sind, und für Arrays summieren sie inner(x[i],y[i]) – im Wesentlichen der „rekursive Vecdot“, den @Jutho will. Aber dann ist dieses innere Produkt für die Matrizen A nicht mit der induzierten Norm norm(A) , die unsere aktuelle Definition norm ist. Um dies zu beheben, müssten wir norm(A) ändern, damit Matrizen standardmäßig auf die Frobenius-Norm eingestellt werden, was möglicherweise eine weitreichende Breaking Change wäre.

Eine Frage (teilweise diskutiert in #25093) ist, ob wir alle drei davon in Base brauchen oder ob wir mit zwei davonkommen (und welche zwei und wie nennen wir sie). Der Vorschlag von @Jutho besteht , so wie ich es verstehe, im Wesentlichen darin, Option 2 in Base zu eliminieren und dann vecdot und vecnorm für Option 3 zu verwenden. Dann haben wir ein echtes inneres Produkt, aber die Terminologie ist ziemlich einzigartig für Julia und ein bisschen seltsam für zB unendlich dimensionale Hilbert-Räume. Das wäre natürlich kein Weltuntergang.

Eine andere Möglichkeit (etwas unabhängig davon, was wir mit vecdot machen) wäre, (zurück) zu verlangen, dass dot ein echtes inneres Produkt ist. dh Verhalten 1 eliminieren und dot(x::AbstractVector, y::AbstractVector) gleich sum dot(x[i],y[i]) machen. Definieren Sie es immer noch nicht für mehrdimensionale Arrays (um konsistent mit norm zu bleiben).

Meine derzeitige persönliche Neigung wäre, dot als echtes inneres Produkt zu definieren (das mit norm konsistent sein sollte) und es für Vektoren in die Summe von dot(x[i],y[i]) zu ändern (dh zu ändern der Vektor-von-Matrizen-Fall) und ihn weiterhin nicht für mehrdimensionale Arrays zu definieren. Definieren Sie dann vecdot , um vecdot rekursiv aufzurufen, wie @Jutho vorschlägt, mit einem Fallback vecdot(x,y) = dot(x,y) . Sagen Sie schließlich, dass neue "Hilbert-Leerzeichen"-Typen dot und norm definieren sollten. Dies scheint mir die am wenigsten störende und nachvollziehbarste Änderung zu sein.

(Ein norm(x) = sqrt(real(dot(x,x))) -Fallback ist auch eine Möglichkeit, obwohl es etwas gefährlich ist, da es anfällig für einen falschen Überlauf ist. Beachten Sie, dass wir sqrt(dot(x,x)) aus technischen Gründen nicht als Fallback verwenden können: Wir wollen eine Real Ergebnis, kein Complex Ergebnis.)

Danke @stevengj für diese informative Reaktion. Nur ein kleiner Kommentar:

mit Fallback vecdot(x,y) = dot(x,y) . Sagen Sie schließlich, dass neue "Hilbert-Leerzeichen"-Typen dot und norm definieren sollten.

Dabei gibt es zwei Probleme. vecdot(x,y) = dot(x,y) Fallback kann nicht existieren, da vecdot bereits Any Argumente akzeptiert, um mit allgemeinen Iteratoren umzugehen. Das zweite Problem ist, dass, wenn dot und norm das wahre innere Produkt und die Norm sind, die jeder Vektor wie der Benutzertyp definieren sollte, dann sogar beim Schreiben eines Pakets mit zB Krylov-Methoden mit vollständig generischen vektorähnlichen Typen funktionieren sollte, funktioniert es immer noch nicht für den Fall, dass der Benutzer verschachtelte oder mehrdimensionale Arrays als vektorähnliche Objekte verwenden möchte. Daher würde ich argumentieren, dass vecdot und vecnorm das allgemeine innere Produkt und die Norm von vektorähnlichen Objekten sind. Dies passt auch gut zu der Tatsache, dass die meisten Leute für Matrizen tatsächlich erwarten, dass norm die induzierte Matrix/Operator-Norm ist.

Wie für einen tatsächlichen Anwendungsfall (um zu zeigen, dass dies kein Ausnahmefall ist). Stochastische Matrizen haben einen größten (Perron-Frobenius-) Eigenwert, für den der entsprechende Eigenvektor eine Festkomma-Wahrscheinlichkeitsverteilung darstellt. Bei ihrer Quantenverallgemeinerung verallgemeinert sich die Wahrscheinlichkeitsverteilung zu einer positiv bestimmten Matrix (der Dichtematrix), und eine solche Matrix ist der Fixpunkt (Eigenvektor, der dem größten Eigenwert entspricht) einer vollständig positiven Abbildung, dh der Abbildung rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) wobei also rho die Dichtematrix und A[i] eine Matrix für alle i ist (bekannt als die Kraus-Operatoren, die die vollständig positive Abbildung darstellen). Für große Matrixdimensionen ist ein Arnoldi-Verfahren ideal geeignet, um die Fixpunktdichtematrix zu finden.

Meine derzeitige persönliche Neigung wäre, Punkt als echtes inneres Produkt zu definieren (das mit der Norm übereinstimmen sollte) und es für Vektoren in die Summe von Punkt (x [i], y [i]) zu ändern. Sagen Sie schließlich, dass neue "Hilbert-Leerzeichen"-Typen Punkt und Norm definieren sollten.

Das ist schon eine enorme Verbesserung. Die Dokumentation dot mit inner -Semantik in Base wird es Benutzern zumindest ermöglichen, ihre eigenen Bereiche zu definieren, ohne unnötige Bibliotheken zu importieren. Ich bin nicht glücklich über die Namensgebung, aber zumindest wäre die Funktionalität für diejenigen verfügbar, die sie brauchen.

Ja, ich denke, es wird schön sein, eine dokumentierte Schnittstelle zu haben, die für "Hilbert-Space"-Typen implementiert werden kann.

Wenn Sie an diese generische Schnittstelle für Vektorräume denken, sollte dies natürlich die Frobenius-Norm für Matrizen sein, wenn sie wie oben vorgeschlagen norm enthält (und für höherdimensionale Arrays verallgemeinert werden, da alle Arrays Elemente eines Vektors sind Platz). In diesem Fall bräuchten wir eine separate "Operatornorm"-Funktion für Matrizen ( matnorm oder opnorm oder so etwas oder ein Schlüsselwortargument für norm ...).

@andyferris , bitte beachte meinen letzten Kommentar. norm und dot können nicht zur allgemeinen Schnittstelle des Hilbert-Raums werden, da sie in Julia nicht einmal mit vektorähnlichen Objekten wie höherdimensionalen Arrays und verschachtelten Arrays arbeiten. Daher sind vecdot und vecnorm ein „besserer“ (im Sinne von am wenigsten brechender) Kandidat dafür.

Wiederbelebung dieses Themas, das ich für ziemlich relevant für die Art von Mathematik halte, die ich in naher Zukunft mit der Sprache zu tun erwarte. Gibt es einen Konsens darüber, was getan werden soll, um die Allgemeingültigkeit und Semantik innerer Produkte zu verbessern?

Hier ist der Teil meiner persönlichen Mathe-Ontologie zum Thema Produkt.
Wenn es helfen könnte, die Erinnerung aufzufrischen / Konsens zu bringen

• Punktprodukt ; Synonyme : Skalarprodukt
• Innenprodukt
• Kreuzprodukt
• Tensorprodukt ; Synonyme : äußeres Produkt
• Keilprodukt ; Synonyme : äußeres Produkt
• Tasse Produkt
• dreifaches Produkt

Bonus: keine Wikipedia-Referenzen

An diesem Punkt scheint @Juthos Vorschlag in #25093 die am wenigsten störende Änderung zu sein, auch wenn mir die vec* -Terminologie in diesem Zusammenhang etwas seltsam vorkommt.

Ich stimme zu, dass die vec* Terminologie seltsam ist. Aus diesem Grund wäre es für alle Benutzer von Vorteil, die Funktionen in Standardnamen umzubenennen.

Ich stimme ebenfalls zu, dass die vec* -Terminologie seltsam ist.

Ich stimme zu, als Alternative zu vecdot könnten wir eine neue Methode inner einführen, aber ich kenne keinen guten Namen, um vecnorm zu "ersetzen". Tatsächlich finde ich vecnorm gar nicht so schlecht, Vektornorm ist ein etablierter und eindeutiger Begriff für die Operation, die wir wollen.

Das grundlegende Problem besteht hier bei Matrizen und mehrdimensionalen Arrays, bei denen das übliche norm(A) keinem Skalarprodukt entspricht, sowie bei Arrays von Arrays, wie oben diskutiert. In diesen Fällen ist eine gewisse Begriffsklärung (z. B. vec* oder fro* ) erforderlich, um anzugeben, welches innere Produkt gemeint ist.

Sie könnten eine inner Funktion haben, die standardmäßig vecdot ist, aber es ist ein wenig albern, zwei Namen für dieselbe Funktion zu haben, und es gibt immer noch das Problem, wie man die Norm nennt.

Ich finde den Namen vecdot auch seltsam, tatsächlich wusste ich nicht einmal, dass er existiert, und hatte meine eigene Funktion dafür erstellt ... namens inner .

Mein Verständnis ist, dass wir einfach das ungerade vecdot zugunsten von inner verwerfen und ihm die innere Produktsemantik geben können, damit Benutzer ihre eigenen Bereiche implementieren können.

Bezüglich der norm , das weiß ich nicht. Ich habe diese Ausgabe eröffnet, um innere Produkte zu diskutieren, vielleicht wäre eine andere Ausgabe angebracht, um den Stand der Normen in Base zu diskutieren.

Ich nehme an, wir könnten inner(x,y) und innernorm(x) = sqrt(inner(x,x)) (mit optimierten Spezialfällen, um einen Überlauf zu vermeiden) anstelle von vecdot und vecnorm haben. innernorm ist etwas ungewöhnlich, aber im Kontext ziemlich klar.

Daumen hoch für diese Änderung. Die Namen inner und innernorm sind klar und stimmen mit den Konzepten überein. Ich wünschte, sie könnten es zu Julia v1.0 schaffen.

inner und innernorm erscheinen mir in Ordnung.

Ich würde trotzdem sagen, dass unsere norm -Funktion meiner Meinung nach nicht wirklich gut in Julias generisches Funktions- und Versandsystem und das, was ich "klare Schnittstellen" nenne, wo der Versand nicht erfolgen sollte, passt semantische Entscheidungen, nur Implementierungsentscheidungen. Ich persönlich würde es vorziehen, wenn wir sagen könnten " norm gibt die Norm eines Elements eines Vektorraums zurück", wobei Matrizen und lineare Operatoren immer noch Elemente von Vektorräumen sind (Sie können sie addieren und mit einem Skalar multiplizieren). . Wir könnten zB auch " opnorm gibt die Operatornorm eines linearen Operators zurück" (oder matnorm oder was auch immer) haben.

Im Moment haben wir " norm gibt die Norm eines Elements eines Vektorraums zurück, es sei denn, das Element ist auch ein linearer Operator, in diesem Fall geben wir Ihnen stattdessen den Operator norm". Ich persönlich bin der Meinung, dass Versand niemals überraschend sein sollte.

Das heißt, ich würde eine Funktion bevorzugen, die immer die Vektornorm ausführt, und eine andere Funktion, die immer die Operatornorm ausführt, und keine Funktion, die versucht, beides zu tun.

Gefällt mir noch besser @andyferris :+1: Spezifische Normen, die nicht die durch das innere Produkt im Raum induzierten Normen sind, könnten einen spezifischeren Namen haben. Der Name norm würde genau norm(x) = sqrt(inner(x,x)) bedeuten und könnte nach Bedarf für Benutzertypen neu definiert werden.

Ich persönlich würde es vorziehen, wenn wir sagen könnten: „ norm gibt die Norm eines Elements eines Vektorraums zurück“

Die aktuelle Funktion norm erfüllt diese Definition. Für Matrizen berechnet es die induzierte (Operator-)Norm, die eine vollkommen gültige Norm für einen Vektorraum ist . (Vektorräume müssen überhaupt keine inneren Produkte oder Normen haben.)

Sie sind vielleicht etwas verwirrt über die Definition einer "Norm", wenn Sie denken, dass die Operatornorm keine "Norm eines Vektorraums" ist.

Dies ist auch eine nützliche Unterscheidung zwischen norm und innernorm . Wenn Sie norm definieren, würde ich sagen, dass dies nur impliziert, dass Sie einen Banachraum (oder zumindest einen normierten Vektorraum) haben. Wenn Sie innernorm definieren, bedeutet dies, dass Sie einen Hilbert-Raum (oder zumindest einen inneren Produktraum) haben und dass diese Norm mit inner konsistent ist.

Zum Beispiel ist die adaptive numerische Integration (ala quadgk) etwas, das nur einen normierten Vektorraum erfordert, keinen Inner-Product-Raum.

Klar, sorry, ich war vielleicht etwas zu ungenau mit meiner Sprache. Es gibt offensichtlich viele gültige Normen für einen Vektorraum, einschließlich verschiedener Operatornormen.

Ich denke, worauf ich hinaus will, ist, dass ich es vielleicht vorziehen würde, welche Norm expliziter als implizit gewählt wird? Und wenn Sie die gleiche Funktion verwenden (zB ohne zusätzliche Schlüsselwortargumente), erhalten Sie die "gleiche" Norm, in diesem Fall scheint die Euklidische eine einigermaßen vertretbare Wahl für AbstractArray zu sein.

Dies ist auch eine nützliche Unterscheidung zwischen norm und innernorm . Wenn Sie Norm definieren, würde ich sagen, dass dies nur impliziert, dass Sie einen Banachraum (oder zumindest einen normierten Vektorraum) haben. Wenn Sie innernorm definieren, impliziert dies, dass Sie einen Hilbert-Raum (oder zumindest einen inneren Produktraum) haben und dass diese Norm mit inner konsistent ist.

Das scheint vernünftig, aber ich würde mich trotzdem fragen, warum ein Objekt, wenn es ein innernorm hat, ein anderes norm benötigt? Ich würde alternativ vorschlagen, dass die Schnittstelle für den Banach-Raum norm erfordert, während eine Schnittstelle für innere Produkträume sowohl norm als auch inner bereitstellen würde. Diese Funktionen können dann in generischem Code verwendet werden, der Objekte von Banach- oder Inner-Product-Räumen erwartet (EDIT: mit dem Gedanken, dass Code, der in Banach-Räumen funktioniert, automatisch auch auf Inner-Product-Räumen funktioniert).

Ich denke, Sie schlagen vor, dass sich norm(x) immer auf eine Art elementweise euklidische Norm bezieht (dh eine Frobenius-Norm für Matrizen), dh im Grunde ist das, was vecnorm jetzt modulo der rekursive Fall ist. In diesem Fall könnten wir dot(x,y) genauso gut neu definieren, um das entsprechende innere Produkt zu sein ( inner funktioniert auch, aber dot hat den Vorteil einer Infix-Variante x ⋅ y ).

Im Prinzip bin ich damit einverstanden, aber dies wäre eine bahnbrechende Änderung, und es könnte vor 0,7 etwas spät sein, um das einzubauen …

Ist L2 auch ein guter Standard in hochdimensional?
In diesem Artikel geht es um Entfernung, aber es kann sich auch um die Norm handeln
https://stats.stackexchange.com/questions/99171/why-is-euclidian-distance-not-a-good-metric-in-high-dimensions

In diesem Fall könnten wir genauso gut dot(x,y) als das entsprechende innere Produkt umdefinieren (inneres funktioniert auch, aber dot hat den Vorteil einer Infix-Variante x ⋅ y)

Können wir dot ganz loswerden? Die Infix-Notation sollte nichts mit der Existenz einer Funktion namens dot zu tun haben. Definieren Sie einfach das Infix mit der Methode inner für Julia-Arrays. Ist das möglich?

Genau das ist es, das Skalarprodukt: eine praktische Notation x ⋅ y für Skalarprodukte zwischen x- und y-Vektoren in R^n mit euklidischer Geometrie.

@stevengj Ich denke, das ist eine gute Zusammenfassung, ja.

@o314 Ist L2 ein guter Standard für hohe Dimensionalität? Möglicherweise nicht, aber ich würde es wirklich hassen, wenn zB die von norm(v::AbstractVector) gewählte Norm von $#$ length(v) $#$ abhängen würde :) Ich möchte auch nicht, ob meine Matrix oder ein höherdimensionales Array an zweiter Stelle steht ist "zu groß für L2" - ich würde vorschlagen, dass dies vielleicht explizit vom Benutzer markiert werden sollte?

@juliohm Das ist definitiv möglich, obwohl, wie bereits erwähnt, dies bahnbrechende Änderungen sind, die wir vorschlagen. (Wiederum modulo, was im rekursiven Fall zu tun ist, und frühere Diskussionen über die möglichen Unterschiede zwischen inner und dot ).

@stevengj , meine Interpretation dessen, was @andyferris andeutete, ist, dass es aufgrund der Enteneingabe schwierig ist zu entscheiden, ob ein Benutzer ein Objekt als Vektor interpretieren möchte (und eine entsprechende Vektor p -Norm verwenden möchte). oder als Operator (und eine induzierte p -Norm berechnen). Daher denke ich, dass es keine andere Wahl gibt, als explizit anzugeben, welches Verhalten gewünscht wird. Der aktuelle Ansatz ist insofern etwas seltsam, als norm versucht, implizit zu erraten, ob die Vektornorm oder die induzierte Norm basierend auf der Eingabe gewählt werden soll, und vecnorm eine Möglichkeit ist, explizit anzugeben, was Sie möchten die Vektornorm (weshalb ich auch vecnorm nicht so einen schlechten Namen finde). Eine radikalere Änderung wäre, norm standardmäßig immer auf die Vektornorm zu setzen und explizit anzugeben, wann Sie die induzierte Norm wollen, indem Sie ein (Schlüsselwort-)Argument oder eine ganz andere Funktion verwenden.

Andererseits stört mich auch der Name innernorm nicht, was explizit darin zum Ausdruck kommt, dass es sich um eine innere produktbasierte Norm handelt (dh immer p=2 im euklidischen Fall). Ich finde es schwierig zu beurteilen, ob für benutzerdefinierte Objekte (vec)norm ein optionales Argument p als Teil der Schnittstelle unterstützen sollte, da in einigen meiner Anwendungsfälle nur p=2 einfach ist berechnen.

Genau das ist es, das Skalarprodukt: eine praktische Notation x ⋅ y für Skalarprodukte zwischen x- und y-Vektoren in R^n mit euklidischer Geometrie.

Dem stimme ich in dem Sinne zu, dass ich mich nicht erinnern kann, jemals die Notation x ⋅ y im Zusammenhang mit allgemeinen (z. B. komplexen) Vektorräumen gesehen zu haben. Ich denke, in solchen Fällen wird nur die mathematische Notation (x,y) oder die Dirac-Notation < x | y > verwendet. Im Elektromagnetismus verwendet man oft E ⋅ B für Vektoren im dreidimensionalen euklidischen Raum, und selbst wenn man eine komplexe Notation (dh Phasoren) verwendet, impliziert dies keine komplexe Konjugation. Falls erforderlich, wird in solchen Fällen explizit auf komplexe Konjugation hingewiesen. Ich hätte also nichts dagegen, wenn aus dot sum(x_i * y_i) würde und aus inner das richtige innere Produkt für allgemeine innere Produkträume würde. Leider ist dies wahrscheinlich nicht in einem einzigen Release-Zyklus möglich.

Ist L2 ein guter Standard für hohe Dimensionalität? Möglicherweise nicht, aber ich würde es wirklich hassen, wenn z. B. die von norm(v::AbstractVector) gewählte Norm von length(v) abhängen würde :) Ich möchte auch nicht raten, ob meine Matrix oder ein höherdimensionales Array ist "zu groß für L2" - ich würde vorschlagen, dass dies vielleicht explizit vom Benutzer markiert werden sollte?

Ich arbeite in der BIM -Welt, wo wir mit 2d und 3d umgehen, aber auch 4d, 5d, 6d können 7d sein. Wir gehen nie weiter. Wir wissen zu jedem Zeitpunkt, in welchen Dimensionen wir arbeiten und welcher Algo beteiligt ist. Das reicht weitgehend.

Ich kann den Standpunkt von Leuten, die in ML, Informationsabruf usw. arbeiten, nicht ausdrücken. Da ist vielleicht norminf besser. Was in meiner Perspektive wichtig ist, ist Erratbarkeit und Stabilität. Ich werde überhaupt nicht schockiert sein, wenn Leute in ML unterschiedliche Standardeinstellungen für ihre Sachen benötigen. Wenn es keine Verwirrung gibt. Z.B. es wird explizit und statisch zur Kompilierzeit entschieden. Es ist sogar Luxus, wenn es während der Algos-Anwendung stabil und konsistent bleibt.

Inspiriert von array:similar Nicht vollständig implementiert und testen.

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

Können wir Punkt ganz loswerden? Die Infix-Notation sollte nichts mit der Existenz einer Funktion namens Punkt zu tun haben. Definieren Sie einfach das Infix mit der inneren Methode für Julia-Arrays. Ist das möglich?

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

Dot / vecdot impliziert die Verwendung von Konjugation und die Entscheidung, wann zu BLAS übergegangen werden soll. das muss irgendwo gehandhabt werden. Dies sollte jedoch in einem einzigen Namensraum überschaubar sein.

Ist L2 ein guter Standard für hohe Dimensionalität? Möglicherweise nicht

L2 ist auch die gebräuchlichste Norm für unendlichdimensionale Räume (z. B. Funktionen). Ich denke, es ist ein vernünftiger Standardwert für jeden Vektorraum.

Natürlich möchten Sie auch andere Normen zur Verfügung haben. Wenn wir norm(x) so umdefinieren, dass es wo immer möglich elementweise L2 ist, dann wäre norm(x, p) elementweise Lₚ, und wir bräuchten eine andere Funktion (z. B. opnorm ) für die entsprechende induzierte / Betreibernormen.

Dem stimme ich in dem Sinne zu, dass ich mich nicht erinnern kann, jemals die Notation x ⋅ y im Zusammenhang mit allgemeinen (z. B. komplexen) Vektorräumen gesehen zu haben.

Ich habe in einem anderen Thread, IIRC, mehrere Zitate gegeben (z. B. verwendet BLAS dot für komplexe Punktprodukte, und Sie können pädagogische Quellen finden, die sogar den Begriff für innere Produkte von Funktionen verwenden). Der Begriff "inneres Produkt" wird normalerweise als "eine Verallgemeinerung eines Skalarprodukts" eingeführt. Ich glaube nicht, dass irgendjemand von der Notation von dot für ein euklidisches inneres Produkt allzu überrascht sein wird, und es ist praktisch, einen Infix-Operator zu haben.

Wir könnten dot natürlich beibehalten und inner einführen, aber ich denke, das würde zu einer verwirrenden Dichotomie führen – in den häufigsten Fällen wären die Funktionen gleichwertig, aber in seltenen Fällen (z. B. Arrays von Matrizen) würden sie sich unterscheiden.

Aber auch hier könnte es für Breaking Changes etwas spät sein, also müssen wir möglicherweise auf innernorm und inner zurückgreifen. Auf jeden Fall müsste jemand so schnell wie möglich eine PR erstellen.

Wenn sich ein vernünftiges Maß an Konsens bildet, kann ich möglicherweise etwas Bandbreite der Untersuchung der Implementierung in einem relevanten (kurzen) Zeitrahmen widmen, einschließlich potenzieller Breaking Changes. Ich schätze das Bestreben, die Semantik dieser Operationen zu klären und ihnen eindeutige Namen zu geben. Am besten!

Ich sehe zwei Hauptoptionen:

• Nicht brechend, fügt eine Funktion hinzu: inner(x,y) und innernorm(x) . Ersetzen vecdot und vecnorm und rekursiv für Arrays von Arrays.

• Breaking: Ändern Sie norm(x,p=2) so, dass es immer elementweise und rekursiv ist, ersetzen Sie vecnorm und führen Sie eine neue Funktion opnorm für den Operator/die induzierte Norm ein. Machen Sie dot(x,y) zum entsprechenden elementweisen Skalarprodukt und ersetzen Sie vecdot . (Alternative: in inner umbenennen, aber es ist schön, einen Infix-Operator zu haben, und es ist ärgerlich, sowohl dot als auch inner zu haben.)

Wenn ich Dinge von Grund auf neu entwerfen würde, würde ich 2 bevorzugen, aber es könnte zu störend sein, die Bedeutung von norm stillschweigend zu ändern.

Eine Zwischenoption wäre, inner und innernorm zu definieren (was vecdot und vecnorm ) und norm(matrix) auf opnorm zu verwerfen norm(matrix) = innernorm(matrix) wieder ein. Auf diese Weise können die Leute schließlich einfach inner und norm verwenden, und wir lassen dot als aktuelles ungerades Tier für Vectors-of-Arrays (das mit inner zusammenfällt

Eine Kuriosität bei innernorm ist, dass Sie eine Möglichkeit suchen, die L1- oder Linf-Normen "elementweise" anzugeben, aber keine davon entspricht einem inneren Produkt, daher ist innernorm(x,p) etwas irreführend.

Ich mag Ihre Zwischenoption.

Wie oben erwähnt, gefällt mir der Name innernorm(x) , weil er p=2 impliziert und es kein zweites Argument geben sollte. Ich habe Objekte, für die ich nur weiß, wie man die innere Produktnorm berechnet. Aber mit dem aktuellen (vec)norm ist es mir unklar, ob das Argument p Teil der angenommenen Base-Schnittstelle ist, und daher weiß ich nicht, ob ich das zweite Argument weglassen oder unterstützen soll es prüft dann aber explizit auf p != 2 und gibt einen Fehler aus.

Aber ich sehe das Problem darin, dass es in der Zwischenphase Ihres Vorschlags keine nicht veraltete Möglichkeit gibt, vecnorm(matrix, p!=2) zu tun.

Ich mag auch die Zwischenoption – wir wollen auf jeden Fall einen ordentlichen Abwertungszyklus für die Normen durchlaufen, anstatt sofort eine bahnbrechende Änderung vorzunehmen. (Als Benutzer machen mir die Breaking Changes Angst, aber ich sehe das Beheben von veralteten Inhalten in meinem Code für v1.0 wie eine Investition in sauberen, klaren Code für die Zukunft).

Würden wir tatsächlich innernorm brauchen oder könnten wir jetzt einfach vecnorm verwenden (und vecnorm später zugunsten von norm verwerfen)?

Ich sehe eigentlich keinen möglichen Aufruhr darin, dot einfach durch $# inner zu ersetzen ... Ich denke auch, dass es klar genug ist, dass inneres Produkt eine Verallgemeinerung von Punktprodukten sein soll.

Änderungen könnten in zwei separaten PRs implementiert werden:

1. Ersetzen Sie dot durch inner und geben Sie ihm die verallgemeinerte Bedeutung. Optional können Sie die Infix-Notation \cdot zwischen den Julia-Arrays nach innen zeigen lassen.
2. Weitere Diskussions- und Verfallszyklen rund um die Normvarianten und Terminologie.

Meines Wissens nach könnte PR 1 vor Julia v1.0 zusammengeführt werden. Es bricht nicht.

Das Ersetzen dot durch inner wäre immer noch kaputt, da dot derzeit kein echtes inneres Produkt für Arrays von Arrays ist – Sie würden also die Bedeutung ändern, nicht nur umbenennen. Ich bin dafür, die Bedeutung zu ändern, um ein wahres inneres Produkt zu sein, aber wenn Sie die Bedeutung ändern (sie als das wahre innere Produkt definieren), sehe ich kein Problem darin, es weiterhin als dot zu buchstabieren.

Wir könnten also in 0.7 Folgendes tun:

1. Veralten Sie norm(matrix) in opnorm(matrix) und norm(vector of vectors) in vecnorm .
2. Verwerfen Sie dot([vector of arrays], [vector of arrays]) für einen Aufruf von sum .
3. Sagen Sie, dass vecdot(x,y) und vecnorm(x, p=2) euklidische innere Produkte/Normen sind (für p=2 ), und machen Sie sie rekursiv (was etwas kaputt geht, aber in der Praxis wahrscheinlich keine große Sache ist). .

Dann in 1.0:

1. Verwerfen Sie vecnorm in norm und vecdot in dot . (Nicht sicher, ob dies nach den 1.0-Release-Regeln zulässig ist, @StefanKarpinski?)

(Beachten Sie, dass die Funktion numpy.inner erstaunlicherweise nicht immer ein inneres Produkt ist. Aber die Terminologie von NumPy für inner und dot war schon eine Weile seltsam.)

Die Gründe, warum ich es vorziehe, es weiterhin als dot zu schreiben:

• Es ist schön, eine Infix-Schreibweise zu haben.
• Für Nicht-Mathematiker, die mit gewöhnlichen endlichdimensionalen Vektorräumen arbeiten, ist dot ein bekannterer Name für das euklidische innere Produkt. (Mathematiker werden sich leicht daran gewöhnen, den Namen dot für die Funktion des inneren Produkts auf beliebigen Hilbert-Räumen zu verwenden – „Punktprodukt“ hat für solche Räume keine andere mögliche Bedeutung.)
• Sowohl inner als auch dot zu haben, wäre verwirrend, da sie in einigen Fällen übereinstimmen würden, in anderen aber vielleicht nicht (wenn wir die aktuelle Bedeutung dot beibehalten).
• Außerhalb der linearen Algebra hat inner viele andere mögliche Bedeutungen in der Informatik, und daher ist es etwas lästig, diesen Namen aus Base zu exportieren.

Können Sie Ihren Widerstand gegen den Namen „inner“ erläutern? Ich verstehe immer noch nicht
Deshalb ziehen Sie es vor, gegen eine Terminologie vorzugehen, die jeder in diesem Thread zu haben scheint
zustimmen?

Am Dienstag, 15. Mai 2018, 5:13 Uhr Steven G. Johnson [email protected]
schrieb:

(Beachten Sie, dass die numpy.inner
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
Funktion ist erstaunlicherweise nicht immer ein inneres Produkt.)

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
.

Keiner der Gründe überzeugt mich:

>

• Es ist schön, eine Infix-Variante zu haben.

Ja, und die Infix-Notation kann unabhängig von der Umbenennung in weiterhin vorhanden sein
innen wie oben beschrieben.

>

• Für Nicht-Mathematiker, die mit gewöhnlichen endlichdimensionalen arbeiten
  Vektorräumen ist Punkt ein gebräuchlicherer Name für das euklidische Innere
  Produkt. (Mathematiker werden sich leicht daran gewöhnen, den Namen Punkt für zu verwenden
  die innere Produktfunktion auf beliebigen Hilbert-Räumen - "Punktprodukt" hat keine
  andere mögliche Bedeutung für solche Leerzeichen.)

Dieses Argument ist nicht gut: Lasst uns gewöhnlichen Menschen das Falsche beibringen
Terminologie, weil sie faul sind und kein neues passendes Wort lernen können,
und Mathematiker zwingen, gegen ihren Willen die falsche Terminologie zu verwenden.

>

• Es wäre verwirrend, sowohl inner als auch dot zu haben, da dies der Fall wäre
  stimmen in manchen Fällen überein, in anderen vielleicht nicht (wenn wir den aktuellen Punkt beibehalten
  Bedeutung).

Wir brauchen beides nicht, den weniger allgemeinen Namen loswerden, dem wir zustimmen
Punkt an dieser Stelle.

>

• Außerhalb der linearen Algebra hat das Innere noch viele andere Möglichkeiten
  Bedeutungen in der Informatik, und daher ist es etwas nervig
  exportieren Sie diesen Namen aus Base.

Außerhalb der linearen Algebra finde ich viele Anwendungen für den Punkt. Noch mehr für die
Punkt-Infix-Notation bedeutet ganz andere Dinge.

>

Ich reposte den letzten Beitrag von @juliohm mit fester Formatierung.

Keiner der Gründe überzeugt mich:

Es ist schön, eine Infix-Variante zu haben.

Ja, und die Infix-Notation kann immer noch existieren, unabhängig von der Umbenennung in inner, wie oben erklärt.

Für Nicht-Mathematiker, die mit gewöhnlichen endlichdimensionalen Vektorräumen arbeiten, ist Punkt ein bekannterer Name für das euklidische innere Produkt. (Mathematiker werden sich leicht daran gewöhnen, den Namen Punkt für die Funktion des inneren Produkts auf beliebigen Hilbert-Räumen zu verwenden – „Punktprodukt“ hat für solche Räume keine andere mögliche Bedeutung.)

Dieses Argument ist nicht gut: Bringen wir gewöhnlichen Menschen die falsche Terminologie bei, weil sie faul sind und kein neues passendes Wort lernen können, und zwingen wir Mathematiker, gegen ihren Willen die falsche Terminologie zu verwenden.

Sowohl inner als auch Punkt zu haben, wäre verwirrend, da sie in einigen Fällen zusammenfallen würden, in anderen jedoch möglicherweise nicht (wenn wir die aktuelle Punktbedeutung beibehalten).

Wir brauchen nicht beides, den weniger allgemeinen Namen loswerden, dem wir zustimmen, dass er an dieser Stelle Punkt ist.

Außerhalb der linearen Algebra hat inner viele andere mögliche Bedeutungen in der Informatik, und daher ist es etwas lästig, diesen Namen aus Base zu exportieren.

Außerhalb der linearen Algebra finde ich viele Anwendungen für den Punkt. Noch mehr für die Punkt-Infix-Notation, die ganz andere Dinge bedeutet.

Ja, und die Infix-Notation kann immer noch existieren, unabhängig von der Umbenennung in inner, wie oben erklärt.

Sie können natürlich const ⋅ = inner definieren, aber dann ist Ihre Terminologie inkonsistent. Ich dachte, du magst es nicht, das „Punktprodukt“ als allgemeines inneres Produkt zu verwenden?

Mathematiker zwingen, gegen ihren Willen die falsche Terminologie zu verwenden

Mathematiker wissen, dass Terminologie weder richtig noch falsch ist, sie ist nur konventionell oder unkonventionell (und vielleicht konsistent oder inkonsistent). (Und die meisten Leute beschäftigen sich nicht mit Mathematik, weil sie eine Leidenschaft für die vorgeschriebene Rechtschreibung haben.) Wenn Sie Mathematikern sagen, dass in der Quantenmechanik ein Vektor ein "Zustand" genannt wird, heißt das Adjoint meiner Erfahrung nach "Dolch" und ein dualer Vektor wird "BH" genannt, sie sind erhaben unbekümmert. Ebenso glaube ich nicht, dass ein erfahrener Mathematiker mehr als einmal blinzeln wird, wenn Sie ihm sagen, dass in Julia ein inneres Produkt dot(x,y) oder x ⋅ y geschrieben wird, zumal die Begriffe bereits so verstanden werden Synonyme in vielen Zusammenhängen. (Ich bezweifle, dass Sie einen Mathematiker finden werden, der nicht sofort weiß, dass Sie sich auf ein Skalarprodukt beziehen, wenn Sie sagen: "Nehmen Sie das Skalarprodukt zweier Funktionen in diesem Funktionenraum".)

Andererseits ist meiner Erfahrung nach für Menschen, die keine ausgebildeten Mathematiker sind und nicht mit abstrakten Inner-Product-Räumen in Berührung gekommen sind (dh die Mehrheit der Benutzer), eine ungewohnte Terminologie eher ein Hindernis. "Wie bilde ich ein Skalarprodukt zweier Vektoren in Julia?" wird zu einer FAQ.

Abgesehen von der Wahl der Semantik gibt es hier wirklich keine mathematische Schwierigkeit zu lösen. Die Rechtschreibfrage ist nur eine Frage der Bequemlichkeit und Verwendung.

Außerhalb der linearen Algebra finde ich viele Anwendungen für den Punkt. Noch mehr für die Punkt-Infix-Notation, die ganz andere Dinge bedeutet.

Abgesehen davon, dass Julia und viele andere Programmiersprachen seit Jahren dot haben und es kein Problem war. inner wäre neuer Bruch.

Letztendlich ist die Schreibweise dieser (oder jeder anderen) Funktion im Vergleich zur Semantik und dem Deprecation-Pfad Nebensache, aber ich denke, die Balance kippt zugunsten von dot .

Sie können sicherlich const ⋅ = inner definieren, aber dann ist Ihre Terminologie inkonsistent. Ich dachte, du magst es nicht, das „Punktprodukt“ als allgemeines inneres Produkt zu verwenden?

Ich glaube du hast es immer noch nicht kapiert. Es ist kein Widerspruch, Punkt als inneres Produkt zu bezeichnen. Es ist ein inneres Produkt, ein sehr spezifisches und für viele von uns nutzloses. Nichts weiter als sum(x.*y) .

Wenn der Begriff dot dazu führt, dass Julia die Semantik von inner hat, wird dies eine historische Katastrophe sein, von der ich Ihnen garantieren kann, dass sich viele ärgern werden. Ich kann mir vorstellen, dass Professoren in einem Klassenzimmer Dinge erklären wie: „Weißt du, wir werden jetzt das innere Produkt für unseren Raum definieren, aber in Julia hat jemand (@stevengj) beschlossen, es Punkt zu nennen.“

Ich werde sicherstellen, dass ich diesen Thread für zukünftige Referenzzwecke abbilde, falls dies geschieht.

Du bist der einzige @stevengj , der auf der dot -Terminologie besteht, niemand sonst hat sich dagegen ausgesprochen. Es wäre schön, wenn Sie diese Tatsache noch einmal überdenken könnten, bevor Sie eine Entscheidung treffen.

Es ist ein inneres Produkt, ein sehr spezifisches und für viele von uns nutzloses. Nichts weiter als sum(x.*y).

Wenn Sie der Meinung sind, dass sich "Punktprodukt" nur auf das euklidische innere Produkt in ℝⁿ beziehen kann, sollten Sie nicht const ⋅ = inner definieren, sondern nur ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) definieren.

Sie können nicht beides haben: entweder inner kann ⋅ als Infix-Synonym verwenden (in diesem Fall ist der Infix-Operator in Ihrem Sprachgebrauch sowohl "falsch" als auch die Benennung inkonsistent) oder es hat kein Infix- Synonym (außer in einem Sonderfall).

Ich kann mir vorstellen, dass Professoren in einem Klassenzimmer Dinge erklären wie: „Weißt du, wir werden jetzt das innere Produkt für unseren Raum definieren, aber in Julia hat jemand (@stevengj) beschlossen, es Punkt zu nennen.“

Ha ha, ich bin bereit, diesem imaginären, empörten Professor die Hitze zu nehmen. Im Ernst, Sie müssen sich mehr umsehen, wenn Sie glauben, dass der Begriff „Punktprodukt“ nur in ℝⁿ verwendet wird oder dass Mathematiker empört sind, wenn der Begriff in anderen Hilbert-Räumen verwendet wird.

dies wird eine historische Katastrophe sein

Ernsthaft?

Diese Diskussion scheint über das hinaus zu erodieren, was man als einladendes, zivilisiertes und konstruktives Umfeld bezeichnen könnte . Meinungen und Hintergründe sind unterschiedlich, aber bitte verzichten Sie auf persönliche Angriffe oder Schuldzuweisungen und gehen Sie davon aus, dass alle Parteien in gutem Glauben über ihren Standpunkt diskutieren.

Ich kann mir vorstellen, dass Professoren in einem Klassenzimmer Dinge erklären wie: „Weißt du, wir werden jetzt das innere Produkt für unseren Raum definieren, aber in Julia hat jemand (@stevengj) beschlossen, es Punkt zu nennen.“

Es kann sich hier auch lohnen, darauf hinzuweisen, dass Steven ein Professor _ist_. :zwinkern:

Ich bin auch unschlüssig, dot zugunsten von inner zu entfernen. Der Begriff dot wird ziemlich häufig verwendet, und es wäre überraschend, die Funktion in Julia nicht zu haben, wenn sie in Python und MATLAB vorhanden ist. Ich mag jedoch auch den Begriff inner , da er besser für Nicht-ℝⁿ-Vektorräume und insbesondere für Matrizen geeignet ist.

Übrigens ist mir beim Testen der Methoden in Julia aufgefallen, dass dot nur mit echten Vektoren/Matrizen funktioniert. Ist das beabsichtigt?

Sowohl inner als auch Punkt zu haben, wäre verwirrend, da sie in einigen Fällen zusammenfallen würden, in anderen jedoch möglicherweise nicht (wenn wir die aktuelle Punktbedeutung beibehalten).

@stevengj Wäre es völlig lächerlich, vecdot durch inner zu ersetzen und auch dot zu behalten? Im Moment existiert genau das Problem, das Sie beschreiben, bereits, nur mit vecdot anstelle von inner .

OK... freuen wir uns, was sind die Live-Vorschläge? Sollen sie:

• Nehmen Sie dot als generisches inneres Produkt für eine breitere Palette von Typen an. Es ist bereits korrekt rekursiv für Vektoren von Vektoren, aber wir würden es für Matrizen usw. funktionieren lassen ( @jebej Ich glaube nicht, dass es so nützlich ist, sowohl dot als auch inner zu haben, und als Steven sagt, wir verwenden zumindest umgangssprachlich ziemlich oft dot , um das innere Produkt zu bezeichnen, und das ist nicht falsch - es ist nur eine Terminologie).
• Erwägen Sie, norm etwas konsistenter mit den obigen dot und über alle AbstractArray zu machen, eventuell opnorm für Operatornormen einzuführen (auf AbstractMatrix ) und (in Neu-zu-Alt-Notation) norm(matrix) == vecnorm(matrix) nach geeigneten Abwertungen. An diesem Punkt brauchen wir vielleicht vecdot und vecnorm nicht mehr?

Ist das richtig? Ich denke, diese würden uns zumindest zu einer relativ konsistenten Geschichte der linearen Algebra mit "sauberen" Schnittstellen führen, in der generischer Code dot und norm als zuverlässiges Paar für die Arbeit mit Räumen innerhalb des Produkts verwenden kann unabhängig vom Typ.

@andyferris , ja, ich denke, wenn wir diese Änderung vornehmen, brauchen wir nur dot und norm (die jetzt die rekursiven euklidischen Operationen auf Arrays oder Arrays von Arrays beliebiger Dimensionalität sind für norm definieren wir auch norm(x,p) als p-Norm) und opnorm und haben nicht länger vecdot oder vecnorm .

Beachten Sie, dass die Änderung zu dot eine bahnbrechende Änderung ist, da dot derzeit kein echtes inneres Produkt für Vektoren von Matrizen (#22392) ist, was in #22220 lange diskutiert wurde ( zu diesem Zeitpunkt wurde das Eliminieren vecdot nicht als IIRC angesehen). Dies wurde jedoch in 0.7 eingeführt, sodass kein tatsächlich veröffentlichter Code beschädigt wird. Tatsächlich ist dot in 0.6 bereits das euklidische Punktprodukt auf Arrays mit beliebiger Dimensionalität, etwas zufällig (#22374). Die hier vorgeschlagene Änderung würde das 0.6-Verhalten wiederherstellen und erweitern und norm so ändern, dass es damit konsistent ist.

Eine Frage ist, ob norm(x,p) norm(x[i]) oder norm(x[i],p) rekursiv aufrufen würde. Beides sind potenziell nützliche Verhaltensweisen. Ich tendiere zu Ersterem, weil es allgemeiner ist – x[i] kann ein beliebiger normierter Vektorraum sein, der nur norm definiert, aber nicht die p-Norm. Das rekursive Aufrufen norm ist auch das, was vecnorm jetzt tut, also ist es konsistent mit dem Veralten vecnorm zu norm .

@jebej , dot auf Master und 0.6 funktioniert für mich auf komplexen Arrays: dot([3im],[4im]) gibt zum Beispiel korrekt 12+0im zurück.

Ein weiterer guter Punkt beim Ändern norm(matrix) in die Frobenius-Norm ist, dass es viel billiger ist. Es ist üblich, nur norm(A-B) zu verwenden, um ein Gefühl dafür zu bekommen, wie groß der Unterschied zwischen zwei Matrizen ist, sich aber nicht zu sehr um die spezifische Wahl der Norm zu kümmern, aber viele Benutzer werden die aktuelle Standardeinstellung nicht erkennen norm(matrix) müssen wir die SVD berechnen.

Es ist wunderbar zu sehen, wie sich ein Konsens über mehrere wichtige Punkte bildet! :) (Wenn mir nicht jemand zuvorkommt (bitte tun, wenn Sie Bandbreite haben!) oder ein Alpha-Tag vorher trifft, werde ich die Implementierung der vorliegenden Konsenspunkte nach dem Versand von #26997 versuchen.) Am besten!

Ein weiterer Link für zukünftige Referenzen: https://math.stackexchange.com/a/476742

Um die schlechte Benennung zu veranschaulichen, die hier bewusst übernommen wird, und die schlechte Entscheidung, die von einem einzigen Verstand auferlegt wird. Punkt- und innere Produkte haben unterschiedliche mathematische Eigenschaften. Sie zwingen eine ganze Gemeinschaft gegen das, was in der Mathematikliteratur bekannt ist.

Und für zukünftige Leser, was hätte stattdessen getan werden sollen, wenn wir eine kollektive Entscheidung getroffen hätten:

# 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

Ich denke, wir werden einfach die ersten Menschen im Universum sein, die den Begriff „Punktprodukt“ für ein inneres Produkt für alles andere als ℝⁿ verwenden. Es ist gut, dass ich diesem Thread meinen Willen aufzwingen konnte (hauptsächlich durch Erpressung der anderen Entwickler), um diese Innovation in die Welt zu setzen! Das Skalarprodukt wird nicht länger auf eine bloße „Notation“ verbannt: Stattdessen wird es ein Symbol sein, das ein inneres Produkt bedeutet (wie alle wissen sollten, ist die Zuordnung von Bedeutungen zu Symbolen das Gegenteil von „Notation“).

Sehr gute Entscheidungsfindung :clap: Es war definitiv ein Konsens. Lesen Sie die Kommentare oben, und Sie werden sehen, wie sich alle einig waren. :+1:

Oder vielleicht sollte ich einige Kommentare zitieren, damit ganz klar wird, wie es zu einem Konsens kam:

>

Richtig - vecdot könnte in inner umbenannt werden

von @andyferris

Option 2 (wahrscheinlich besser): Verwenden Sie mathematisch korrektere Namen

innere
Abmessungen
Aber was tun mit der Norm?

von @Jutho

Ich stimme zu, als Alternative zu vecdot könnten wir eine neue Methode inner einführen

von @Jutho

Ich finde auch den Namen vecdot seltsam, tatsächlich wusste ich nicht einmal, dass er existiert, und hatte meine eigene Funktion dafür erstellt ... namens inner.

von @jebej

Und viele mehr...

Menschen können lautstark miteinander debattieren und viele Meinungsverschiedenheiten äußern, aber dennoch zu einem Konsens (wenn auch nicht immer zu Einstimmigkeit) gelangen, indem sie überzeugt werden und die Vor- und Nachteile abwägen. (Ich stimme zu, dass es hier sowohl Vor- als auch Nachteile für jede Option gibt.) Es tut mir leid, dass das Ergebnis, das hier (vorläufig!) zu gelieren scheint, nicht das Ergebnis ist, das Sie bevorzugen, aber ich bin mir nicht sicher, wie Sie denken Ich habe meinen Willen „auferlegt“.

(Natürlich nicht, dass eine endgültige Entscheidung getroffen worden wäre – es gibt noch nicht einmal eine PR, geschweige denn etwas, das zusammengeführt wurde.)

Ich wünschte nur, wir könnten eine Entscheidung treffen, die auf dem Publikum der Sprache basiert. Wenn jemand Julia als Werkzeug auswählt, bin ich sicher, dass die Person zumindest von dem Begriff inner -Produkt gehört hat. Es ist ein ziemlich beliebtes Konzept und alles andere als exotisch. Zu den exotischen Dingen gehören "persistente Homologie", "Quantentheorie", diese sind weniger verbreitet, und ich wäre dagegen, diese Art von Terminologie aufzunehmen.

Schließlich möchte ich nur eine Sprache haben, die die beste Sprache für wissenschaftliches Rechnen, Mathematik usw. ist.

@juliohm , alle Argumente basieren auf den Bedürfnissen dessen, wer wir denken, dass das Publikum ist, und wir alle versuchen, Julia zu einer so guten Sprache wie möglich zu machen. Vernünftige Menschen können über die Terminologie zu unterschiedlichen Schlussfolgerungen kommen, da die Mathematik nicht über die Rechtschreibung entscheidet.

Erstens kann ich, wie oben erwähnt, sicherlich dem aktuellen Vorschlag von @stevengj zustimmen und bei dot als allgemeinem Namen für das innere Produkt bleiben. Außerdem missfällt mir die Art und Weise, wie diese Diskussion geführt wird, und ich möchte auf jeden Fall richtig zitiert werden. @juliohm , das zweite Zitat, das du mir zuschreibst, ist nicht von mir.

Davon abgesehen möchte ich folgendes als Denkanstoß bei der Abwägung von Vor- und Nachteilen erwähnen. Das Folgende sind hauptsächlich Nachteile, aber ich stimme den von @stevengj erwähnten Profis zu. Es könnte leicht separate Anwendungsfälle geben, bei denen dot nur sum(x[i]*y[i] for i ...) bedeutet. In den Fällen, in denen die Infix-Punkt-Notation in der Mathematik am häufigsten verwendet wird, ist dies tatsächlich typischerweise die Bedeutung. Als inneres Produkt ist die Infix-Punktnotation typischerweise (wenn auch sicherlich nicht ausschließlich) für reelle Vektorräume reserviert. Andere Anwendungsfälle umfassen die Aktivierung von Dingen wie σ ⋅ n mit σ einem Vektor von Pauli-Matrizen und n einem Vektor von Skalaren. Dies war einer der Beweggründe für die derzeitige Implementierung dot , wie mir in einem anderen Thread mitgeteilt wurde. Die Tatsache, dass BLAS sich entschieden hat, nur dot für reelle Vektoren zu verwenden und für komplexe Vektoren zwischen dotu und dotc zu unterscheiden, ist ein weiterer zu berücksichtigender Punkt. Leute mit BLAS-Hintergrund könnten verwirrt sein, ob sie mit komplexen Vektoren dot(conj(u),v) oder dot(u,v) berechnen wollen, wenn sie das wahre innere Produkt wollen (dh dotc ). Außerdem könnten sie nach einer Möglichkeit suchen, dotu zu machen, ohne zuerst eine konjugierte Kopie des vorliegenden Vektors zu erstellen.

@Jutho das Zitat gehört dir, dein vollständiger Kommentar wird unten kopiert:

Ich stimme zu, als Alternative zu vecdot könnten wir eine neue Methode inner einführen, aber ich kenne keinen guten Namen, um vecnorm zu "ersetzen". Tatsächlich finde ich vecnorm nicht so schlecht, Vektornorm ist ein gut etablierter und expliziter Begriff für die Operation, die wir wollen.

Auf jeden Fall soll das Zitat zeigen, was sich viele hier (zumindest als erster natürlicher Gedanke) wünschen, wenn wir über dieses Thema nachdenken. Wenn Sie Ihr Verlangen im Laufe der Zeit geändert haben, ist das eine andere Geschichte. Mir selbst würde bei einer Modellierung mit Hilbert-Räumen der Begriff „Punkt“ nie aus dem Kopf gehen. Es fühlt sich unnatürlich an und widerspricht dem, was ich gelernt habe.

@Jutho : Außerdem könnten sie nach einer Möglichkeit suchen, dotu zu tun, ohne zuerst eine konjugierte Kopie des vorliegenden Vektors zu erstellen.

Die Möglichkeit, eine dotu -Funktion zu exportieren, ist hin und wieder aufgetaucht (siehe zB #8300). Ich stimme zu, dass dies manchmal eine nützliche Funktion ist: ein unkonjugiertes euklidisches "inneres Produkt" (nicht mehr wirklich ein inneres Produkt), das eine symmetrische bilineare (nicht sequilineare) Form dotu(x,y) == dotu(y,x) (nicht konjugiert) ist, selbst für komplexe Vektorräume . Aber die Nützlichkeit dieser Operation ist nicht auf ℂⁿ beschränkt – zum Beispiel taucht diese Art von Produkt oft in unendlich dimensionalen Vektorräumen (Funktionen) für Maxwells Gleichungen als Folge der Reziprozität auf (im Wesentlichen: der Maxwell-Operator in typischen verlustbehafteten Materialien ist analog zu einer "komplexsymmetrischen Matrix" - symmetrisch unter dem unkonjugierten "inneren Produkt"). Wenn wir also dot(x,y) als allgemeines euklidisches inneres Produkt definieren (mit konjugiertem ersten Argument), wäre es ganz natürlich, eine dotu(x,y) -Funktion für das nicht konjugierte euklidische Produkt auf einem beliebigen Vektorraum zu definieren wo es Sinn macht. Ich sehe jedoch nicht die Möglichkeit einer dotu Funktion als Argument gegen dot . Wenn Sie mit komplexen Vektorräumen arbeiten, möchten Sie in den meisten Fällen das konjugierte Produkt, daher ist dies das richtige Standardverhalten.

Aber ich stimme zu, dass eine Möglichkeit darin besteht, dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) zu definieren, wie es derzeit in master definiert ist (nicht 0.6), und inner(x,y) als das wahre Skalarprodukt zu definieren. Dies hat den Vorteil, dass beide Funktionen bereitgestellt werden, die beide in bestimmten Fällen nützlich sein können. Allerdings haben wir dann zwei Funktionen, die fast immer zusammenfallen, außer bei Arrays von Matrizen, und ich vermute, es wäre etwas verwirrend zu entscheiden, wann die eine oder die andere verwendet werden soll. Viele Leute würden dot schreiben, wenn sie inner meinten, und es würde für sie in den meisten Fällen gut funktionieren, aber dann würde ihr Code etwas Unerwartetes tun, wenn ihm ein Array von Matrizen übergeben wird. Mein Verdacht ist, dass die Leute in 99 % der Fälle das wahre innere Produkt wollen und die "Summe-of-Product"-Version einem Paket überlassen werden kann, wenn es überhaupt benötigt wird (im Gegensatz zu nur sum ).

@juliohm , ich habe deinen Beitrag falsch gelesen, da ich dachte, die Namen stünden über (statt unter) den jeweiligen Zitaten, daher dachte ich, du hättest mir das Zitat von @jebej zugeschrieben. Ich entschuldige mich dafür.

@stevengj , ich habe sicherlich nicht daran gedacht, dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) als vernünftigen Standardwert zu haben. Im Fall σ ⋅ n ist die komplexe/hermitesche Konjugation des ersten oder zweiten Arguments unnötig. Was ich also sagen wollte, ist, dass in vielen (aber nicht allen) Fällen, in denen die Infix-Punktnotation in wissenschaftlichen Formeln verwendet wird, ihre Bedeutung mit dotu übereinstimmt, dh sum(x[i]*y[i] for i = 1:length(x)) auch ohne Konjugation als inneres Produkt auf reellen Vektorräumen oder als allgemeinere Konstruktion.

Wenn ich also einen Alternativvorschlag machen würde (obwohl ich ihn nicht unbedingt befürworte), hat er zwei Funktionen:

• dot(x,y) = sum(x[i]*y[i] for i...) , was immer noch das richtige innere Produkt für reelle Vektoren ist (was wahrscheinlich der Anwendungsfall von Leuten ist, die mit dem Begriff inneres Produkt weniger oder nicht vertraut sind), aber auch allgemeinere Konstruktionen wie σ ⋅ n zulässt

• inner(x,y) ist das immer gültige innere Produkt mit Konjugation und Rekursion, das von Menschen in allgemeineren und technischen Kontexten verwendet wird.

Ich verteidige dies nicht als eine gute Wahl, um es in der Julia-Sprache zu übernehmen, aber ich denke, dass es in einem Großteil der Literatur so verwendet wird. Wenn ein Infix-Punkt verwendet wird, handelt es sich entweder um ein inneres Produkt im Zusammenhang mit reellen Vektoren oder um eine allgemeinere Konstruktion, bei der es nur um eine Kontraktion geht. Wenn ein allgemeines inneres Produkt auf beliebigen Vektorräumen beabsichtigt ist, wechselt die meiste wissenschaftliche Literatur (aber Sie haben sicherlich Gegenbeispiele gezeigt) zu <u,v> oder <u|v> (wobei in der ersten Notation noch darüber diskutiert wird, was der beiden Argumente wird konjugiert).

Ich könnte mit diesem Vorschlag leben, aber ich könnte genauso gut damit leben, nur dot als allgemeines inneres Produkt zu haben. Letztendlich ist es eine Frage der guten Dokumentation, und ich kann auch nicht glauben, dass jemand über diese "Design" -Wahl stolpern würde.

@Jutho , ich stimme zu, dass es nicht ungewöhnlich ist, dot so zu definieren, dass es nur eine Kontraktion bedeutet. Sicherlich kann man Beispiele in beide Richtungen finden. Zum Beispiel in Programmiersprachen und populären Bibliotheken:

• Unkonjugiert: Numpy dot (und bizarrerweise inner ), Mathematicas Dot , Maxima . , BLAS dotu

• Konjugiert: dot von Matlab, DOT_PRODUCT von Fortran, DotProduct von Maple, VecDot von Petsc, vdot von Numpy, $#$ dotc $#$ von BLAS (beachten Sie, dass das Fehlen von Die Überlastung in Fortran 77 machte es unmöglich, dies dot zu nennen, selbst wenn sie wollten), Eigens Punkt

Einerseits wird das konjugierte innere Produkt normalerweise in Lehrbüchern als "natürliche" Erweiterung des Begriffs "Punktprodukt" auf komplexe Vektoren eingeführt - die unkonjugierte Version ist in gewissem Sinne eine "unnatürliche" Erweiterung, da dies normalerweise nicht der Fall ist was du willst. (Berücksichtigen Sie die Tatsache, dass von den Sprachen, die eine konjugierte dot -Funktion in ihren Standardbibliotheken bereitstellen – Matlab, Fortran, Julia, Maple – nur Maple eine unkonjugierte Variante bietet, was auf einen Mangel an Nachfrage hindeutet.) On the Andererseits ist eine unkonjugierte dotu -Funktion in bestimmten Spezialfällen (von denen ich einige oben erwähnt habe) praktisch (als Ergänzung).

Wenn wir sowohl dot als auch inner haben, vermute ich, dass viele Leute versehentlich dot verwenden werden, wenn sie wirklich wollen, dass ihr Code inner ist generisch. (Ich würde wetten, dass Numpys inner aufgrund eines solchen Unfalls unkonjugiert ist – sie haben es mit echten Arrays im Hinterkopf implementiert und nicht über den komplexen Fall nachgedacht, bis es zu spät war, um es zu ändern, also fügten sie hinzu das ungeschickt benannte vdot .) Wenn wir dagegen dot und (möglicherweise) dotu haben, wird deutlicher, dass dot die Standardauswahl ist und dotu ist die Sonderfallvariante.

(Ich stimme zu, dass ⟨u,v⟩ , ⟨u|v⟩ oder (u,v) gebräuchlichere Notationen für innere Produkte auf beliebigen Hilbert-Räumen sind – sie sind das, was ich normalerweise selbst verwende – aber diese Notationen sind a Nonstarter für Julia. Es gab einige Diskussionen über das Parsen von Unicode-Klammern als Funktions-/Makroaufrufe, z. B. #8934 und #8892, aber es ging nirgendwo hin und dies scheint sich nicht bald zu ändern.)

Deiner Einschätzung stimme ich voll und ganz zu @stevengj .

Ich auch.

Ich vermute, es ist Zeit für einen von uns, mit einer der beiden Implementierungen in einer PR zu spielen und zu sehen, wie es herauskommt.

@Jutho Ich habe das Punktprodukt mit Pauli-Matrizen immer als Abkürzung für eine Kontraktion über Tensoren höherer Ordnung gesehen ... einer der Vektorräume ist real, 3D.

Ich stimme zu, dass ⟨u,v⟩, ⟨u|v⟩ oder (u,v) gebräuchlichere Notationen für innere Produkte auf beliebigen Hilbert-Räumen sind – sie sind das, was ich normalerweise selbst verwende – aber diese Notationen sind für Julia ein Nichtstarter.

Es wäre tatsächlich möglich, ⟨u,v⟩ zum Laufen zu bringen.

@StefanKarpinski : Es wäre tatsächlich möglich, ⟨u,v⟩ zum Laufen zu bringen.

Absolut, und die Unterstützung dieser genauen Notation wurde in #8934 vorgeschlagen, aber es ging nirgendwo hin. (Beachten Sie auch, dass spitze Klammern andere häufige Verwendungen haben, z. B. bezeichnet ⟨u⟩ oft einen Durchschnitt irgendeiner Art.) Es ist nicht brechend und könnte immer noch an einem Punkt hinzugefügt werden, aber es scheint nicht vernünftig zu sein, es in naher Zukunft zu erwarten Begriff. Es ist auch ziemlich langsam, \langle<tab> x, y \rangle<tab> , daher ist es aus Programmiersicht für eine elementare Operation nicht sehr praktisch.

und wir können <> dafür nicht überladen, richtig?

Nein

Ich kann nicht sagen, dass ich jeden Kommentar zu diesem riesigen Thread gelesen habe, aber ich möchte nur ein paar Punkte hervorheben, von denen einige schon früher gemacht wurden:

• Die Unterscheidung zwischen Punkt und Innen erscheint zu pedantisch. In meinen Ohren scheint es tatsächlich unsinnig, weil es im Französischen nur einen Begriff gibt - "Skalarprodukt" - und es schwierig ist, Dinge zu unterscheiden, die für mich den gleichen Namen haben ;-)
• Wenn Sie von numpy kommen und mit komplexen Arrays arbeiten, ist die standardmäßige Konjugation von dot das Beste, was es je gab. Kein Entscheidungspunkt hier, ich wollte nur sagen, wie froh ich bin, dass ich diese conj(dot()) s nicht mehr machen muss!
• Zwei Funktionen zu haben, die in den meisten Fällen das gleiche Verhalten haben, sich aber manchmal unterscheiden, ist schlechtes Design und hat und wird zu Verwirrung führen, da Code, der eine aufrufen sollte, tatsächlich die andere aufruft, einfach weil der Benutzer es nicht besser weiß. Das ist besonders ärgerlich bei norm : Wenn Sie einen Optimierungsalgorithmus programmieren und immer dann stoppen wollen, wenn norm(delta x) < eps , schreiben Sie norm . Aber dann wollen Sie ein Bild oder so etwas optimieren, Sie führen Ihren Code aus und er startet plötzlich in einer nicht zu tötenden (weil BLAS) SVD eines großen Arrays. Das ist nicht akademisch, es hat Probleme in Optim.jl und zweifellos auch in anderen Paketen verursacht. Niemand wird wissen, dass vecnorm existiert, es sei denn, er hat einen bestimmten Grund, danach zu suchen.
• Basierend auf dem vorherigen Punkt ist jede Lösung, die dot und vecdot und norm und vecnorm zusammenführt, gut, auch wenn dadurch ein wenig Flexibilität verloren geht Array-of-Array-Fälle. Für Normen würde ich hinzufügen, dass der Benutzer oft norm aufrufen möchte, um eine Norm zu erhalten, wenn er mit Dingen arbeitet, für die mehrere Normen definiert sind (z. B. Matrizen), ohne sich besonders darum zu kümmern, welche. Induzierte Normen sind aufgrund ihrer rechnerischen Widerspenstigkeit meistens eher von theoretischem als von praktischem Interesse. Sie sind auch spezifisch für die 2D-Array-als-Operator-Interpretation und nicht für die 2D-Array-als-Speicher-Interpretation (ein Bild ist ein 2D-Array, aber es ist kein Operator im sinnvollen Sinne). Es ist gut, die Möglichkeit zu haben, sie zu berechnen, aber sie verdienen es nicht, die Standardeinstellung norm zu sein. Vernünftige, einfache und gut dokumentierte Standardeinstellungen, die erkennbare Alternativen haben, sind besser als versuchter Cleverness (wenn der Benutzer etwas Cleveres tun möchte, lassen Sie ihn es ausdrücklich tun).

Daher +1 für @stevengj

Ja, ich denke, wenn wir diese Änderung vornehmen, brauchen wir nur Punkt und Norm (die jetzt die rekursiven euklidischen Operationen auf Arrays oder Arrays von Arrays beliebiger Dimensionalität sind, obwohl wir für Norm auch norm(x,p) als definieren die p-Norm) und opnorm und haben nicht mehr vecdot oder vecnorm.

Eine "julianischere" Alternative zu norm/opnorm könnte ein Operatortyp sein, der ein 2D-Array umschließen könnte, auf dem norm opnorm ausführt. Dies kann auf der Ebene von Paketen erfolgen (von denen bereits mehrere vorhanden sind).

Ich würde viel lieber opnorm(matrix) als norm(Operator(matrix)) …

Ich werde mich hier aus der Peanut-Galerie einmischen und sagen, dass ich mag, wohin das führt – vecnorm und vecdot haben mich schon immer gestört. Die Notwendigkeit, explizit nach der Operatornorm zu fragen – die mir immer ziemlich spezialisiert erschien – scheint viel vernünftiger zu sein, als nach einer Norm zu fragen, die viel schneller und einfacher zu berechnen ist (z. B. die Frobenius-Norm). Das Schreiben opnorm scheint eine gute Schnittstelle zu sein, um nach der relativ spezialisierten Operatornorm zu fragen.

Ich bin auch der Meinung, dass eine subtile Unterscheidung zwischen dot und inner wahrscheinlich zu Verwirrung und zügellosem Missbrauch führt. Benutzer darüber zu belehren, welche Funktion sie verwenden _sollten_, wenn beide Funktionen tun, was sie wollen und eine von ihnen einfacher ist, funktioniert in der Regel nicht sehr gut. Mein Eindruck ist, dass es in generischem Code relativ selten vorkommt, dass sum(x*y for (x,y) in zip(u,v)) tatsächlich das ist, was Sie wollen, wenn tatsächlich ein echtes inneres Produkt ⟨u,v⟩ existiert. Wenn das wirklich erwünscht ist, ist es ziemlich einfach, klar und effizient (weil Julia das ist, was es ist), einfach so etwas zu schreiben, um es zu berechnen.

Ob die u⋅v -Funktion dot oder inner aufgerufen werden soll, scheint der am wenigsten wichtige Teil von all dem zu sein. Ich bin mir ziemlich sicher, dass keine der beiden Entscheidungen von Historikern als Katastrophe betrachtet werden würde – obwohl die Vorstellung, dass Historiker sich überhaupt darum kümmern würden, sicherlich schmeichelhaft ist. Auf der einen Seite, wenn wir zustimmen, die Bedeutung des „wahren inneren Produkts“ von u⋅v beizubehalten, dann ja, inner ist der korrektere mathematische Begriff. Wenn es andererseits eine Syntax mit einem entsprechenden Funktionsnamen gibt, verwirrt es die Benutzer weniger, wenn der Name mit der Syntax übereinstimmt. Da die Syntax hier einen Punkt verwendet, unterstützt diese Faustregel die Schreibweise dieser Operation als dot . Vielleicht ist dies ein vernünftiger Fall, um const dot = inner zu definieren und beide zu exportieren? Dann können die Leute den Namen verwenden oder erweitern, den sie bevorzugen, da es sich um dasselbe handelt. Wenn jemand einen der beiden Namen für etwas anderes verwenden möchte, kann er dies tun, und der andere Name bleibt mit seiner Standardbedeutung verfügbar. Das würde natürlich drei exportierte Namen für dieselbe Funktion ergeben – dot , inner und ⋅ – was etwas übertrieben erscheint.

Ist es eine Option, das Symbol ⋅ zu entfernen oder durch <u,v> zu ersetzen?

Bemerkungen:

• Es macht die Absicht deutlich. Vergleichen Sie diese beiden Beispiele:

<u,v> * M * x

vs.

u ⋅ v * M * x

• Die <u,v> -Syntax impliziert eine Assoziation: zuerst arbeiten wir mit u und v und dann folgt der Rest des Ausdrucks.

• Wenn sich ein Benutzer die Mühe gemacht hat, <u,v> , ist es sehr unwahrscheinlich, dass er an ein einfaches sum(x[i]*y[i]) hat. Das Symbol ⋅ kann leicht mit den Augen übersprungen werden und hat viele andere Bedeutungen. Insbesondere in der linearen Algebra wird für einen Vektorraum V über einem Körper F das Produkt eines Skalars α ∈ F mit einem Vektor v ∈ V α ⋅ v bezeichnet.

• Das Entfernen oder Ersetzen von ⋅ würde auch das Problem beseitigen, dass mehrere Namen exportiert werden. Man müsste nur inner und <,> für allgemeine innere Produkte exportieren, wobei die Standardimplementierung für Arrays der iterierbaren Summationssemantik entspricht.

• Wenn man ein Skalar-für-Vektor-Produkt wie oben beschrieben für einen Vektorraum V über einem Feld F definieren muss, könnte man dafür die ⋅ -Notation definieren. Der Vektorraum wäre dann mit einer netten kurzen Syntax vollständig definiert und könnte durch weitere Definition <u,v> zu einem Hilbert-Raum erweitert werden.

Wir können definitiv nicht die Syntax <u,v> verwenden; die Syntax, die wir verwenden könnten, ist ⟨u,v⟩ – beachten Sie die Unicode-Klammern, nicht die Kleiner-als- und Größer-als-Zeichen, < und > . Wir haben auch u'v als Syntax für etwas, das entweder ein Punktprodukt oder ein inneres Produkt ist? (Ich bin mir nicht sicher welche...)

Ja, sorry, die Unicode-Version davon. Es wäre sehr klar zu lesen. Es würde auch dieses Problem mit mehreren Namen lösen und ⋅ für andere Zwecke freigeben.

Ich glaube nicht, dass wir ⋅ für andere Zwecke verwenden wollen – das scheint verwirrend zu sein.

Stellen Sie sich nur vor, wie wunderbar es wäre, Code schreiben zu können, der so aussieht:

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

für abstrakte Vektoren (oder Typen) u,v,w,z ∈ V und Skalare α, β ∈ F .

u'v ist ein inneres Produkt (und ein Skalarprodukt, wenn Sie der konjugierten Konvention folgen) nur für 1d-Arrays, nicht zB für Matrizen. (Dies ist ein weiterer Grund, warum es sinnlos ist, Infix-Punkte auf 1d-Arrays zu beschränken, da wir für diesen Fall bereits eine knappe Notation haben.)

Stefan, „richtiger mathematischer Begriff“ ist ein Kategoriefehler – mathematische Korrektheit ist kein Begriff, der sich auf Terminologie/Notation bezieht. (Ersetzen Sie „konventionell“ durch „richtig“. Aber dann wird die Sorge weniger dringend,)

Weitere Anwendungsfälle: https://stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

Und eine formale Ableitung von booleschen inneren Produkten mit der Notation ⟨,⟩ : https://arxiv.org/abs/0902.1290

BEARBEITEN: Link zum Papier behoben

Was halten Sie von dem Syntaxvorschlag für spitze Klammern? Würde es die hier angesprochenen Probleme lösen?

Was genau ist Ihr Vorschlag? Ist es ungefähr so:

1. Verwerfen Sie dot zu inner
2. Veralten Sie u⋅v zu ⟨u,v⟩

Dann gäbe es also keine dot -Funktion und keinen ⋅ -Operator?

Wäre diese Änderung etwas Vernünftiges?

Entschuldigen Sie die Verzögerung bei der Antwort, ich bin auf einer Konferenz mit eingeschränktem Internetzugang.

Und nur der Klarheit und Vollständigkeit halber, was ist hier der Gegenvorschlag? Nichts tun?

Um den Vorschlag noch weiter zu verdeutlichen, gibt es eine semantische Änderung: verallgemeinerte innere Produkte.

Achtung: Wir haben dies jetzt bis zu dem Punkt diskutiert, an dem ein echtes Risiko besteht, dass es nicht in 0,7-Alpha kommt. Das bedeutet nicht, dass es nach der Alpha nicht geändert werden kann, aber danach wird es viel mehr Zurückhaltung geben, Dinge zu ändern.

Ja, ich wünschte, ich hätte die Fähigkeiten, schon vor langer Zeit eine PR eingereicht zu haben. Es übersteigt meine Fähigkeiten, dies zu realisieren, obwohl ich es für ein äußerst wichtiges Feature halte.

Selbst wenn man die Frage der Operatorsyntax außer Acht lässt, gibt es immer noch eine gewisse Komplexität mit Namensschatten und mehrstufigen Ablehnungen für jeden Satz semantischer Konzepte (aktuell dot und vecdot und aktuell norm und vecnorm ).

Für die dot -Seite sieht es so aus, als wäre der gesamte Raum der Optionen (wiederum mit Diskontierungsoperatoren):

I. Brechen Sie stillschweigend dot auf Vektoren von Arrays, indem Sie das Verhalten in 0.7 zu einem inneren Produkt ohne standardmäßiges depwarn ändern (obwohl Sie warnen können, dass das Verhalten geändert wird). Setzen Sie vecdot $ auch in 0.7 auf dot als veraltet.
II. Veralten Sie in 0.7 vecdot für alle Eingaben zu inner .
III. Veralten Sie in 0.7 dot für Vektoren von Arrays zu seiner Definition und dot für andere Eingaben und vecdot für alle Eingaben zu inner .
IV. Veralten Sie in 0.7 sowohl dot als auch vecdot für Vektoren von Arrays entweder für nicht exportierte Funktionen oder für ihre Definitionen und vecdot für alle anderen Eingaben für dot . Fügen Sie in 1.0 dot zu Vektoren von Arrays mit innerer Produktsemantik hinzu.

Für die Normseite gibt es einen gewissen Konsens über einen einzelnen Pfad (in 0.7 veralten Sie norm auf Matrizen auf opnorm und möglicherweise vecnorm auf innernorm ; in 1.0 , fügen Sie norm zu Matrizen mit aktueller vecnorm Semantik hinzu), aber das führt auch zu einem zusätzlichen Namen in 1.0 (entweder vecnorm oder innernorm ); Eine Möglichkeit, dies zu vermeiden, könnte wiederum darin bestehen, vecnorm in 0.7 auf seine Definition oder auf eine nicht exportierte Funktion wie Base.vecnorm statt auf einen exportierten Namen zu verwerfen.

...Ich denke. Hoffe, ich habe die Dinge nicht matschiger gemacht, als sie bereits waren.

Kann jemand, der mit der Codebasis vertraut ist, eine PR für die Änderung einreichen?

Können wir den Normkram, bei dem sich alle einig zu sein scheinen, abspalten und das wenigstens erledigen? Das dot versus inner Bit ist etwas umstrittener, aber lassen wir uns davon nicht den Teil beeinträchtigen, der es nicht ist.

@StefanKarpinski , beachten Sie, dass sie etwas gekoppelt sind: Für Typen, bei denen Sie sowohl ein Punktprodukt (inneres Produkt) als auch eine Norm haben, sollten sie konsistent sein.

Ok, es ist mir egal, in welche Richtung das geht. Wer die Arbeit macht, entscheidet.

Ich hatte eine PR ( #25093 ), um vecdot dazu zu bringen, sich wie ein echtes inneres Produkt zu verhalten (und vecnorm als die entsprechende Norm), indem ich sie rekursiv machte. Dies könnte als Ausgangspunkt dafür nützlich sein, wie die zukünftigen dot und norm aussehen sollten. Leider hat mein Mangel an Git-Fähigkeiten dazu geführt, dass ich diese PR vermasselt habe, also habe ich sie geschlossen, weil ich vorhatte, darauf zurückzukommen, nachdem die neue Iterationssyntax abgeschlossen war.

Da ich aber gerade erst vor ein paar Tagen zum zweiten Mal Vater geworden bin, sind in meinem Kalender aktuell keine „Freizeiten“-Slots vorhanden.

nachdem ich vor wenigen Tagen zum zweiten Mal Vater geworden bin

Herzlichen Glückwunsch Juto! 🎉

Ja, herzlichen Glückwunsch!

Es scheint, als würde sich ein gewisser Konsens über die Idee bilden, sowohl dot als auch inner zu haben, wobei:

1. inner ist ein echtes rekursives inneres Produkt
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) konjugiert oder nicht, und würde sich daher mit dot für Vector{<:Number} oder Vector{<:Real} überschneiden

Bezüglich:

Viele Leute würden einen Punkt schreiben, wenn sie innerlich meinten, und es würde in den meisten Fällen für sie gut funktionieren, aber dann würde ihr Code etwas Unerwartetes tun, wenn ihm ein Array von Matrizen übergeben wird.

Ich glaube nicht, dass das ein Problem wäre. Da dies eine ziemlich ungewöhnliche Operation ist, würde ich erwarten, dass die Leute es zumindest versuchen, um zu sehen, was es tut, und / oder sich die Dokumentation ansehen.

Ich denke, dass das Obige eine großartige Änderung wäre und nicht sehr störend, da die Semantik von dot in den meisten Fällen nicht geändert wird.

Es scheint, als würde sich ein gewisser Konsens über die Idee bilden, sowohl dot als auch inner zu haben

Im Gegenteil, die Diskussion ab https://github.com/JuliaLang/julia/issues/25565#issuecomment -390069503 scheint zu befürworten, das eine oder das andere zu haben, aber nicht beides, wie z. B. in https://github dargelegt. com/JuliaLang/julia/issues/25565#issuecomment -390388230 und gut unterstützt durch Reaktionen.

Vielleicht sollten inner (und auch dot ) rekursive innere/Punkt-/Skalarprodukte sein und das alte Verhalten könnte in Funktionen wie dotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x)) und dotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x)) implementiert werden ? Die Namen dotu und dotc würden mit entsprechenden BLAS-Namen übereinstimmen.

(Ich stimme zu, dass ⟨u,v⟩, ⟨u|v⟩ oder (u,v) gebräuchlichere Notationen für innere Produkte auf beliebigen Hilbert-Räumen sind – sie sind das, was ich normalerweise selbst verwende – aber diese Notationen sind für Julia ein Nichtstarter . Es gab einige Diskussionen über das Parsen von Unicode-Klammern als Funktions-/Makroaufrufe, z. B. #8934 und #8892, aber es ging nirgendwo hin und dies scheint sich nicht bald zu ändern.)

@stevengj , als Sie diesen Absatz selbst zu einem früheren Kommentar hinzugefügt haben, meinten Sie, dass die Syntax ⟨u,v⟩ in der Sprache schwer zu implementieren ist?

Gibt es eine Chance, dass dieses Feature es zu Julia v1.0 schafft? Ich habe so viele Ideen und Verpackungen, die von der Vorstellung allgemeiner innerer Produkte abhängen. Bitte lassen Sie mich wissen, wenn ich meine Erwartungen senken sollte. Sorry für die ständige Erinnerung.

Hast du #27401 nicht gesehen?

Danke @jebej und danke @ranocha , dass du die Führung übernommen hast :heart:

Als Sie diesen Absatz selbst zu einem vorherigen Kommentar hinzugefügt haben, meinten Sie, dass die Syntax ⟨u,v⟩ in der Sprache schwer zu implementieren ist?

Technisch nicht schwer zum Parser hinzuzufügen, aber es hat sich als schwierig erwiesen, einen Konsens darüber zu finden, wie (und ob) benutzerdefinierte Klammern in der Sprache dargestellt werden sollen. Siehe die Diskussion unter #8934, die vor 4 Jahren nirgendwo hinging und seitdem nicht wiederbelebt wurde. (Fügen Sie dies der Tatsache hinzu, dass Menschen in verschiedenen Bereichen dieselben Klammern für viele verschiedene Dinge verwenden, z. B. wird ⟨u⟩ für Ensemble-Mittelwerte in der statistischen Physik verwendet.) Ein weiteres Problem, das in #8892 angesprochen wurde, ist die visuelle Ähnlichkeit vieler verschiedener Unicode Klammern.

Danke @stevengj , ich schätze die Klarstellungen. Ich freue mich schon sehr darauf, dass wir allgemeine Innenprodukte für alle Pakete standardisieren werden. :100: Vielleicht könnte die Notation in spitzen Klammern in einem weiteren Veröffentlichungszyklus in der Zukunft glänzen. Nicht so wichtig, aber ziemlich praktisch, um Code schreiben zu können, der buchstäblich der Mathematik in unseren Veröffentlichungen entspricht.

Wenn ⟨args...⟩ eine gültige Syntax zum Aufrufen des anglebrackets -Operators oder so etwas ist (wie man die Funktion nennt, die diese Syntax aufruft, ist eigentlich etwas knifflig, da wir keinen Präzedenzfall haben), dann könnten die Leute das tun entscheiden sich für eine beliebige Bedeutung für die Syntax.

@StefanKarpinski , das Argument in #8934 war, dass es ein Makro sein sollte. Ich glaube nicht, dass wir uns jemals geeinigt haben.

(Wenn wir in Base entscheiden, dass anglebrackets(a,b) inner(a,b) bedeutet, wird dies die Leute davon abhalten, „sich für die Bedeutung zu entscheiden, die sie wollen“, weil die Entscheidung bereits getroffen wurde.
Es ist natürlich keine schlechte Wahl, aber es kann unnötig sein, dem in Base eine Bedeutung zuzuweisen, solange sie geparst werden.)

Ich erinnere mich nicht an die Details dieser Diskussion, aber das Erstellen eines Makros scheint mir offensichtlich eine schlechte Idee zu sein.

Mit #27401 denke ich, dass wir innere Produkte ernst genommen haben.

Traditionell wird ein Issue erst geschlossen, wenn die entsprechende PR zusammengeführt wird...

Sicher, wir können es offen lassen, denke ich. Wollte es nur vom Triage-Label streichen.

Sollte dies geschlossen werden, da #27401 jetzt zusammengeführt wird?