[Webserver] %-Werte sauber darstellen

[Uwe!]

Hallo,

ich bin grad noch am basteln einiger Webseiten, die auch %-Werte (in meinem Fall Heizungs-Stellgrößen) darstellen sollen.

In meinem jugendlichen Leichtsinn hab ich die "Roh-" Werte durch 2.55 dividiert, das sollte rein rechnersisch bei max. 255 eigentlich die gewünschten 100,0 ergeben. Es werden bei 255 aber 99,92 angezeigt.

Die Forumssuche hat ergeben "Divison durch 2.549". Das ergibt eigentlich 100,039... Hab jetzt noch nicht ausprobiert, was der Webserver dann wirklich anzeigt, aber ich versteh ja schon gar nicht, warum die Division mit 2,55 nicht funktioniert? So falsch kann er doch nicht rechnen?

Hilfe!

[enertegus]

? So falsch kann er doch nicht rechnen?

Die Darstellung 16 Bit hat da ihre Tücken. Sowie etwa beim Taschenrechner nach 10x Wurzel und 10x Quadrieren nicht mehr das Gleiche steht.

[macflei]

versuch mal das makro unten ......

[Uwe!]

Die Darstellung 16 Bit hat da ihre Tücken.

ja, das ist mir wohlbekannt. Aber das 255/2.55=99.92 ist für mich jetzt mehr geschätzt als gerechnet. Ein "99.9999" oder "100.0001" hätte mich nicht verwundert.
Hilft es die 255 und die 2.55 zuvor in f32 zu konvertieren?
Oder eben so wie das Makro von macflei am Ende das Ergebnis als u08 darstellen.
Dass ich aber den Divisor so zu sagen per trial and error ermitteln muss, um zum gewünschten Ergebnis zu kommen, finde ich schon etwas befremdlich. DAS kann zumindest jeder neuere (also ich sag mal nicht älter als 20 Jahre) Taschenrechner besser.

[enertegus]

ja, das ist mir wohlbekannt. Aber das 255/2.55=99.92 ist für mich jetzt mehr geschätzt als gerechnet.

Hm, das ist aber so. GGf. einen Verbesserungsvorschlag an die KNX einreichen. .

Hilft es die 255 und die 2.55 zuvor in f32 zu konvertieren?

Yep, dann ist das gut. Habe ich irgendwo auch hier schon mal beschrieben.

[Uwe!]

Hm, das ist aber so. GGf. einen Verbesserungsvorschlag an die KNX einreichen.

Was hat die KNX damit jetzt zu tun? Ich hab's jetzt nicht überprüft, aber auch 16 bit sollten doch für etwas mehr Genauigkeit reichen???

Yep, dann ist das gut. Habe ich irgendwo auch hier schon mal beschrieben.

ok, das ging dann leider an mir vorbei, ist ja aber eine gangbare Lösung!

PS: mein € 3,99 Taschenrechner schaftt das Wurzel/Quadrieren übrigens 7mal ohen Abweichung, erst bei 8mal hab ich 0,2 Differenz;-)

[enertegus]

Was hat die KNX damit jetzt zu tun? Ich hab's jetzt nicht überprüft, aber auch 16 bit sollten doch für etwas mehr Genauigkeit reichen???

Mit 16 Bit kann man nur einen Ganzahlbereich von 2^16 darstellen. Wenn man nun mit f16 einen höheren Bereich abdecken will, mit Kommadarstellung, so geht was verloren. Überlegmal, deckste noch einen Exponent mit 4 Bit ab, so bleiben mit vorzeichen gerade mal 12 Bit . Vielleicht mal bei Interesse googlen.

PS: mein € 3,99 Taschenrechner schaftt das Wurzel/Quadrieren übrigens 7mal ohen Abweichung, erst bei 8mal hab ich 0,2 Differenz;-)

Der EibPC rechnet intern sogar mit 32 Bit, aber beim Konvertieren geht das wieder verloren.
Dein Taschenrechner wird auch mit 32 Bit rechnen - auch wenn oft nur ein 4 Bit-er verbaut ist.

[fuchs]

versuch mal das makro unten ......

Hast du für die anderen Knöpfe, Status und Stop, auch Makros?

[MarkusL]

Hallo macfli,

da ist noch ein Minitippfehler bei der Ankleide "Temperaturen".

An den anderen Macros wäre ich auch interessiert...obwohl bekomme ich auch alles selber hin und macht noch Spass...dauert nur etwas das es ja auch noch andere Baustellen gibt.

Grüße mal deine Tochter ;-)

