Die Vision eines intelligenten Mediaplayers...

[omata]

Habt ihr eigentlich schon mal darüber nachgedacht was ihr das so schreibt?

Bei einem neuronalen Netz ist eine Lernphase nötig. Wann soll diese durchgeführt werden?
Bei einem Backpropagationnetz wird kontrolliertes Lernen angewendet. Ein Kohonennetz lernt zwar selbst aber wie wollt ihr das dann interpretieren?

Was sollen die Eingangs- und was die Ausgangssynapsen sein?

Siehe auch mein Backpropagation-Netz.

Ein Kohonennetz habe ich auch mal realisiert, aber hier nicht veröffentlicht.

Also Graphen mit gerichteten Kanten ist wohl die bessere Variante.

[Hisoka]

Zitat:

Zitat von omata (Beitrag 1055118)

Habt ihr eigentlich schon mal darüber nachgedacht was ihr das so schreibt?

Bei einem neuronalen Netz ist eine Lernphase nötig. Wann soll diese durchgeführt werden?
Bei einem Backpropagationnetz wird kontrolliertes Lernen angewendet. Ein Kohonennetz lernt zwar selbst aber wie wollt ihr das dann interpretieren?

Was sollen die Eingangs- und was die Ausgangssynapsen sein?

Siehe auch mein Backpropagation-Netz.

Ein Kohonennetz habe ich auch mal realisiert, aber hier nicht veröffentlicht.

Also Graphen mit gerichteten Kanten ist wohl die bessere Variante.

Daher fällt das ganze ja auch unter die Kategorie "Interessante Idee ohne Plan". Also die Idee ein NN für sowas zu nutzen ist ja recht interessant, nur wie man sowas umsetzt ist etwas anderes.

An sich ist ein Problem ja der Anfang. Man hat keine Vergleichsdaten. Also man muss dem Netz erstmal beibringen was zu einander passt( "Like button", "ähnlich button",...) und mit den Ergebnissen könnte man dann ein Netz füttern und dann auf unbekannte Lieder los lassen. Ob das Ganze aber zufriedenstellend funktioniert ist eine andere Sache. Dazu kommen ja noch Sachen wie das zu viel lernen(auswendig lernen), dadurch kann das Ergebnis vielleicht für eine kurze Zeit sehr gut sein aber dann wenn man neue Musik erwirbt kann es total versagen.

Aus der Praxis heraus würde ich daher doch eher einen fertigen Dienst wie Last.fm einbinden. Aber das wäre dann weniger interessant. ;)

[Mithrandir]

Ich hab mal einen kleinen Test gemacht, und ich glaube, ich weiß, warum dieses Feature noch kein Player implementiert hat.

Gehen wir davon aus, dass wir 5000 Lieder auf der Festplatte haben (jahrzehntelange Sammelwut). Baut man für die Initialisierung einen Graphen auf, bei dem jedes Lied mit jedem eine Verknüpfung hat, so kommt man auf die niedliche Datenmenge von insgesamt 25.000.000 Verbindungen. Das bedeutet, dass ich, halte ich diese Menge im Speicher vor, einen Speicherverbrauch von über eine Gigabyte habe. Serialisiere ich meine Liste in eine XML-Datei, ist diese 2,8 Gigabyte groß. Das Hauptproblem ist also weniger die Rechenleistung, sondern eher die riesigen Datenmengen, die anfallen.

Freiwillige bitte zuerst melden, die hier einen Lösungsvorschlag hätten. :)

[Teekeks]

Den Baum nicht im Speicher halten sondern nur dann das passende (aus der DB) laden wenn es gebraucht wird.

[Mithrandir]

Es geht mir auch mehr um die Gesamtdatenmenge. Versuch mal, dem User zu erklären, dass er für seine 5000 Lieder eine Indexdatei mit 3 GB braucht. :mrgreen:

