|
|
|
|
|
|
|
| | Zitat von Lord-McViper
/e aber ich bin mir fast sicher, dass die Metriken nicht spurfrei sein können...
| |
Da war ich mir auch *fast* sicher. Aber leider nur fast.
Taking advice from cartoon characters is probably a bad idea.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
und ich bin mir mir 99% sicher, dass G nicht entartet ist
|
|
|
|
|
|
|
|
|
|
|
Wie krieg ich es hin, eine container Klasse in Java zu bauen, in der man beliebige Daten zusammen mit einem Schlüssel reinschmeißen und nachher mittels des Schlüssels wieder bekommen kann?
Sowas hier funktioniert zwar
| |
| Code: |
public static class Test {
Map<String, Serializable> mData = new HashMap<String, Serializable>();
public <T> void setData(String key, T value) {
mData.put(key, (Serializable)value);
}
@SuppressWarnings("unchecked")
public <T> T getData(String key) {
return (T)mData.get(key);
}
} |
|
, ich frage mich aber, woher getData den Typen kennt, wenn ich es so aufrufe:
| |
| Code: |
Integer[] testArray = {1,3,2};
t.setData("bla2", testArray);
t.getData("bla2"); |
|
/e: Serializable kann erwartet werden, aber ansonsten will ich echt alles reinschmeißen können; Arrays inklusive.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Oli am 23.03.2013 14:38]
|
|
|
|
|
|
|
|
|
Ich gehe mal davon aus, dass jedes Objekt weiß, von welcher Klasse es ist. Insofern kann man den serialisierten Wert auch wieder hoch casten. Dennoch wundert mich public <T> T getData(String key) , denn T steht ja erst zur Laufzeit fest, je nach dem was raus geholt wird.
Java ist doof. In jeder dynamisch typisierten Programmiersprache wäre das kein Problem.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Kambfhase am 23.03.2013 14:41]
|
|
|
|
|
|
|
|
|
| | Zitat von Kambfhase
Ich gehe mal davon aus, dass jedes Objekt weiß, von welcher Klasse es ist. Insofern kann man den serialisierten Wert auch wieder hoch casten. Dennoch wundert mich public <T> T getData(String key) , denn T steht ja erst zur Laufzeit fest, je nach dem was raus geholt wird.
Java ist doof. In jeder dynamisch typisierten Programmiersprache wäre das kein Problem.
| |
Java ist doof, weil es funktioniert, wie in jeder anderen Sprache auch? 
|
|
|
|
|
|
|
|
|
|
|
|
Das steht in der Tat erst zur Laufzeit fest, vorher kann man nur mit Object rechnen. Deswegen ja auch die SuppressWarnings Annotation, weil der Compiler sonst zumindest darauf hinweisen würde.
|
|
|
|
|
|
|
|
|
|
|
Übrigens: Selbst wenn du ein Objekt castest, bleibt für das Objekt selbst die Klasse erhalten. Denn irgendwoher muss ja die Information über die interne Datenstruktur kommen.
| |
| Code: |
Integer i = 1000;
Number n = (Number) i;
System.out.println(n.getClass());
// class java.lang.Integer
System.out.println((n instanceof Number) ? "Number" : "Integer");
// Number |
|
Damit sollte es dann klar sein und auch nicht weiter verwundern, warum es funktioniert.
|
|
|
|
|
|
|
|
|
|
|
|
Ah, cool. Aber irgendwie auch nicht so transparent.
|
|
|
|
|
|
|
|
|
|
|
Nur am Rande, aber solltest du nicht fordern, dass etwas was in die Map kommt auch Serializable ist?
| |
| Code: |
public <T extends Serializable> void setData(String key, T value) {
mData.put(key, value);
}
|
|
Wenn nein: Warum nicht?
|
|
|
|
|
|
|
|
|
|
|
|
Ist halt RTTI. Damit langsam.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Diesmal kann ich sogar Klugscheißen: Metriken sind auch gar kein Vektorraum, weil schon alleine die Addition keine Inversen liefern könnte... ...bzw. die Skalarmultiplikation nicht immer möglich ist.
Aber danke! 
I find your lack of faith disturbing.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Wraith of Seth am 23.03.2013 16:42]
|
|
|
|
|
|
|
|
|
Kann mir jemand den Schritt von der ersten auf die zweite Zeile erklären? Geht um Markov-Prozesse. Bzw. welche Formel wurde da angewandt? (Ich finde da nix passendes von Bayes)
|
|
|
|
|
|
|
|
|
|
|
Wenn du dir  wegdenkst ist das das normale Bayestheorem:
Die Wahrscheinlichkeit durch die geteilt wird ist in dem Alpha "versteckt" weil es sich wsl ein paar Schritte weiter unten kürzt.
|
|
|
|
|
|
|
|
|
|
|
|
was heißt "wegdenken", dass sind alle evidenzvariablen von 1 bis t die kann ich ja nicht einfach weglassen? und an welcher stelle meinst du bzw. ueberall?
|
|
|
|
|
|
|
|
|
|
|
|
Nicht weglassen, aber nicht davon in der Formel verwirren lassen. Du hast gegeben die Information e_1:t und behältst diese einfach in der Formel für alle Faktoren.
|
|
|
|
|
|
|
|
|
|
|
Ich meine damit dass der Bayes auch gilt wenn du da überall noch nach irgendwas bedingst - in deinem Fall halt . Also:
Außerdem ist auch  .
e/ Woops, sorry.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 23.03.2013 19:21]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Genau mein Stil.  Den Comic häng ich mir morgen auf.
|
|
|
|
|
|
|
|
|
|
|
Ist normalerweise ein Zeichen von wirklich schlechtem Design und vor allem völlig unwartbar.
Kann ich gar nicht genug vor warnen.
|
|
|
|
|
|
|
|
|
|
|
Da gibs keine Standards für, da hört er nicht drauf 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Irdorath
Nicht weglassen, aber nicht davon in der Formel verwirren lassen. Du hast gegeben die Information e_1:t und behältst diese einfach in der Formel für alle Faktoren.
| |
| | Zitat von B0rG*
Ich meine damit dass der Bayes auch gilt wenn du da überall noch nach irgendwas bedingst - in deinem Fall halt . Also:
Außerdem ist auch .
e/ Woops, sorry.
| |
Danke euch!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [smith]
Ist normalerweise ein Zeichen von wirklich schlechtem Design und vor allem völlig unwartbar.
Kann ich gar nicht genug vor warnen.
| |
Wofür ich das gebraucht hätte, es aber sowieso anders gelöst habe, ist ein Container um jegliche Art von Daten in einem Objekt zu speichern, und zwar mit einer möglichst simplen API. Die Container Klasse wäre wohl übersichtlich genug gewesen, um deine Bedenken zu eliminieren.
Und weil ich wissen wollte, wie man sowas elegant löst, habe ich hier gefragt. Aber mit deiner und Gores Hilfe bin ich eine ganze Ecke weiter gekommen, vielen Dank!
/e: Um das Problem etwas genauer zu beschreiben: In Android wollte ich Daten bei einer Bildschirmrotation o.ä. speichern. Da hab ich mir einfach eine Klasse erstellt mit diesen Daten als Members, die ich dann so übernommen habe. Das habe ich 5 mal gemacht, weil ich die Chose in 5 Activities (Screens oder, halt, Situationen) brauche und in jedem Fall habe ich unterschiedliche Daten. Mal ist es (String, Integer, Board[]), mal ist es (Post[], String, String, Integer) usw. Ich hätte gerne eine zentrale Klasse oder API gehabt, die ich instantiieren kann und der ich diese Daten, gerne auch mit Generics, hinzufügen kann. A liebsten per store("key", T var), und sie nachher mittels get("key") wieder bekomme. Ich hätte gedacht, sowas ist mittels Generics irgendwie möglich, aber so richtig wusste ich nicht, wie ich das Object komplett umgehen könnte. Da diese Storage Klasse in jedem Fall aber nur aus zwei kurzen Methoden, store und get, bestehen würde, wäre es meiner Meinung nach übersichtlich genug um nicht unbedingt deinen Comic zu rechtfertigen - auch wenn der, wie gesagt, relativ lustig ist. Und übrigens, es ist potdroid. Da ist eh nichts mehr zu retten. Das ist Code, der wäre selbst Gore peinlich.
Optionen, das zu lösen, wären
a) In jedem Fall eine eigene Klasse verwenden
b) Method Overloading für jeden möglichen Variablentypen (wie würde ich die Dinger dann speichern?)
c) Object! S. oben.
An dieser Stelle will ich nochmal anmerken, dass mir Java irgendwie sehr gut gefällt. Also, die Syntax und so. Es ist bisweilen irgendwie Kuddelmuddel, aber alles in allem deutlich strukturierter als Python oder so. Ich nutze es gerne.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Oli am 23.03.2013 21:58]
|
|
|
|
|
|
|
|
|
Hm, persönliche Erfahrung ist dass man Generics wirklich sehr sehr sparsam und wohlüberlegt einsetzen sollte. Hatte jetzt schon öfter das Problem, dass man sie einfach nicht mehr losgeworden ist wenn sie denn mal drin waren. Im dem Fall oben kann ich es noch einsehen.
Eine weitere sinnvolle Möglichkeit ist es ein Interface dazwischen zu ziehen. Ich weiß jetzt nicht genau ob du die 5 "Speicherobjekte" irgendwie unter einen Hut bekommst, aber ich vermute jetzt einfach mal ganz dreist, dass zu deinen 5 Typen ein 5faches if oder ein switch-case kommt, damit du dann richtig zurück casten kannst.
Und genau sowas ist (99% der Fällen) beschissen und lässt sich mit Polymorphie eleganter lösen, siehe etwa hier. Vielleicht hilft dir das ja als Anregung, dann hättest du, wenn denn anwendbar, immerhin eine Map von key auf InterfaceXY, und musst weder Generics benutzen noch hässlich rumcasten.
Setzt natürlich wie gesagt voraus, dass man ein gemeinsames Interface finden kann.
|
|
|
|
|
|
|
|
|
|
|
Natürlich habe ich auch über Interfaces nachgedacht, aber da hätte ich kaum Code gespart. Meine Intention war es ja, die Klassendefinition gemeinsam zu haben.
Aber naja, wie gesagt, das ist eh alles überflüssig geworden und so Sonderfälle treten gottseidank nicht so häufig auf.
|
|
|
|
|
|
|
|
|
|
|
Ich bau grad MergeSort in Java mit Generics. Es funktioniert auch alles nur haut eclipse diese Warnung an 2 Stellen :
| |
| Code: |
Comparable is a raw type. References to generic type Comparable<T> should be parameterized |
|
Code wo der Fehler kommt :
| |
| Code: |
public static <T extends Comparable<T>> void mergesort(T [] a){ // Mergesort
HIER --> Comparable[] tmp = new Comparable[a.length];
HIER --> mergeSort(a, tmp, 0, a.length - 1);
} |
|
Ich will die nicht mit @SuppressWarnings("unchecked") wegmachen sondern korrekt beheben. Nur komm ich nicht drauf :/
Jemand eine Idee?
|
|
|
|
|
|
|
|
|
|
|
Sollte das nicht Comparable<T> heißen? Das ist ein Array von Elementen, die sich mit dem Typ "T" vergleichen lassen.
|
|
|
|
|
|
|
|
|
|
|
| |
| Code: |
public static <T extends Comparable<T>> void mergesort(T [] a) |
|
ist vorgegeben..
Und das mit dem Array : Wenn ich das auf <T> setze dann funktioniert das nicht weil
| |
| Code: |
Cannot create a generic array of Comparable<T> |
|
..
Ist es in diesem Fall vielleicht einfacher den MergeSort Algo einfach komplett in der gegebenen Methode zu bauen ?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von b4ckspin am 25.03.2013 13:03]
|
|
|
|
|
|
|
|
|
Ah, das Problem ist z.b. hier beschrieben.
Du könntest es dir einfach machen und Mergesort auf Listen implementieren, is eh leichter .
Oder du machst halt einen mehr oder minder bösen Workaround, die sind da erwähnt.
e/ Ooooder du lebst mit dem Warning.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von B0rG* am 25.03.2013 13:21]
|
|
|
|
|
|
| Thema: pOT-lnformatiker, Mathematiker, Physiker XII ( Jetzt mit Primzahlen > 1024 ) |
![AUP [smith] 29.07.2010](./avatare/upload/U1066026--zeratul.png)
