JavaScript identische Array Inhalte zählen

Sorry, war ein kleiner typo, ist gefixt.

Und würde mich auch interessieren. Finde aber die funktionalen Ansätze i.d.R. einfacher. Und hoffe vor allem, dass die Aufteilungen in Funktionen das ganze einfacher macht.
 
Bei deinem finalen Codebeispiel entfallen Werte:

rating
[src=javascript]Object { gut: 4, schlecht: 1, mittel: 1 }[/src]

rating2
[src=javascript]Object { gut: 1, schlecht: 0, mittel: 0 }[/src]

Da fehlen die ganzen "okay"s aus Rating2.
 
Immer noch fehlerhaft. Außerdem finde ich deine Lösung sehr komplex, jemand der sich erst mal in deinen Code einarbeiten muss hat es viel schwerer als jemand der sich in meinen Code einarbeiten muss. Nur meine Meinung dazu.
 
Jetzt aber. @CPU ich gebe zu bedenken, dass von der Funktionalität meine Variante viel weiter geht.

Funktional identisch zu deinem ist bei mir schon die sehr frühe Variante:

[src=javascript]
function getNoOfElementsWithRating(arr, field, rating) {
return arr.filter(elem => elem[field] === rating).length;
}

const noOfRatingGood = getNoOfElementsWithRating(arr, "rating", "gut");
const noOfRatingBad = getNoOfElementsWithRating(arr, "rating", "schlecht");
const noOfRating2Good = getNoOfElementsWithRating(arr, "rating2", "gut");
const noOfRating2Bad = getNoOfElementsWithRating(arr, "rating2", "schlecht");
[/src]

Die folgenden Anpassungen erlauben dann dynamisch zusätzliche ratings. Und ein filter ist jetzt auch nicht schwieriger zu erklären ein als switch, aber viel klarer.
 
Jetzt passt es. Das einzige was ich mich nun frage, "wie oft" iterierst du über das Array/Object.

Irgendwie scheint dieses ganze Set erstellen / Map Funktion und Filter eine sehr komplexe Laufzeit zu haben?
 
Also 'filter', 'reduce' und 'map' (die klassisch funktionalen Funktionen) sind linear. Beim Rest weiß ich nicht, wie JavaScript das implementiert.
 
Die asymptotische Laufzeit ist O(a * n) wobei a die Anzahl an möglichen ratings und n die länge des Arrays ist. Eine Lösung mit O👎 wäre denkbar, aber vermutlich nicht wesentlich vorteilhaft, da a relativ klein sein dürfte.

In konstanten Faktoren gehe ich das Array sehr oft durch. Es ist jedoch ein beliebtes Irrtum anzunehmen, dass es effizienter ist ein Array 1-mal durchzugehen und jeweils 2 Dinge zu machen statt das Array 2-mal durchzugehen und nur jeweils eine Sache zu machen. Deswegen gilt auch O(n + n) = O👎. Tatsächlich bietet dies alles sehr viel Spielraum zur Optimierung auf allen Ebenen der VM und der CPU.
Wie sich das dann konkret z.B. mit Sprungvorhersage und so verhält müsste man im Detail untersuchen.

Allgemein ist nicht davon besonders inperformant, und funktionale Programmierung mit map/reduce nicht langsamer als iterative Programmierung mit klassische loops.
Was skalierung angeht bietet map/reduce im "grossen" sogar signifikante Vorteile, da es konzeptionell gut parallelisierbar ist.
 
Für die Leute, die es interessiert:

Die schnellste Lösung ist von MingsPing, dann kommt meine eigene und das Schlusslicht ist Krutius' Lösung.

Möchte jetzt auch mal was Schlaues sagen, so wie Krutius:
E=mc^2
a^2 + b^2 = c^2
 
Zuletzt bearbeitet:
:p nicht Äpfel mit Birnen vergleichen. Deine Lösung macht weniger. Nimmst du nur den Teil von meiner sieht das wieder anders aus:



Die von MingsPing ist tatsächlich besser, braucht aber underscore. Tauscht also Payload gegen Performance.
 
Zuletzt bearbeitet:
Sag mal, hast du eine Konzentrationsschwäche? Dein Link funktioniert mal wieder nicht. :D
Aber ja, ich habe es korrigiert mit der kurzen Version von dir und tatsächlich war dann meine Lösung die Langsamste.

Aber deine Lösung macht ja dann auch nicht mehr das was es soll.
 
Und wenn ihr jetzt noch die 'console.log's rausnehmt, bekommt ihr ein realistischeres Ergebnis :-P

Edit
Aber da ihr euch (wir uns?) ja so niedlich battlet (battlt?!), wie wäre es mal wieder mit einer ngb-Programmier-Challenge? Das hatten wir paar mal schon und war immer sehr nett!
 
Zuletzt bearbeitet:
Nein, aber irgendwie kapier ich nicht wann JSBEN sichert...

Also, hier mal ohne console.log und bei mir in der simplen Variante:
Und in der grossen, dafür mit mehr Daten. Denn Konstante Faktoren sind natürlich bei wenig Daten heftig:

alles nicht so einfach...
 
Du bist mein Mann! Darauf hätt' ich BOCK!

Wer ist hier Moderator, damit ich das mal zum Rollen bringe?

EDIT

Ah hab's, drfuture ist hier zuständig. Ich hab ihn angeschrieben. :)
 
Zuletzt bearbeitet:
Gibt es schon längst: https://ngb.to/threads/38556-ngb-to-Coders-auf-quot-Codewars-quot



Für die Leute, die es interessiert:

Die schnellste Lösung ist von MingsPing, dann kommt meine eigene und das Schlusslicht ist Krutius' Lösung.

Möchte jetzt auch mal was Schlaues sagen, so wie Krutius:
E=mc^2
a^2 + b^2 = c^2

Verstehe diese toxische Einstellung kein bisschen. Die Lösung von Krutius hat mega viel beigetragen, gut erklärt und schön gelöst. Aber wenn du dich sportlich battlen willst sei auf codewars willkommen ;-).
 
Das ist wirklich einmal wieder ein schöner Thread geworden! Bisschen ge-battle, bisschen wer hat den eleganteren Code, aber vor allem ein paar interessante Erklärungen und Ansätze dabei.

Am Ende soll halt immer klar sein, dass es hier nicht drum geht, wer der oder die Bessere ist und Fehler in anderen Lösungen zu suchen, sondern gemeinsam elegante Lösungen zu finden und dabei bisschen Spaß und Beef zu haben.

Für mich war der Performancevergleich zwischen Native und jQuery besonders interessant. Denke viel zu selten daran, weil ich wenige performance-kritische Projekte habe. Ich werd auch sicher weiterhin jQuery alleine wegen der Leserlichkeit/Gemütlichkeit verwenden, aber dort, wo es nicht viel mehr Aufwand/Code bedeutet, sicher auf native Funktionen zurückgreifen.
Und es gibt ja auch ist.

Am Ende sind noch ein paar nette Vergleiche.
 
Zurück
Oben