Ich teste das gerade mit SQLite durch... Sollte ja mindestens um den Faktor 10 kleiner werden, wenn ich richtig gerechnet habe. Das ginge ja noch... Ggf. könnte man auch sehen, dass man von vornherein nur die Wahrscheinlichsten Verknüpfungen zulässt, und das Programm dann später eigenständig neue Verknüpfungen hinzufügt...

[Medium]

Nimm statt XML ein ordentliches, natives Format ;). Geht man von sortierten Daten aus, brauchst nu nichtmal mehr Strukturinformationen, und kannst die Bindungsstärken einfach so der Reihe nach auf die Platte streamen. Drückt man die einfach mal in Bytes aus, erscheinen 25MB schon garnicht mehr so fies. Koppel das mit einem einigermaßen sinnvollen read-ahead Algo, und du musst das auch nicht am Stück im Speicher halten.

[jfheins]

Du kannst einen Graphen (fast immer) auch als Matrix darstellen.

In diesem Beispiel also eine 5000x5000 Matrix (wenn jedes Element ein Byte hat, ist das nicht mal allzu groß) und ein Wert stellt dann dar "wie doll" die beiden Lieder (Zeile/Spalte) zusammenhängen. Also z.B. -128 = gar nicht 0=neutral, 127 = quasi identisch
Da diese Zuordnung symmetrsich ist, brauchst du auch nur die Hälfte der Einträge. Wären also 12,5 Megabyte ;)

Und wenn du dann das nächste Lied spielen sollst, gehst du einfach alle Lieder durch, ermittelst die "Ähnlichkeitskomponente" und (nur als Beispiel) nimmst diese als Wahrscheinlichkeit und wählst zufällig eins aus. (Ähnliche Lieder werden wahrscheinlicher ausgewählt als fremde)

[Medium]

Da hatter wahr :). Find's immer schmerzhaft zu sehen, wenn diese XML/DB-Euphorie so simple schlanke Dinge vom Platz der "ersten Einfälle" verdrängt :stupid:

[Sir Rufo]

Es geht noch kleiner wenn man möchte

Stellt man die Beziehungen jetzt auf einer virtuellen Erdkugel dar mit Längen- und Breitengrad, dann brauche ich pro Lied 2 Werte die je nach gewünschter Auflösung nur 5000x2xBewertungsauflösung benötigen
Bei 1Byte sind das gerade mal 10kByte.

(außer acht gelassen haben bislang den Index auf den Titel, der mindestens 2Byte groß sein sollte)

Wären in diesem Falle mit Index also 20kB
Die Matrix-Variante benötigt pro Eintrag 2+2+1 Byte und das genau 4999*5000/2 mal ergibt 59,59MB

Ein weiteren Vorteil wäre die Auswahl der betroffenen Lieder. Einfach alles, was in einem entsprechenden Radius um einen Punkt ist gehört dazu.

Die Errechnung der Koordinaten ist allerdings aufwendiger, weil jedes hinzugefügte Lied alle anderen auf der Kugel wieder verschiebt

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1055157)

Die Errechnung der Koordinaten ist allerdings aufwendiger, weil jedes hinzugefügte Lied alle anderen auf der Kugel wieder verschiebt

Und um das ordentlich zu machen, braucht man evtl. wieder die Beziehungen der Lieder?

Ist interessant, dass alle am Speicherplatz herumrechnen, bevor überhaupt feststeht, wie genau die Daten aussehen, die gespeichert werden sollen/müssen.
Zum Beispiel eignet sich die Matrix besonders dann, wenn es (sehr) viele Kanten gibt. Die Vereinfachung mit "nur die Häfte speichern" geht nur mit ungerichteten Graphen.

Imho braucht man im experimentellem Stadium ja auch nicht mit 5000 Liedern anfangen und dann wären auch größere große Indices zu verkraften.
Bits knausern kann man dann später, wenn man weiß, wie die Daten aussehen.