median



  • DocShoe schrieb:

    Stell dir vor du bist doof und jeder merkt's...

    Da helfen auch keine persönlichen Angriffe.



  • asddasdasasd schrieb:

    Mehr als eine Zeile darf es bei einer solch grundlegenden Funktion nicht brauchen. Alles andere ist absurd.

    ist aber trotzdem so. und die realität zu verweigern ist auch absurd.

    asddasdasasd schrieb:

    Warum sollte ich einen Median selbst implementieren wollen? Ich arbeite im medizinischen Sektor. Einen Commit mit nth element werde ich nie durchgewunken bekommen.

    lol. und einen der ne 3rd party library mit zigtausend zeilen benötigt schon? absurd.

    asddasdasasd schrieb:

    Habe auch schon was in der boost https://www.boost.org/doc/libs/1_67_0/doc/html/accumulators/reference.html#header.boost.accumulators.statistics.median_hpp gefunden. Früher oder später wandert es in den Standard und gut ist.

    ja, wenn das featuer nicht so dringend ist. am besten einfach warten bis das produkt für das du das machen sollst durch ein anderes ersetzt wird. und das könnt ihr dann in java programmieren. weil ja jeder weiss dass die teletubby-sprachen gerade für medizintechnik so viel besser sind.



  • asddasdasasd schrieb:

    DocShoe schrieb:

    Stell dir vor du bist doof und jeder merkt's...

    Da helfen auch keine persönlichen Angriffe.

    Ich habe also herausgelesen: dir fehlt bei C++ die "große" Super-STL oder eine irgendwie geartete erweiterte Standardbibliothek.

    Ja, die gibt es in C++ so nicht. Leider oder nicht leider, je nach dem. Würdest du das wirklich standardisieren wollen? Also im Sinne von ISO? Das wäre doch viel zu viel Aufwand. Und irgendwas kleines zu ändern, würde wieder 3-6 Jahre dauern? Das ergibt keinen Sinn.
    Nicht, dass ich mir manchmal auch ne fertige Klasse für Problem XY wünschen würde.

    Und dass std::string Kodierungsagnostiker ist, hat mit median schon kaum mehr was zu tun. Du kannst aber natürlich immer eine Bibliothek deiner Wahl nehmen wie zum Beispiel QString aus Qt. Wenn du das nicht magst (und ja, utf8 ist schöner&einfacher als utf16), nimm sowas wie CsString. Mir fehlt bei std::string regelmäßig "begins_with" oder "ends_with". Klar, das gibts in boost. Meine einzigen Argumente gegen die freien Funktionen (und das meine ich ernst!) ist 1. fehlende Vervollständigung in der IDE - und 2. kann ich mir einfach nicht merken, wie herum ich die Parameter angeben muss. Das ist bei member-Funktionen eindeutig.

    median(liste von zahlen) ist allerdings keine einfache Operation. Wie hier ja schon gesagt wurde, müsste man 1x nth-Element und einmal max_element aufrufen. Aber diese Operationen würden die Zahlenliste noch umsortieren. Also müsste man die Inputdaten erstmal umkopieren. Oder wie auch immer. Jedenfalls: wenn man schon "mean" berechnet, will man vielleicht den zur Berechnung nötigen Aufwand auch gleich für weitere stat. Eigenschaften nutzen. Daher vermute ich mal, dass mean(const collection) möglicherweise zu unnötigem Mehraufwand in der Berechnung führen würde, insbesondere wenn ich dann auch noch irgendwelche Quantillen berechnen will... Aber naja. Musst du selbst wissen, was die Vor- und Nachteile von C++ in deinem Gebiet sind.


  • Mod

    wob schrieb:

    Ich habe also herausgelesen: dir fehlt bei C++ die "große" Super-STL oder eine irgendwie geartete erweiterte Standardbibliothek.

    Ich möchte noch einmal darauf aufmerksam machen, dass das gefragte Feature bereits in der Standardbibliothek vorhanden war. Und zwar in einer so viel allgemein anwendbareren Form, dass man noch einen Extraschritt gehen musste, um auf die popelige, beschränkte Definition des Medians zu kommen. Der Threadersteller stellte sich bloß absichtlich quer, aus welchen Gründen auch immer.

    Die Situation ist so absurd, als hätte er nach einer Funktion zum Sortieren der ersten 5 Elemente gefragt und nach dem Hinweis auf sort_n einen Schreianfall bekommen, dass es doch primitiv sei, dass man N=5 von Hand angeben müsse.



  • SeppJ schrieb:

    wob schrieb:

    Ich habe also herausgelesen: dir fehlt bei C++ die "große" Super-STL oder eine irgendwie geartete erweiterte Standardbibliothek.

    Ich möchte noch einmal darauf aufmerksam machen, dass das gefragte Feature bereits in der Standardbibliothek vorhanden war. Und zwar in einer so viel allgemein anwendbareren Form, dass man noch einen Extraschritt gehen musste, um auf die popelige, beschränkte Definition des Medians zu kommen.

    Das sehe ich nicht so. nth_element modifiziert den Bereich, der übergeben wird. "Gib mir den Median" ist keine modifizierende Operation.

    Ich würde mal sagen, man importiere numpy in Python und rechne numpy.median([3,111,4,4,5,10]) aus 🙂


  • Mod

    wob schrieb:

    Das sehe ich nicht so. nth_element modifiziert den Bereich, der übergeben wird. "Gib mir den Median" ist keine modifizierende Operation.

    Es modifiziert (was oft ok ist), weil der Medianalgorithmus sonst O(N) im Speicherbedarf ist, was oft inakzeptabel wäre. Wenn man mit O(N) Speicherbedarf ok ist aber absolut keine Modifikation will, kann man ja vorher eine Kopie machen.



  • wob schrieb:

    Ich würde mal sagen, man importiere numpy in Python und rechne numpy.median([3,111,4,4,5,10]) aus 🙂

    Noch einfacher: Da gibts doch schon statistics.median 🤡



  • hustbaer schrieb:

    ist aber trotzdem so. und die realität zu verweigern ist auch absurd.

    Ist eben nicht so, mit Boost ist es tatsächlich nur eine Zeile. Alles andere ist nur für Geeks, die sich auf extrem kompliziertem und unleserlichem Code aufgeilen wollen.

    hustbaer schrieb:

    lol. und einen der ne 3rd party library mit zigtausend zeilen benötigt schon? absurd.

    Boost wird so gut wie überall akzeptiert. Wenn du es selbst ordentlich programmierst, dann endest du bei nicht weniger Zeilen.

    hustbaer schrieb:

    ja, wenn das featuer nicht so dringend ist. am besten einfach warten bis das produkt für das du das machen sollst durch ein anderes ersetzt wird. und das könnt ihr dann in java programmieren. weil ja jeder weiss dass die teletubby-sprachen gerade für medizintechnik so viel besser sind.

    Ist besser als jede noch so kleine Funktion selbst (schlecht) implementieren zu müssen. So etwas wie das Hadoop Ecosystem oder Geoserver wären mit C++ niemals mit vertretbaren Ressourcen zu bewältigen.

    wob schrieb:

    Würdest du das wirklich standardisieren wollen? Also im Sinne von ISO? Das wäre doch viel zu viel Aufwand. Und irgendwas kleines zu ändern, würde wieder 3-6 Jahre dauern? Das ergibt keinen Sinn.
    Nicht, dass ich mir manchmal auch ne fertige Klasse für Problem XY wünschen würde.

    Hier geht es nicht um GUI Funktionen sondern um einen mathematisch simplen Median. Dessen Definition blieb wahrscheinlich nach seiner Einführung unverändert. Egal wie man es dreht. Es bleibt ein Armutszeugnis der Standardisierung, dass selbst solche alltäglichen Funktionen von jedem selbst implementiert werden müssen.

    SeppJ schrieb:

    Ich möchte noch einmal darauf aufmerksam machen, dass das gefragte Feature bereits in der Standardbibliothek vorhanden war. Und zwar in einer so viel allgemein anwendbareren Form, dass man noch einen Extraschritt gehen musste, um auf die popelige, beschränkte Definition des Medians zu kommen. Der Threadersteller stellte sich bloß absichtlich quer, aus welchen Gründen auch immer.

    Die Gründe habe ich dir genannt. Mehr als eine Zeile darf so etwas nicht brauchen. Theoretisch kannst du in C++ mit wenigen Schlüsselwörtern alles erstellen, damit hast du die noch viel allgemeinere Form. Praxisgerecht ist es nicht.

    Das Thema ist für mich erledigt, die richtige Antwort ist:

    #include <boost/accumulators/accumulators.hpp>
    #include <boost/accumulators/statistics/stats.hpp>
    namespace ba = boost::accumulators;
    ba::accumulator_set< uint16_t , ba::stats< ba::tag::median > > container;
    container( 0u );
    container( 255u );
    container( 4095u );
    container( 65535u );
    

    Damit reduziert sich der Median auf eine Zeile und 0 eigenes Herumfrickeln an einer Nebenbaustelle.

    auto med = ba::median( container );
    

    Es ist schön, einfach zu lesen und übersichtlich.



  • Und - kommt auch das richtige heraus?

    In deinem Beispiel kommt hier 4095 raus, nicht (4095+255)/2.



  • wob schrieb:

    Und - kommt auch das richtige heraus?

    In deinem Beispiel kommt hier 4095 raus, nicht (4095+255)/2.

    Bestimmt 🙂 Der gepostete Sourcecode ist ein Ausschnitt und nicht was ich im Programmcode geschrieben habe. Da ist die Aufgabe deutlich aufwändiger.



  • asddasdasasd schrieb:

    hustbaer schrieb:

    ist aber trotzdem so. und die realität zu verweigern ist auch absurd.

    Ist eben nicht so, mit Boost ist es tatsächlich nur eine Zeile.

    Es gibt genug Bereiche wo du Boost niemals genehmigt bekommen wirst. I.A. gehört da Medizintechnik auch dazu.

    asddasdasasd schrieb:

    Alles andere ist nur für Geeks, die sich auf extrem kompliziertem und unleserlichem Code aufgeilen wollen.

    Wenn du glaubst.

    asddasdasasd schrieb:

    hustbaer schrieb:

    lol. und einen der ne 3rd party library mit zigtausend zeilen benötigt schon? absurd.

    Boost wird so gut wie überall akzeptiert.

    S.o.

    asddasdasasd schrieb:

    Wenn du es selbst ordentlich programmierst, dann endest du bei nicht weniger Zeilen.

    Blödsinn. Alleine boost/config.hpp zieht tausende Zeilen Code mit rein. Und wenn du nur die "eigentliche" Implementierung zählst, wird eine eigene Implementierung einfacher, kürzer und übersichtlicher sein. Weil man sie weniger generisch machen wird und weniger optimieren. Beides erhöht die Lesbarkeit enorm und drückt die Fehlerquote.

    asddasdasasd schrieb:

    hustbaer schrieb:

    ja, wenn das featuer nicht so dringend ist. am besten einfach warten bis das produkt für das du das machen sollst durch ein anderes ersetzt wird. und das könnt ihr dann in java programmieren. weil ja jeder weiss dass die teletubby-sprachen gerade für medizintechnik so viel besser sind.

    Ist besser als jede noch so kleine Funktion selbst (schlecht) implementieren zu müssen. So etwas wie das Hadoop Ecosystem oder Geoserver wären mit C++ niemals mit vertretbaren Ressourcen zu bewältigen.

    Ich denke es ging um Medizintechnik?

    asddasdasasd schrieb:

    Das Thema ist für mich erledigt, die richtige Antwort ist:

    #include <boost/accumulators/accumulators.hpp>
    #include <boost/accumulators/statistics/stats.hpp>
    namespace ba = boost::accumulators;
    ba::accumulator_set< uint16_t , ba::stats< ba::tag::median > > container;
    container( 0u );
    container( 255u );
    container( 4095u );
    container( 65535u );
    

    Damit reduziert sich der Median auf eine Zeile und 0 eigenes Herumfrickeln an einer Nebenbaustelle.

    auto med = ba::median( container );
    

    Es ist schön, einfach zu lesen und übersichtlich.

    Wenn du glaubst 🙄



  • hustbaer schrieb:

    Es gibt genug Bereiche wo du Boost niemals genehmigt bekommen wirst. I.A. gehört da Medizintechnik auch dazu.

    Vielleicht nicht die ganze Boost, zumindest hatte ich bei diesem Commit keine Einwände. Ich bin auch nicht der Maintainer, der sicherlich noch ein paar Änderungen einpflegt. Code mit BGL, Quaternion und Geometry Abhängigkeit habe ich auch schonmal commitet. Genau so ist es mit Eigen. Es ist einfach zu fehleranfällig eine stabile numerische Bibliothek zu pflegen. Man sollte sich eher auf seinen eigenen Saustall konzentrieren.

    hustbaer schrieb:

    Blödsinn. Alleine boost/config.hpp zieht tausende Zeilen Code mit rein. Und wenn du nur die "eigentliche" Implementierung zählst, wird eine eigene Implementierung einfacher, kürzer und übersichtlicher sein. Weil man sie weniger generisch machen wird und weniger optimieren. Beides erhöht die Lesbarkeit enorm und drückt die Fehlerquote.

    Von was redest du da? Im Endeffekt geht es darum, ob und wie viel unnötiger Code im Source-Code oder der Binary landet. Im Code landet es nicht, es bleibt in der Boost. In der Binary auch nicht. Diese ist soweit ich weiß nur wenige kbytes gewachsen. Zieh dir nicht Argumente aus der Nase nur um etwas schlecht zu reden was nicht von dir kam.

    hustbaer schrieb:

    Ich denke es ging um Medizintechnik?

    Wieso sollte Geoserver und das Hadoop System nicht in der Medizintechnick verwendet werden. GIS und Big-Data sind Bestandteile vieler Disziplinen.

    hustbaer schrieb:

    Wenn du glaubst 🙄

    Ich lasse mich gern belehren, da ich nicht oft auf C++ losgelassen werde. Zeig uns doch deile Lösung und dann können wir vergleichen 🙂



  • asddasdasasd schrieb:

    Code mit BGL, Quaternion und Geometry Abhängigkeit habe ich auch schonmal commitet. Genau so ist es mit Eigen.

    Wundert mich jetzt etwas. Kannst du 'was zu der Art Software sagen die du da entwickelst? Bei den Medizintechnik-Firmen wo ich mal mit Entwicklern geplaudert habe wäre das auf jeden Fall nicht durchgegangen.

    asddasdasasd schrieb:

    Es ist einfach zu fehleranfällig eine stabile numerische Bibliothek zu pflegen. Man sollte sich eher auf seinen eigenen Saustall konzentrieren.

    Grundsätzlich: ja. Aber glaubst du dass Firmen wie SpaceX das genauso sehen? Damit dann ne Rakete aus der Luft fällt weil ein Boost Maintainer nen schlechten Tag hatte?
    Kommt also immer drauf an was für Software man gerade schreibt würde ich sagen.

    asddasdasasd schrieb:

    hustbaer schrieb:

    Blödsinn. Alleine boost/config.hpp zieht tausende Zeilen Code mit rein. Und wenn du nur die "eigentliche" Implementierung zählst, wird eine eigene Implementierung einfacher, kürzer und übersichtlicher sein. Weil man sie weniger generisch machen wird und weniger optimieren. Beides erhöht die Lesbarkeit enorm und drückt die Fehlerquote.

    Von was redest du da? Im Endeffekt geht es darum, ob und wie viel unnötiger Code im Source-Code oder der Binary landet.

    Nein. Es geht auch darum wie viel Zeilen Code nötig sind damit der ganze Spass funktioniert. Je mehr, desto mehr muss man durchgucken um Fehler zu finden, bzw. desto mehr Zeilen hat man wo bei Anpassungen auch kein Fehler gemacht werden darf. Geh einfach mal File für File durch wie viel das bei selbst einfachen Boost Klassen ist. Dann verstehst du vielleicht was ich meine.

    asddasdasasd schrieb:

    Im Code landet es nicht, es bleibt in der Boost. In der Binary auch nicht. Diese ist soweit ich weiß nur wenige kbytes gewachsen. Zieh dir nicht Argumente aus der Nase nur um etwas schlecht zu reden was nicht von dir kam.

    Ich zieh mir nichts aus der Nase. Du hast nur offenbar noch nie in die Boost reingeguckt. Also in die Implementierung.

    asddasdasasd schrieb:

    hustbaer schrieb:

    Ich denke es ging um Medizintechnik?

    Wieso sollte Geoserver und das Hadoop System nicht in der Medizintechnick verwendet werden. GIS und Big-Data sind Bestandteile vieler Disziplinen.

    Also Medizintechnik sind für mich Sachen wie Com­pu­ter­to­mo­graphen und dergleichen. Ich wüsste nicht wo man da GIS oder Big-Data brauchen sollte.


Anmelden zum Antworten