Rückgabewerte für analoge Werte in Bindings

[Holy]

Mich würde mal interessieren warum die analogen Werte in den Bindings nicht direkt in die jeweilige Einheit umgerechnet werden? D.h. 1/10 Lux bei z.B. AmbientLight.get_illuminance() statt direkt ein Float in Lux.

Ich denke spätestens in den Bindings hätte es gewisse Vorteile diese Umrechnungen vorzunehmen:

 

1. muss nicht jedes mal durch den Nutzer gemacht werden

2. Änderungen an der Wertigkeit brechen den User-Code, z.B. 1/100 statt 1/10 weil der Sensor genauer ist...

 

Oder gibt es hier gute Gründe für die mir bisher nicht aufgefallen sind? 

[AuronX]

Lustig ist, dass ich heute früh beim Aufstehen darüber nachgedacht habe

 

Also ic denke die Motivation wird es sein, dass du im int oder uint keinen Präzisionsverlust hast, bei float und double könnte sowas passieren.

 

Dennoch fände ich skalierte Werte auch schöner, da ich auch oft ziemlich durcheinander komme. War Humidity jetzt Faktor 10 oder 100? Ich müsste nachschauen.

 

Hier wäre mein Masterplan:

In der Config der Bricks wird je Element eine Spalte für das Scaling eingeführt. So zum Beispiel:

com['packets'].append({
'type': 'function',
'name': ('GetIlluminance', 'get_illuminance'), 
'elements': [('illuminance', 'uint16', 1, 'out', 0.1)],
'doc': ['bm', {
'en':
"""
This is only the doc of the Bricklet...
""",
'de':
"""
"""
}]
})

(neu ist die letzte Spalte bei elements

 

Bindings sind jetzt frei wie sie diese Spalte ausnutzen wollen (bzw. TF darf frei wählen was sie anbieten wollen):

 

public double GetScaledIlluminance()

1.Option: Eine zusätzliche Methode anbieten die skalierte Werte ausgibt (also 20.0 statt 200), die alte bleibt unter altem Namen zusätzlich bestehen wegen der Kompatibilität und Präzision.

 

public double GetRawIlluminance()

2.Option: Die Methode mit altem Namen skaliert per default, aber es gibt noch immer eine "Raw"-version mit voller Präzision und ohne Umrechnung, ähnlich dem Ansatz mit GetAnalogValue().

 

public double GetIlluminanceScaleFactor()

3.Option: Die Bindings bieten wenigstens eine Möglichkeit an zu erfahren mit welchem Scale-Faktor der aktuelle Wert arbeitet.

 

Weiterer Mini-Vorteil: Die bisher nur im Fließtext zu erfahrende Skalierung könnte ebenfalls automatisiert Dokumentiert werden ^^

[The_Real_Black]

@AuronX:

public int GetIlluminance()

public double GetIlluminance(bool scale)

public double GetScaledIlluminance()

{

  return ((double)GetIlluminance() / (double)GetIlluminanceScaleFactor());

}

public int GetIlluminanceScaleFactor()

 

So könnte ich damit leben. Immer die passenden Datentypen wählen...

Aber ist double oder float sinvoll?

Mir sind ints lieber darauf kann ich casten wie ich will. ;-)

[AuronX]

Ints sind schon ziemlich praktisch, obwohl ich das mit dem Parsen nicht verstanden habe ^^

 

Wegen Float vs. Double: Ich denke Float sollte eigentlich überall reichen, da ja die Werte nie in nem Grenzbereich sind (also sehr groß oder sehr viele nachkomma-stellen).

 

Mein double in den Beispielen war jetzt eher Gewohnheit

 

P.S.: Die Variante die nen bool als Parameter kriegt finde ich komisch... wenn ich da false übergebe habe ich ja das schlechte beider Welten: Ich muss Dividieren und halte keinen int in der Hand...

[The_Real_Black]

