median

hustbaer

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

hustbaer

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 Computertomographen und dergleichen. Ich wüsste nicht wo man da GIS oder Big-Data brauchen sollte.