Dichte aufsplitten

[chgad]

Die Dichte ist momentan ein Text Feld, welches eigentlich eine Zahlenspanne angibt. Dies soll nun im Rahmen des Dynamischen Bestimmungs helfer aufgespalten werden:

• [ ] erstelle FloatField max_density

• [ ] erstelle FloatField min_density

[mimischi]

Django unterstützt unter PostgreSQL auch RangeField: https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#range-fields

[chgad]

Gut, habe ich übersehen. Werde mir das Anschauen. Wichtig wäre herauszufinden ob es die Standart Filtermethode erlaubt einen Wert zu in dieser Range zu filter.

Beispiel: Sei die Dichte von Objekt X in der range 1,6 - 2,9. Findet die .filter() methode dieses Objekt wenn man nach density=1,8 filtert ?

[chgad]

Es taucht das Problem auf, dass einige Datenbankeinträge der jetzigen Dichte nicht immer eine tatsächliche "Range" darstellen. D.h. esmuss überlegt werden wie man in einem FloatRangeFiled auch einzelne Zahlen einstellen kann, ohne die Vorhandene Filterdynamik zu zerstören.

[mimischi]

Wie lösen andere das Problem? In anderen Systemen ist das ja sicherlich schon aufgetaucht und wurde gelöst.

Woran ich gerade denke: Start- und Endwert gleichsetzen, wodurch man eben zwei Werte für die Range hat. Im UI kann man diesen Fall dann eben gesondert darstellen.

[chgad]

Man könnte dieses Problem umgehen, indem man folgendes benutzt:

man wähle = sys.folat_info.epsilon was einem den Kleinsten unterschied zwischen 2 Float Zahlen im system gibt. Man erstelle dann die Felder in denen bis jetzt nur eine Zahl eingetragen ist, so das new_densitiy = (x, x+ sys.float_info.epsilon) erstellt wird. Somit erstellt man Formal eine NumericRange welche folgendes Intervall darstellt : [x,x+) , diese ist allerdings formal nur mit dem Element x gefüllt.

Das Problem an dieser herangehensweise isst, dass man hier die Eingabe durch ein Admin Panel beeinflussen müsste, da es niemandem zuzumuten ist, diesen x+) Term hinzuschreiben. Somit kann diese Lösung nur durch nachbearbeitung ausgeführt werden.

[chgad]

Das Probelm am gleichsetzen von Start und Endwertis , dass es mathematisch korrekt zu einer leeren Menge bzw. Range führt. Somit ist diese herangehensweise nicht möglich.

[mimischi]

Aber wird das vielleicht nicht einfach von PostgreSQL unterstützt? Also wenn es eben technisch realisierbar ist, warum nicht so nutzen?

Somit kann diese Lösung nur durch nachbearbeitung ausgeführt werden.

Man könnte ein Widget schreiben, welches die Anzeige übernimmt und automatisch x+epsilon setzt.

[chgad]

Es gibt eine leere Menge !? Was soll das nützen wenn man zumbeispiel den Wert 4 hat und nun (4.0,4.0) also FloatRangeField Eintrag wählt wird dies zu [4.0,4.0) ==> . Bzw. um im Pythonstil zu belibem NumericalRange(empty=True)

[sheepyhollow]

Komisch, dass der Thread bei mir unterm Radar durchgeflogen ist... dabei habe ich diesmal wirklich die Reminder bekommen... komisch...

Was die leere Menge angeht könnte man noch eine pragmatische Lösung wählen: dann gibt es eben per Definition kein Mineral mit nur einem Eintrag, sondern ein ± 0,1 auf den Wert und dann haben wir einen max und ein min-Wert. Ich vermute überdies, des es nahezu kein Mineral gibt, das immer und in jedem Fall einen exakten Dichtewert hat. Die wird in der Realität immer schwanken.

Und tatsächlich - ich habe eben mal stichprobenartig nach Literaturwerten für Minerale mit nur einer Angabe gesucht und in jedem Fall eine Range gefunden! Also kein Stress mit den Einzelwerten bei der Dichte. Die Ressourcen, die 80 Einträge von Hand zu bearbeiten, haben wir - das würden Jacques und/oder Kerstin machen können und das scheint wegen fälligen Korrekturen (Dichte 0??) ohnehin nötig zu sein.

Bei der Mohshärte allerdings haben wir das gleiche Problem - und da geben die Ressourcen (mineralienatlas / wikipedia) oft nur einen Wert an. Also gleiches Problem, anderes Feld.

[chgad]

Aufgrund dessen, würde ich für die Dichte, um die es hier geht, folgendes Vorgehen vorschlagen :

Ich gehe im folgenden davon aus das ALLE Dichten das Format (bsp.) "4,25-7,98" haben. Wenn dies nämlich der Fall ist, kann ich die Umstellung von einem string auf ein Arrayfiled, simplerweise, mit einer Datamigration erschlagen.

Dazu müssen, bevor die neuen Änderungen live gehen, alle "Artefakt" Dichten (Dichten bei denen nur eine Zahl steht) überarbeitet worden sein. Das ersparrt ein komplettes neu eintragen.

Ich kann selbstverständlich eine Liste aller Mineralien erstellen bei denen "Artefakt" Dichten auftreten.

[chgad]

Erldeigt in #279, bzw. #280