Nicht vorhandene Werte++
-
Die steckt in einem empty-field
Ich meine, das Konzept, dass irgendwo NA statt einem gültigen Wert steht ist ja eigentlich keines, das ich jetzt erfunden hätte...
-
Und warum muss der vector darüber bescheid wissen?
-
Guck Dir mal
boost.iterator.filter_iteratoran. Villeicht ist das ja was.
-
Klingt für mich so als würdest du Boost.Optional suchen.
-
Ich kann natürlich nicht verlangen, dass da gerade jeder in's Repo schaut, deshalb hier die Erwähnumng: Ich benutze sowohl boost::filter_iterator und optional auch boost::optional (Je nach Policy)
Hätte ich gleich mal erwähnen sollen, mea culpa.
-
ScottZhang schrieb:
Und warum muss der vector darüber bescheid wissen?
Also der vector muss nicht darüber Bescheid wissen, aber der abgelittene (oder komponierte) na_vector soll das Konzept vermitteln, dass man in jedem Element auch ein (wie auch immer geartetes) NA ablegen kann, sowie an eine um die NAs gefilterte Liste oder Sequenz kommt.
-
Und was genau spricht jetzt gegen vector<optional<T>>? Eventuell noch mit einem auto i = filtered_iterator(v.begin()); ?
-
Es spricht nichts so sehr dagegen, dass ich nicht genau für dieses Konstrukt eine äquivalente Policy vorgesehen habe. Allerdings fand ich, könnte das bei den kleinen Datentypen, die ich gerade im Kopf habe, auf ziemliche Speicherverschwendung hinauslaufen, daher habe ich noch eine Policy vorgesehen, die besondere Werte als NA repräsentiert (NAs als liste von Indizes zu repräsentieren ließ sich leider nicht mit den sonstigen Anforderungen an vector aber auch allen anderen containern vereinen).
Also bleibt noch die Frage übrig, warum ich nicht überall auto it = my_filter_iterator( v.begin() ) schreiben möchte... Weil ich finde, dass die Tatsache, dass NAs auftreten, wie ich diese erkenne usw., eine Eigenheit der Datenvorhaltung ist, und sich deshalb der Client-Code nicht mit den Interna befassen sollte oder wie er am besten NA von Nicht-NA unterscheidet. Ich finde daher "auto it = vec.filtered.begin()" oder meinetwegen "auto it = vec.filtered_begin()" ausdrucksstärker und auch einfacher.
Das einzige, was mir ein Dorn im Auge ist im Moment, ist die Tatsache dass der na_vector eben wegen der Ableitung um Arbeit zu sparen 100% kompatibel zu einem gewöhnlichen vector ist. Ich muss diesen na-support aber in eine bestehende Quellcode-Basis retrofitten (damals habe ich gedacht, dass die na-problematik zu ignorieren wäre), da wäre ein inkompatibler Typ pflegeleichter.
Kann man einen benutzerdefinierten Konvertierungs-Operator zu einer Basis-Klasse privat definieren, um den down-cast zu verhindern?
update: nein 
Und eines könnt ihr wissen: Am liebsten käme ich ohne diesen Schmu aus. Dieses ganze NA hier kotzt mich maximal an, weil damit jetzt so ziemlich jeder Algo, der über die Daten läuft klarkommen muss. Bei vielen ists einfach nur das Ersetzen der alten Sequenz durch die gefilterte, aber es entstehen auch viele kompliziertere Problemfälle. Kotzkotzkotz.
-
Mir scheint als bräuchtest du wirklich nur einen Iterator, der die NA's ignoriert.
Man kann sicherlich einen Wrapper pro Container schreiben, der zusätzlich eine valid-Funktion hat, dann ginge vec.filtered.begin() auch. Man muss aber alle Funktionen und Iteratoren neu schreiben (bzw. durchreichen) um den downcast zu verhindern, wobei aber zum Beispiel ein []-Zugriff auf einen Vektor nicht performant implementierbar ist, und schon bei size() muss man sich einige Gedanken machen.
-
Decimad schrieb:
Das einzige, was mir ein Dorn im Auge ist im Moment, ist die Tatsache dass der na_vector eben wegen der Ableitung um Arbeit zu sparen 100% kompatibel zu einem gewöhnlichen vector ist. Ich muss diesen na-support aber in eine bestehende Quellcode-Basis retrofitten (damals habe ich gedacht, dass die na-problematik zu ignorieren wäre), da wäre ein inkompatibler Typ pflegeleichter.
Nicht Ableiten!!
Und eines könnt ihr wissen: Am liebsten käme ich ohne diesen Schmu aus. Dieses ganze NA hier kotzt mich maximal an, weil damit jetzt so ziemlich jeder Algo, der über die Daten läuft klarkommen muss. Bei vielen ists einfach nur das Ersetzen der alten Sequenz durch die gefilterte, aber es entstehen auch viele kompliziertere Problemfälle. Kotzkotzkotz.
Dann brauchst du nur einen filter-Iterator und fertig.
Wenn deine Algos nicht korrekt mit iteratoren bzw. iteratoren ranges arbeiten - sondern auf Containern - musst du einen Adapter um den Container schreiben, der filtered iteratoren anbietet.Am coolsten wäre es natürlich, wenn du direkt mit Ranges arbeiten würdest - das würde dir die ganze Arbeit ersparen. uU kannst du an der Stelle ansetzen - das würde nämlich bei weiteren Änderungen enorm Zeit sparen.
Denn genau aus diesem Grund soll man niemals gegen Container programmieren sondern nur gegen iteratoren.
-
Naja, die Algorithmen benutzen an den allermeisten Stellen bislang bidirektionale oder random-access sequenzen, nicht wirklich Container. Aber ich muss dafür sorgen, dass sie die richtigen (gefiltert oder ungefiltert) Sequenzen erhalten und vor allem müssen manche Algorithmen anders arbeiten. Bei der Index-Verschiebung von Daten per Interpolation beispielsweise müssen die NA's weiter propagieren etc.
Ich habe jetzt einen 1:1 wrapper (-emplace-Krams, weil ich jetzt wirklich keine Lust habe, irgendwelche Makro-Eskapaden zu machen und die Jungs bei Microsoft nicht aus den Puschen kommen) als Drop-In-Replacement für die bisherigen vectors fertig (siehe Repo, falls es interessiert) und lasse mich dann mal überraschen, wie lange die Adaption dauert ;).
-
Moah, als ich eben den boost::zip_iterator ausgepackt habe, ist mir wieder eingefallen, warum ich boost echt nicht mag... Das ist ja alles super elegant, was die da machen, aber einfache Ideen werden da so ein Klump von verschachteltem Typ-Gedöns, dass es keine Freude mehr ist... Hoffentlich wird das alles besser, sobald die C++11-Unterstützung mal allumfassend ist.