@AuronX: Parsen habe ich jetzt auch nicht verstanden wenn man dort casten schreibt machts plötzlich mehr Sinn. Hörte mit 'ten auf *close enough* ;-P Man sollte immer nur einen Post nach den anderen schreiben. Frage ist wo man mit den Werten "hin will" die .Net Framework Math Klasse verwendet double und die XNA Framework MathHelper Klasse verwendet float...

[Holy]

Double ist wohl mittlerweile der Standardweg, ausser vielleicht auf embedded. Ein Beispiel für Probleme ist z.B. auf ein Single Precision Float kann man auf Zahlen größer ~16384 nicht mehr 0,0005 aufaddieren (Zeitwert des jeweiligen Samples in Sekunden bei einer Samplingrate von 2kHz). Hat mich mal bei einer kumulativen Zeitinformation für Messwerte erwischt

[AuronX]

Das meinte ich ja mit Grenzbereich

Es gibt halt keine TF-Werte die oberhalb von 16k so viele Nachkommastellen brauchen ^^

 

Aber ich persönlich nehm eigentlich auch immer double.

[borg]

Naja, wenn wir eine Auflösung von 1/10 Lux haben macht es einfach sehr viel Sinn die Werte auch in 1/10 Lux zu übertragen, bringt doch sonst nur nachteile (Präzisionsverlust etc).

 

Anders ist das z.B. bei den Quaternionen beim IMU Brick, die übertragen wir entsprechend aber auch in float.

[AuronX]

Wie gesagt, ich möchte die Übertragung überhaupt nciht ändern, nur das was die Bindings ausgeben. Und das auch eigentlich nur Optional, weil es ja schon sinnvoll ist nicht ins Gleitkomma-Milieu abzurutschen wenn man doch auf maximale Präzision angewiesen ist.

 

Für einen Haufen EInsatzzwecke ist es aber einfach umständlich immer "per Hand" umzurechnen.

[Holy]

Der Präzisionsverlust bei einer Umrechnung innerhalb der Bindings ist denke ich doch zu vernachlässigen, besonders bei 1/10. Wenn ich das richtig sehe ist das Signalrauschen der analogen Werte sowieso meist größer als 1/10.

[borg]

mit float kann ich 0.3 Lux z.B. nicht darstellen, d.h. ich kann z.B. auch nicht testen ob ich bei 1000 Messungen im Schnitt absolut 3 Lux hatte:

 

>>> x = 0
>>> for i in range(1000):
...  x += 3/10.0
... 
>>> x == 300.0
False

 

Da müsste ich jetzt wieder anfangen mit:

if x < 300.0 + epsilon and x > 300.0 - epsilon

 

Warum würde ich das vorziehen wollen?

[Holy]

Ja, Gleitkommazahlen sollte man nie auf Gleichheit prüfen.

Mal unabhängig ob Integer oder Float macht ein solcher Vergleich relativ wenig Sinn da bei der Messung von analogen Signalen immer ein Rauschen vorhanden ist. Damit kannst auch das nicht auf Gleichheit prüfen.

[ThomasKl]

ich wäre auch für die parallele Möglichkeit zur Abfrage der Messgrößen in "Realworld" Einheiten. Wem das zu langsam ist oder zuviel Speicher wegnimmt kann dann immer noch die Bits einzeln zählen.

[AuronX]

@Borg: Deswegen habe ich ja jederzeit das Hintertürchen offen gelassen, dass man int haben kann wenn es auf 100% Präzision ankommt. Aber Holy hat halt recht, dass schon alleine durch die Messungenauigkeit jegliche Vergleiche mit == halbwegs unsinnig sind.

 

Ich behaupte noch immer ganz dreist, dass in 99% der Anwendungsfälle die float-genauigkeit ausreicht und dort eine bequeme Programmierung den Verlust rechtfertigt.

 

Ich finde es btw. auch Klasse, dass ihr euch schon Gedanken gemacht habt, dass eben nicht mal eben fix alles nach Gleitkomma gewandelt wird. Vielerorts wird dieses Problem auch gerne weg-ignoriert.