[wiregate] - √ - Auch noch ne Bestellfrage :)

[greentux]

Bevor ich zuschlage und hoffe, noch ein paar Aktionssensoren zu bekommen, eine Frage:
Hat jemand Erfahrung, wie ich den Berker Sensoreinsatz in die Jung AS500 / Acreation bekomme? Vermutlich gehts ganz einfach - wenn man weiß wie.
Mailtechnisch hatte ich bisher keinen Erfolg Jahreswechselferien oder arg beschäftigt mit Aktionssensoren verpacken...

Grüße

[makki]

Sorry, ich erinnere mich dunkel an die Frage, finde aber nichtmal das eMail

JUNG - Artikel/Produkt-Katalog -> Rahmen -> Zwischenrahmen A 590 Z (weiss) oder "A 590 Z WW" (alpinweiss)
+ den äusseren Rahmen von Jung
Gibts aber offenbar nur in weiss für dieses Programm.

+ Die (mittlere) Abdeckung (Zentralplatte) von Berker

7594 04 03 edelstahl, lackiert
7594 04 04 hellbronze, lackiert
7594 04 02 weiß, glänzend
7594 04 85 anthrazit, matt
7594 04 83 alu, matt
7594 04 89 polarweiß, matt/samt
7594 04 09 polarweiß, glänzend

"Berker-Weiss"=

weiss - ähnlich RAL 1013
polarweiss - ähnlich RAL 9010

Weil weiss != weiss..
Für die Unterscheidung glänzend/matt muss man Ausnahmsweise nicht Eli gelernt haben

Makki

[greentux]

Merci. Die ganzen Jung Sachen stehen hier noch. Polarweiss ist also in etwa Alpinweiss... Muß ich nur noch schauen, ob es glänzt. Prima, dann werd ich mal die Multisensoren bestellen.

[greentux]

Hat so seine Rundungsprobleme der Shop Wie Excel früher...

[makki]

Runden..

Ja, das hatten wir schon ein paarmal festgestellt; irgendwo im Magento-Team muss sich ein ganz fieser Cobol-Programmierer verstecken, der in guter Buchhalter-Manie einfach mal gerne alle Fliesskommazahlen hart abschneidet.. Haben wir uns aber aufgrund der immensen Beträge von +-1ct/Bestellung (und der Tatsache, das es dort wirklich *überall* drinsteht) bisher ein Ei drauf gepellt. Wir reden von 2-5 EUR im Jahr für oder gegen uns..

Weil richtig: an der Floating-point-präzision von 32Bit CPU's oder PHP liegts bestimmt nicht

Makki

[Chris M.]

in guter Buchhalter-Manie einfach mal gerne alle Fliesskommazahlen hart abschneidet.. Haben wir uns aber aufgrund der immensen Beträge von +-1ct/Bestellung
[...]
Weil richtig: an der Floating-point-präzision von 32Bit CPU's oder PHP liegts bestimmt nicht

Ne, ne, ne. Geld und Floating-Point passt nicht zusammen - hat es noch nie und wird es auch nie.
Bei Cobol-Programmierern erwarte ich dass die das wissen...

Beispiel (einfach per Copy&Paste in die Firebug Kommandozeile zum Testen):

var  etwasGeld = 0.01;   // 1 Cent - in Euros angegeben
var einnahme = 0;        // Wie viele Euros haben wir bekommen?
for( bestellungen = 0; bestellungen  < 100; bestellungen++ ) { 
  einnahme += etwasGeld; // Pro Bestellung gibt's etwas Geld
} 

// Und nun: Was bleibt übrig wenn wir einen Euro aus der Kasse nehmen?
console.log( einnahme - 1.00 );

Was erwarten wir, wenn wir 100*0.01 - 1 rechnen? Und was kommt raus?

Da Buchhaltung immer auf den Cent aufgehen muss, bleibt nur eine Lösung: Fixed Point rechnen (oder, was aber das selbe ist, in Cent rechnen und nur beim Anzeigen einen Punkt bzw. Komma für den Euro-Betrag bei der Ausgabe einfügen).
SQL kann Fixed Point IIRC ziemlich leicht (war das nicht der Datentyp DECIMAL?) - was aber auch zeigt, dass das (mit Geld in einer DB umgehen) ein typisches Problem ist, das bereits gelöst wurde.

PS: Dabei habe ich noch nicht mal angesprochen, was passiert, wenn die Mantisse nicht mehr ausreicht und dann sogar ganz fies gerundet oder abgeschnitten wird
PPS: Die Präzession von PHP ist die von der CPU (wenn man den nativen Datentyp und nicht eine Erweiterung wie PHP: BC Math - Manual nimmt). Und die der CPU ist schon seit vielen Jahren die der IEEE 754 - und die reicht aus um die Welt zu berechnen und zu beschreiben. Zumindest wenn man Profis rechnen lässt, die genau wissen wo die Grenzen liegen - dann passiert auch nicht das, was der Sleipner A offshore platform passiert ist...
PPPS: Das muss jetzt als Numerik-Unterricht für heute reichen