|
|
|
|
|
|
|
Ist eigentlich gar nicht so ein schlechter Vergleich. Du fickst dich beim Prototype ändern auch mit Libraries und Abhängigkeiten in's Knie. Änderungen an den Builtins gelten dann für jedes Arrayobjekt in der ganzen Runtimeumgebung, in der das gemacht wird. Das ist natürlich süss, so lange man das in seiner kleinen Umgebung macht, aber stell dir mal vor was passiert, wenn das jede Library tun würde. Klar, kann man jetzt auch als konzeptionelle Schwäche auslegen, aber tun sollte man es halt einfach gar nicht  Alles zerstörst du dann natürlich, wenn du builtins neu definierst und nicht nur ausbaust.
| |
| Code: |
> Array.prototype.filter = null;
null
> const a = [1, 2, 3];
undefined
> a.filter(x => x > 1);
TypeError: a.filter is not a function
|
|
¤: Javascript ist eine tolle Sprache
¤: Ach ja, und der Node REPL gibt gleich ganz den Geist auf wenn man das hier macht:
| |
| Code: |
> global.Array = null
null
TypeError: Array is not a constructor
at process.nextTick (internal/process/next_tick.js:259:16)
at onwrite (_stream_writable.js:444:15)
at WriteStream.Socket._writeGeneric (net.js:782:5)
at WriteStream.Socket._write (net.js:792:8)
at doWrite (_stream_writable.js:388:12)
at writeOrBuffer (_stream_writable.js:374:5)
at WriteStream.Writable.write (_stream_writable.js:291:11)
at WriteStream.Socket.write (net.js:710:40)
at finish (repl.js:537:27)
at REPLServer.defaultEval (repl.js:281:5)
internal/process/next_tick.js:259
args = new Array(arguments.length - 1);
^
TypeError: Array is not a constructor
at process.nextTick (internal/process/next_tick.js:259:16)
at onwrite (_stream_writable.js:444:15)
at WriteStream.Socket._writeGeneric (net.js:782:5)
at WriteStream.Socket._write (net.js:792:8)
at doWrite (_stream_writable.js:388:12)
at writeOrBuffer (_stream_writable.js:374:5)
at WriteStream.Writable.write (_stream_writable.js:291:11)
at WriteStream.Socket.write (net.js:710:40)
at Domain.debugDomainError (repl.js:304:24)
at Domain.emit (events.js:159:13)
|
|
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von SwissBushIndian am 27.11.2017 19:03]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab mal ne blöde Frage bezüglich Klassenvererbung (in C#). Grundsätzlich ist mir klar wie es funktioniert aber in der Praxis bin ich unsicher wann man es nutzen sollte.
Beispiel: Ich habe irgendeine beliebige Klasse und die Klasse hat z.B. ein Property das das Objekt beschreibt, z.B. ob eine Resource Lokal oder auf einem Share liegt. Ich hatte sowas bisher meist über ein Property gelöst.
Man könnte das natürlich auch über eine vererbte Klasse machen (z.B. "Klasse-Lokal", "Klasse-Share"). Die Frage ist, wann macht das Sinn? Ich hätte jetzt gesagt sobald, abhängig von diesem Property, auch bestimmte Methoden oder neue/andere Propeties nötig werden. Da das in meinen Fällen seltenst nötig war, habe ich auch entsprechend wenig mit Vererbung gearbeitet. Hat da jemand Empfehlungen an der Hand?
|
|
|
|
|
|
|
|
|
|
|
Composition > Inheritance. Das haben inzwischen auch recht viele Sprachdesigner eingesehen und bieten die klassische Vererbung nichtmal mehr als Sprachfeature an.
Gerade im von dir geschilderten Fall (Daten sharen) macht Vererbung keinen Sinn. Meine Faustregel allgemin ist 1) so gut wie möglich vermeiden 2) muss ich dieses Objekt wirklich polymorphisch ersetzen können (und reicht mir dafür nicht ein Interface)? Klar gibt es für Vererbung gute Anwendungsfälle, aber oft wird Vererbung falsch eingesetzt. Einzelklassenvererbung wie man sie aus Java/C#/etc kennt ist hauptsächlich da um Objekte in einer klaren Hierarchie erweitern zu können, und nicht um sie mit einzelnen Fähigkeiten auszustatten (wie zum Beispiel mit Mixins in Scala oder ähnlichen Konzepten).
Als kleiner Einstieg: Composition vs Inheritance, Wikipedia.
¤: Das klingt jetzt wiedermal viel zu schwarz/weiss. Vererbung ist eine super Sache, aber wie mit jeder Medizin macht es die Dosis. Kleine Vererbungshierarchien die übersichtlich bleiben und einem Zweck in der Domain dienen machen total Sinn. Gigantische Abhängigkeitsbäume wie man sie aus der Javawelt kennt sind einfach völlig übertrieben. Problematisch wird es vor allem dann, wenn du nicht über die ganze Vererbungshierarchie die Kontrolle hast. Dann bist du immer direkt an den Parent gekoppelt. Jede Änderung in der Hierarchie führt auch zu änderungen an deinem Code (und zum Testen ist es dann meistens auch ziemlich kacke).
¤: Und falls du ein konkretes Beispiel hast, können wir das gerne hier anschauen 
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von SwissBushIndian am 28.11.2017 13:26]
|
|
|
|
|
|
|
|
|
Danke für die gute Antwort! Der Link ist schon mal wichtig für mich. Ich versuche gerade mich mit den Design-Prinzipien vertraut zu machen. Ich hab bisher immer ungelernt und nach Gefühl gemacht und merke, dass ich da einiges an Basics nachholen muss.
Mein konkretes Beispiel ist ein Klasse "Macro" (ein Text, der eine Art Script-Befehlskette darstellt) die ein paar Properties enthält (Befehl-Strings, Save, Load, ChangeDate, etc) und eben aus unterschiedlichen Quellen stammen kann (File, Datenbank). Ich habe es bisher so gelöst, dass es nur eine Klasse gab, die ein Property "Typ" hatte und ich dort nach Herkunft unterschieden habe.
Die Klasse hat den Typ lediglich bei Save/Load benutzt weil da unterschieden werden musste wie/wo das gemacht wird. Hier ist denke ich beides irgendwie valide, sowohl diese Lösung als auch eine Lösung mit 2 Klassen.
Ich werde mich wohl von meinem "es gibt immer einen besten Weg"-Denken verabschieden müssen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Viva la Bluescreen
Ich werde mich wohl von meinem "es gibt immer einen besten Weg"-Denken verabschieden müssen.
| |
Den besten Weg gibt es sowieso nie. Das ist immer ein abwägen aus verschiedensten Kriterien. Für mich am wichtigsten sind: Lohnt sich der Aufwand? Passt es in das Projekt / die Domäne? Macht das überhaupt Sinn?
| | Zitat von Viva la Bluescreen
Mein konkretes Beispiel ist ein Klasse "Macro" (ein Text, der eine Art Script-Befehlskette darstellt) die ein paar Properties enthält (Befehl-Strings, Save, Load, ChangeDate, etc) und eben aus unterschiedlichen Quellen stammen kann (File, Datenbank). Ich habe es bisher so gelöst, dass es nur eine Klasse gab, die ein Property "Typ" hatte und ich dort nach Herkunft unterschieden habe.
Die Klasse hat den Typ lediglich bei Save/Load benutzt weil da unterschieden werden musste wie/wo das gemacht wird. Hier ist denke ich beides irgendwie valide, sowohl diese Lösung als auch eine Lösung mit 2 Klassen.
| |
Ich verstehe das so (oder so ähnlich halt, ich ziehe das einfach mal frei aus dem Text): Der eigentliche Makro bleibt gleich, also der Befehl und die anderen Properties. Unterscheiden tut sich das ganze durch den Store wo es herkommt. Du hast also Makro als Superklasse und DbMakro und FileMakro.
| |
| Code: |
+-------+
| Macro |
+-------+
+-----------^ ^--------+
| |
| |
+--+----+ +----+----+
|DbMacro| |FileMacro|
+-------+ +---------+
|
|
Ich zeige hier jetzt eine Möglicheit, wie ich das spontan angehen würde. Makro an sich beschreibt ja nur einen Makro, also würde ich diese Klasse komplett auf die Datenhaltung über Makros behalten. Nun würde ich zwei Interfaces definieren, eines heisst MacroStorer, das andere MacroLoader. Wenn nun weiterhin Makro selber speichern und laden können soll, dann kann man das über Behaviours lösen, welche man dem Makro gibt. So kann man dem Makro sagen wie er sich speichern soll, ohne dass sich die Makroklasse ändern muss um auf verschiedene Speicherorte zu schreiben.
| |
| Code: |
+--------------+ +-------+ +---------------+
| LoadBehavior +------------+ Makro +---------+ StoreBehavior |
+--------------+ +-------+ +---------------+
+--------^ ^-----+ +-----^ ^--------+
| | | |
| | | |
| | | |
| | | |
+-----+------+ +-----+-----+ +-----+------+ +----+-----+
| FileLoader | | DbLoader | | FileStorer | | DbStorer |
+------------+ +-----------+ +------------+ +----------+
|
|
Save und Load im Makro ruft nun einfach die jeweilige Funktion des hinterlegten Loader und Storers auf. Wieso Store und Load trennen? Naja, man kann jetzt aus der Db Laden und in ein File schreiben. Als nächsten Schritt kann man zum Beispiel anstatt einen Storer zu haben eine Collection und dann sowohl in ein File wie auch in eine Db speichern usw.
So kann man die Abhängigkeit zwischen Representation (Makro )und dem Speicherverhelten (Loader/Storer) schön auftrennen.
Das ist jetzt natürlich nur eine Möglichkeit, du kannst jetzt das auch umdrehen und einfach verschiedene Storer / Loader haben die einen Makro nehmen und dann lesen und schreiben. Falls das zu abstrakt ist, kann ich das gerne auch noch in Code eintippseln, aber dazu komme ich erst heute Abend.
¤: Obligatorischer Wikipedialink.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 28.11.2017 16:12]
|
|
|
|
|
|
|
|
|
Tausend Dank dafür. Du hast meinen Fall genau richtig verstanden und ich glaube ich kann den Gedanken auch nachvollziehen. Code-Beispiel brauche ich erstmal nicht.
In meinem konkreten Fall ist das "Produkt" jetzt mit nur einer Klasse fertig und der Aufwand das umzubauen steht wohl nicht dafür, aber nachdem ich gerade überlege wie ich mein nächstes Bastel-Projekte aufziehe, werde ich das dort versuchen zu berücksichtigen.
Der tatsächliche Vorteil dieser Strategie ist ja eigentlich eine etwas aufgeräumtere Struktur und die Chance schon an Hand des Objekts zu bestimmte Dinge ableiten zu können ohne immer mit "if-Statements" zu fragen "Kommst aus der Datenbank/dem Filesystem". Und natürlich die Anpassbarkeit wenn man was in der Basisklasse ändert bzw. Austauschbarkeit von sowas wie dem Loader.
Schon irgendwie cool!
|
|
|
|
|
|
|
|
|
|
|
|
Genau. Erfüllt auch schöner das single responsibility principle, weil deine Klasse jetzt tatsächlich einen Makro darstellt, und andere Aufgaben delegiert. Ich bin ja ehrlichgesagt nicht der allergrösste Patternfan. Das liegt nicht so sehr an den Patterns selbst, sondern daran, dass viele Hardliner die pragmatische Sichtweise schon lange verloren haben. Nicht jedes Pattern löst ein Problem, und nicht jedes Problem braucht einen Pattern. In deinem Fall passt das jetzt natürlich wie Arsch auf Eimer, aber man muss auch nicht um jeden Preis für jede Aufgabe einen Pattern suchen, nur weil das schonmal jemand vorgekaut hat. Ist quasi wieder das gleiche wie beim "optimale Lösung".
|
|
|
|
|
|
|
|
|
|
|
Ich beantworte mir die Frage nach gutem Design über den Aufwand, die Klasse unter Test zu stellen.
Damit kann man dann auch gut argumentieren für oder gegen ein weiteres Pattern.
|
|
|
|
|
|
|
|
|
|
|
|
Ja, das kommt dazu. In der Regel ist aber alles was die Kopplung reduziert gut für die Testbarkeit, ob Pattern oder nicht.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich kämpfe gerade ein bisschen mit Pandas und HDF5. Mein Code sieht so aus:
| |
| Code: |
import pandas as pd
import numpy as np
store = pd.HDFStore('test.h5')
columns = ['sensor_a', 'sensor_b', 'sensor_c']
testdata = []
for i in range(100):
testdata.append({
'subject_id': np.random.randint(low=1, high=10),
'recording_id': np.random.randint(low=1, high=10),
'data': pd.DataFrame(np.random.rand(100, len(columns)), columns=columns, dtype=np.float64)
})
testdataframe = pd.DataFrame(testdata)
store.put('testdata', testdataframe, format='table') |
|
Der Gedanke war, dass ich für jede meiner Aufnahmen einen Datensatz in meinem übergeordneten DataFrame anlege, dass ich später die Daten nach Bedarf datenbankähnlich abrufen kann ("gib mir Aufnahme 2-5 von Subject 7").
Beim Speichern kriege ich aber den Fehler "TypeError: Cannot serialize the column [data] because its data contents are [mixed] object dtype". Anscheinend kann ich also keine DataFrames in DataFrames packen und speichern.
Ist das überhaupt eine sinnvolle Vorgehensweise?
Die aktuelle Übergangslösung verwendet eine Datenbank mit den Daten, und die ID von jedem Datensatz entspricht dem Dateinamen. Ich könnte das natürlich im Interface abstrahieren, aber habe eigentlich keine Lust auf tausende Dateien, lieber eine große Datenbank. Nur wie mache ich das in HDF5?
|
|
|
|
|
|
|
|
|
|
|
|
Die Lösung ist Tidy Data. Im Kurzen: Ein großer Dataframe mit vielen Spalten. Du kannst das dann noch etwas hübscher machen mit MultiIndizes. Man könnte das im Grunde in mehrere DataFrames aufteilen und die Tatsache ausnützen, dass HDF5 hierarchisch ist, aber wenn du nicht wirklich viele Daten hast würde ich mir das sparen, zumindest für den Anfang.
|
|
|
|
|
|
|
|
|
|
|
|
Yo, das Paper sollte man eigentlich jedem, der irgendwie mit Messdaten zu tun hat oder irgendwann mal zu tun haben könnte, schon auf der Uni an den Kopf nageln, so sehr ich R verachte. Ist einfach guter Stil.
|
|
|
|
|
|
|
|
|
|
|
Pah, wenn man so fragwürdige Wissenschaft betreibt, in der die Daten "aufgeräumt" werden müssen vielleicht.
|
|
|
|
|
|
|
|
|
|
|
|
Wenn man die Daten selbst generiert kann man natürlich auch einfach den Code aufheben.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
Pah, wenn man so fragwürdige Wissenschaft betreibt, in der die Daten "aufgeräumt" werden müssen vielleicht.
| |
...dafür hat man doch die Hardwaretrigger, nicht?
@Oli: Ist das das Paper, in dem Wheeler "it from bit" erfand? Gerade keine Zeit das genauer nachzuverfolgen.
Du gewinn den Nobelpreis und halt den Schnabel
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Wraith of Seth am 01.12.2017 4:45]
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
@Oli: Ist das das Paper, in dem Wheeler "it from bit" erfand? Gerade keine Zeit das genauer nachzuverfolgen.
Du gewinn den Nobelpreis und halt den Schnabel
| |
Ja.
|
|
|
|
|
|
|
|
|
|
|
Ok, bist du darüber darauf gestoßen? Den Link habe ich von meinem Freund bekommen, der an (relativistischer) Quanteninformation arbeitet - aber selbst noch nicht zum Lesen gekommen. Als ich ihm dann deinen Wheelerlink zukommen ließ (ungelesen  ), wies er mich darauf hin, dass in dem Artikel darauf verwiesen wird (ungeprüft von mir ).
Spoken like a true virgin! - Damn straight!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 01.12.2017 11:51]
|
|
|
|
|
|
|
|
|
|
Ich glaube ich habe es auf Hacker News gefunden. Dann festgestellt, dass ich jeden Satz mindestens 5 Minuten anstarren musste, bis sich mir der Sinn erschließt und deshalb gedacht, naja, bestimmt steht WoS drauf.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
| | Zitat von RichterSkala
Pah, wenn man so fragwürdige Wissenschaft betreibt, in der die Daten "aufgeräumt" werden müssen vielleicht.
| |
...dafür hat man doch die Hardwaretrigger, nicht?
| |
Ausgelöst im Pikosekundenbereich! Real time triggering! 80 % higher trigger rates than competitors! Correlated triggers! Analyse von bis zu 65535 unabhängigen Auslösungen durch segmentierten Speicher! Simplified trigger setup through patented touch triggering!
|
|
|
|
|
|
|
|
|
|
Spoiler - markieren, um zu lesen:
It's important to note that while the effective size of the dog can be arbitrarily large, it's not any more of a good dog than the two original dogs.
|
|
|
|
|
|
|
|
|
|
|
|
Bieten data.frames in R große Vorteile für die Geschwindigkeit? Ich erzeuge meine eigenen Daten, aktuell hab ich alles als lists of lists realisiert. Könnte man bestimmt leicht zu data.frames umbauen, aber lohnt sich das? Dieser Link sieht eher nach dem Gegenteil aus.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Ich glaube ich habe es auf Hacker News gefunden. Dann festgestellt, dass ich jeden Satz mindestens 5 Minuten anstarren musste, bis sich mir der Sinn erschließt und deshalb gedacht, naja, bestimmt steht WoS drauf.
| |
Irgendwie war ich nicht informationstheoretisch genügend interessiert, um mich näher mit "it for bit" zu beschäftigen - jenseits davon, dass es ein typischer "Wheelerismus" ist. (Diesmal aber tatsächlich halbwegs jugendfrei. Keine schwarzen Löcher oder No-Hair-Theoreme [Schwarze Löcher haben keine Haare. {Sic!}])
____________________
Ich langweile mich gerade zu Tode mit den ersten page proofs, die komplett auf meinem Manuskript beruhen. Und gleichzeitig bin ich irgendwie angenehm überrascht, wie lesbar das Ding ist, auch nach einigen Monaten des Nichtlesens. Ich scheine keinen absoluten, literarischen Bockmist gebaut zu heben. Jetzt muss ich nur noch peak procrastination überwinden, und die fiese Matrixalgebra durchziehen, die nötig ist, weil wir damals(tm) einen trivialen Fehler eingebaut haben. Glücklicherweise nur in einem "Übrigens, man könnte das auch SO schreiben", d.h. völlig irrelevant. Sollte ich meine Prokrastination nicht überwinden, müssen halt zwei Zeilen dran glauben.*achselzuck*
¤DIT:
Copy Editors sind echt sauhohle Nüsse.
KENNEN SIE DIESEN PINGUIN?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 03.12.2017 7:11]
|
|
|
|
|
|
|
|
Wenn ich einen Artikel von JSTOR habe, gibt es eine Möglichkeit, zu checken, ob eine DOI existiert?
It is written with the zeal of a missionary preaching to cannibals.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, aber nichts damit gefunden. Und ich bin mir auch nicht ganz sicher, dass ich verstehe, wie ich ihm beibringe, nach zusammengesetzten Begriffen zu suchen. "bla blubb" liefert zumindest zuviel...
Time to add a few more Galileo's, darlings.
|
|
|
|
|
|
|
|
|
|
|
|
Hat jemand schon einmal mit monotonen/isotonischen Regressionen gearbeitet? Ich suche bei meinem Hiwijob Regressoren, die als Output eine einzige Funktion haben, die dann auch stetig-differenzierbar ist. Die Suche danach gestaltet sich nicht so ganz einfach, deshalb hier die Frage. Interessant wären Support Vector Regressoren oder neuronale Netze, im Prinzip aber alles, solange die Output-Funktion nachher überall differenzierbar ist.
|
|
|
|
|
|
|
|
|
|
|
Soll die Funktion monoton (steigend oder fallend) sein? Was meinst du mit isoton? Wenn es dir um Stetigkeit oder Differenzierbarkeit geht, dann kannst du das mit den meisten Modellen haben. Neuronale Netze mit (sagen wir mal) Sigmoiden als Aktivierung sind zum Beispiel unendlich oft stetig differenzierbar.
Könntest du genauer formulieren was du willst oder was dein Problem ist?
e/ Ah, das scheint ein Begriff aus der Statistik zu sein. Kannst du das für mich übersetzen?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 05.12.2017 18:31]
|
|
|
|
|
|
|
|
|
|
"ordnungserhaltend" = "monoton steigend"
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XXI ( X-Ray-Edition ) |