Gruß,
Markus

[macflei]

vorab.
der hersteller hat wirklich einen tollen und netten support

Hast du für die anderen Knöpfe, Status und Stop, auch Makros?

die zwangsstellung der heizung soll mir nur angezeigt werden. von daher habe dort folgendes verwendet.......

[Webserver]
line $Heizung OG Philipp$
pbutton(Heizt_Mit_OG_PhilippID)[TEMPERATURE]$Heizt mit:$ pbutton(HZ_Zwang_PhilID)[STOP]$Heizung Zwang$
 
 
[EibPC]
if "Zwang OG Kind1-2/3/0" then {
pdisplay(HZ_Zwang_PhilID,settime(),STOP,DARKRED,GREEN,Page_Heizung_GesamtID)
} else {
pdisplay(HZ_Zwang_PhilID,settime(),STOP,INACTIVE,GREY,Page_Heizung_GesamtID)
} endif

Hallo macfli,

da ist noch ein Minitippfehler bei der Ankleide "Temperaturen".
.................
Grüße mal deine Tochter ;-)

Gruß,
Markus

oha.... stimmt. [featurewunsch] implementierung des duden

die kleine wird übrigens übermorgen 3. ich glaube ich werde aber bei ihren freunden und freundinnen nicht so richtig punkten können, wenn ich denen auf der geburtstagsfeier statt einem clown und ponny den eibpc und die visu präsentiere......... achwas.....clown und ponny sind gestrichen und es gibt einen crashkurs zum thema validierungsschema.
obwohl ....... dieser wird sich aber wahrscheinlich auch eher in minimalen grenzen halten. und was mach ich dann, nach den 30 sek.?

[Uwe!]

Überlegmal, deckste noch einen Exponent mit 4 Bit ab, so bleiben mit vorzeichen gerade mal 12 Bit .

Das ist mir soweit schon klar. Ich hab mir sogar mal die Mühe gemacht und versucht das händisch nachzurechnen. Die 255 und auch die 2.55 lassen sich mit 16bit exakt abbilden, auch die 100.0. Insofern sollte ein richtiges Ergebnsi möglich sein. Was ich nicht nachvollzogen hab ist die Division selbst. Und ich hab auch keine Normalisierung gemacht.

Der EibPC rechnet intern sogar mit 32 Bit, aber beim Konvertieren geht das wieder verloren.

Das versteh ich nun wieder nicht. Dann sollt es aber auch egal sein, ob ich mit f16-Werten rechne (jedenfalls bei einer einfachen Division) oder mit f32-Werten und dann das Ergebnis wieder in f16 konvertiere, oder?

Michael, nicht dass das falsch rüber kommt: Ich wär der letzte, der den EibPC schlecht reden wollte! Das Teil ist und bleibt genial!
Aber ich suche gern mit nach Verbesserungen. Und momentan bin ich noch nicht überzeugt, dass man mit 16bit nciht genauer rechnen kann. Wenn ich noch mal ne ruhige Stunde habe, mach ich noch die Normalisierung und die eigentlcihe Divison. Mich interessiert das einfach!

[Bodo]

Aber ich suche gern mit nach Verbesserungen. Und momentan bin ich noch nicht überzeugt, dass man mit 16bit nciht genauer rechnen kann. Wenn ich noch mal ne ruhige Stunde habe, mach ich noch die Normalisierung und die eigentlcihe Divison. Mich interessiert das einfach!

Hoi

Es liegt an der Datenpunkt Definition vom KNX. Werte die auf den Bus gehen sollen müssen nach dem Schema das der KNX vorgibt konvertiert werden.

Und dabei gehen massig Zwischenwerte verloren.

Intern rechnet der EibPC korrekt.

Oder liege ich da falsch?

[Uwe!]

Oder liege ich da falsch?

Vom Grundsatz liegst Du da schon richtig! Nur die besagten 255, 2.55 und 100 lassen sich ohne Verlust codieren. Drum fehlt mir hier noch ein "aha-Erlebnis", warum dann bei der Berechnung trotzdem was verloren gehen soll.
Die KNX-Float-16bit-Definition sieht 1bit Vorzeichen, 4bit Exponent und 11bit Mantisse vor. Abgebildet wird es als 0,01 x Vorzeichen x 2^Exponent x Mantisse

[salixer]

Das liegt am Pentium-Bug: Pentium-FDIV-Bug

[MarkusL]

...interessant was ihr so alles in euer kleines Zauberkistchen eingebaut habt: Respekt!! ;-)

Gruß,
Markus