Summe eines Arrays

[Matzeeee]

Schönen Mittag wünsche ich !!

Habe folgendes Problem:

ich möchte einfach die Summe aus einem Array wiedergeben was wie folgt aussieht:

Array
(
    [0] => Array
        (
            [product_price] => 58.99
        )

[1] => Array
        (
            [product_price] => 146.00
        )

)

Ich speichere die Daten per while-Schleife in dem Array
Ein echo array_sum($preis); gibt mir nur den Wert "0" zurück.
Die Frage ist nun ob man mit diesem "Array im Array" so arbeiten kann?
Falls nicht liegt es an der While Schleife? Steh gerade irgendwie auf dem Schlauch und bitte um Hilfe. Danke Matze

[ChrisB]

Hi,

ich möchte einfach die Summe aus einem Array wiedergeben was wie folgt aussieht: [...]

Ich speichere die Daten per while-Schleife in dem Array

Und warum ermittelst du die Summe dann nicht einfach schon innerhalb dieser Schleife, in dem du jeden Wert auf eine Summen-Variable drauf addierst?

Ein echo array_sum($preis); gibt mir nur den Wert "0" zurück.
Die Frage ist nun ob man mit diesem "Array im Array" so arbeiten kann?

Nein, array_sum möchte ein eindimensionales Array haben.

MfG ChrisB

[Matzeeee]

Hi,

ich möchte einfach die Summe aus einem Array wiedergeben was wie folgt aussieht: [...]

Ich speichere die Daten per while-Schleife in dem Array

Und warum ermittelst du die Summe dann nicht einfach schon innerhalb dieser Schleife, in dem du jeden Wert auf eine Summen-Variable drauf addierst?

Ein echo array_sum($preis); gibt mir nur den Wert "0" zurück.
Die Frage ist nun ob man mit diesem "Array im Array" so arbeiten kann?

Nein, array_sum möchte ein eindimensionales Array haben.

MfG ChrisB

Vielen Dank für die schnelle Antwort...
"malEinStepZurSeiteVomSchlauchMachen"

$preis = array();
        $summe = 0;
        while ($productpreis = mysql_fetch_array($db_ergEP, MYSQL_ASSOC)){
            $preis[] = $productpreis;
            $summe = $summe + $productpreis['product_price'];
        }

funktioniert DANKE

[Der Martin]

Hallo,

Hi,
[...]
MfG ChrisB

bitte zitiere nicht das gesamte Vorposting ("TOFU"), sondern gezielt das, worauf du dich beziehst - sonst lass das Zitat lieber ganz weg.

"malEinStepZurSeiteVomSchlauchMachen"

;-)

$summe = $summe + $productpreis['product_price'];

Oder noch etwas einfacher und übersichtlicher:

$summe += $productpreis['product_price'];

Wobei du bei *diesem* Array-Aufbau auch wieder array_sum() verwenden könntest, wenn dir das besser gefällt.

Ciao,
 Martin

[fastix®]

Moin!

Das geht so nicht, weil array_sum() nicht weiß, was es denn addieren soll.

In deinem Fall ist es so, dass Du einen Array aus Hashes hast. array_sum kann wunderbar eindimensionale Array durchrechnen. Deinen indes nicht. Was wäre denn, wenn es nicht nur einen Preis gäbe:

Array
(
    [0] => Array
        (
            [product_price] => 58.99
            [special_price] => 49.99
        )

[1] => Array
        (
            [product_price] => 146.00
            [special_price] => 126.99
        )

)

Dir kann aber geholfen werden. Damit die von mir verwendeten Variablen nicht mit Deinen kollidieren kapsele ich die Ermittlung in einer Funktion:

function getSummeVonArrayAusHashes ($ar, $sKey) {  
     /*  
     # $ar: Array aus Hashes  
     # $sKey: hash-Bezeichner des jeweiligen Elementes  
     */  
  
     // Leere Variable für die Summe:  
     $sum=0;  
     // Für jedes Element des Arrays als hash:  
     foreach ($ar as $tmp) {  
     // Teste ob der Key überhaupt existiert:  
         if (isset($tmp[$sKey]) {  
               // addiere den Wert:  
               $sum += $tmp[$sKey]; // Kann auch als $sum = $sum + $tmp[$sKey] notiert werden.  
         } else {  // Falls nicht ...  
             // Deine Fehlerbehandlung hier hinschreiben  
             return false; // Abbruch  
         }  
     }  
     return $sum;  
}

In Deinem Fall kann es womöglich mit der funktion und dem Aufruf ...

setlocale(LC_MONETARY, 'de_DE');  
$summe=getSummeVonPreisArray ($preis, 'product_price');  
if (! false === $summe) {  // Kann ja tatsächlich auch 0 rauskommen...  
     print money_format('%.2n', $summe);  
} else {  
      // Deine Fehlerbehandlung hier hinschreiben  
}

... funktionieren. Der Code kann fehlerhaft sein, er ist nicht getestet, kann insbesondere "Typos" enthalten. Die weitere Verfeinerung überlasse ich Dir.

Im Übrigen wirst Du schon bald sehen das es besser ist die Preise als ganzzahlige Cent-Beträge zu speichern, mit diesen zu rechnen und diese nur für Ausgaben in Euro "umzurechnen".

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Im Übrigen wirst Du schon bald sehen das es besser ist die Preise als ganzzahlige Cent-Beträge zu speichern, mit diesen zu rechnen und diese nur für Ausgaben in Euro "umzurechnen".

Warum sollte man das tun?

Es ist (außer bei Beträgen unter 1 Euro) im täglichen Leben nicht üblich, Preise in Cent anzugeben. Ein Programm sollte das widerspiegeln, also auch in Euro rechnen.

Qapla'

[fastix®]

Moin!

Warum sollte man das tun?

"Das haben wir doch hier Forum schon tausendmal diskutiert." Vor allem aber wollte ich einem gewissen Gunnar Bittersmann und noch so zwei, drei anderen Meckerfritzen die Möglichkeit des Monierens nehmen, dass ich es nicht vorgeschlagen hätte.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Tom]

Hello,

"Das haben wir doch hier Forum schon tausendmal diskutiert." Vor allem aber wollte ich einem gewissen Gunnar Bittersmann und noch so zwei, drei anderen Meckerfritzen die Möglichkeit des Monierens nehmen, dass ich es nicht vorgeschlagen hätte.

Na, dann will ich dem Einen oder der Anderen mal wieder die Möglichkeit zum Rumnölen einräumen:

@Matzeeee:

Wenn man die Datenstruktur von vorneherein anders aufbaut, kann man alle diese praktischen Arrayfunktionen von PHP auch nutzen.

aus

Array
(
    [0] => Array
    (
        [product_price] => 58.99
        [special_price] => 49.99
    )

[1] => Array
    (
        [product_price] => 146.00
        [special_price] => 126.99
    )
)

machen wir:

Array
(
    [product_price] => Array
    {
        [0] => 58.99
        [1] => => 146.00
    }

[special_price] =>
    {
        [0] => 49.99
        [1] => 126.99
    }
}

Das Einzige, worauf man dann achten muss, ist die Harmonisierung der Indexe.

Man kann dieses Array aber nach jeder "Spalte" sortieren, und zwar auch gleichzeitig nach allen. Je nachdem, welche man dann als Leitspalte benutzt, kann man die Datensätze wieder holen.
Auf jede Spalte sind dann auch alle die praktischen Funktionen von PHP für Summe, Durschnitt, Maximum, usw.  anwendbar

Ein paar Funktionen zum Einfügen, Ändern usw. von "Datensätzen" findet man schon unter
http://wiki.selfhtml.org/wiki/Artikel:PHP/Arrays_mal_anders_herum

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[fastix®]

Moin!

Das Einzige, worauf man dann achten muss, ist die Harmonisierung der Indexe.

Hm. Das macht es "irre kompliziert" einen Datensatz zu löschen oder einzufügen. Besonders bei späteren Änderungen.

Ich bin jetzt auf den objektorientierten Lösungsansatz gespannt. Der könnte geeignet sein, das Problem zu ein für alle mal beheben!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Tom]

Hello,

Das Einzige, worauf man dann achten muss, ist die Harmonisierung der Indexe.
Hm. Das macht es "irre kompliziert" einen Datensatz zu löschen oder einzufügen. Besonders bei späteren Änderungen.

Wieso, die Funktionen sind einmalig erstellt und funktionieren universell, egal, wie breit der Datensatz wird.

Ich bin jetzt auf den objektorientierten Lösungsansatz gespannt. Der könnte geeignet sein, das Problem zu ein für alle mal beheben!

Das könnte die Akzeptanz verbessern helfen ;-)

Aber es muss ja jeder selber wissen, womit er sich abquält.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello Fastix,

Ich bin jetzt auf den objektorientierten Lösungsansatz gespannt. Der könnte geeignet sein, das Problem zu ein für alle mal beheben!

Ich habe darüber während meines stupiden Tages-Frondienstes nochmal nachgedacht. Ich glaube, dass das wirklich eine gute Idee wäre, dieses ständig wiederkehrende "Problem" einfach mal durch eine Klasse zu knacken.

Was müsste die denn Deiner Meinung nach alles leisten? Ich wede dann meine Gedanken auch noch sammeln und hinzufügen. Hier wäre natürlich toll, wenn PHP Überladung können würde. Dann könnten wir z.B. den []-Operator einfach ersetzen...

Aber sicherlich gibt es auch noch genügend andere sinnvolle Möglichkeiten, die man auch auf andere Weise einbauen kann.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matti Mäkitalo]

Hi,

Ich bin jetzt auf den objektorientierten Lösungsansatz gespannt. Der könnte geeignet sein, das Problem zu ein für alle mal beheben!

Ich habe darüber während meines stupiden Tages-Frondienstes nochmal nachgedacht. Ich glaube, dass das wirklich eine gute Idee wäre, dieses ständig wiederkehrende "Problem" einfach mal durch eine Klasse zu knacken.

alles relevante hat Sven Rautenberg schon gesagt. Im wesentlichen geht es um die Benutzung von map-Funktionen (array_map im Falle von PHP) und Callback-Funktionen.

Dies halte ich auch für "sauberer", da sie auch in anderen Sprachen meist genauso umgesetzt werden würden. Dadurch braucht man den Wust an unübersichtlichen Funktionen nicht mehr, den PHP hat. Als Beispiel seien hier die Sortierfunktionen erwähnt. PHP braucht 13 verschiedene Funktionen, während z.B. perl dank Callback-Funktion mit einer auskommt.

  
my @array = sort { $a{'price'} < $b{'price'} } @unsorted_array;  

Eine kurze Möglichkeit (in PHP) dafür kenne ich zumindest nicht, eine kurze Recherche liefert auch nur eher umständliche Methoden wie z.B. dieser Userkommentar auf php.net.

Trotzdem würde _ich_ nicht auf die von dir vorgestellte Art, Daten zu speichern, ausweichen. Die Nachteile erscheinen mir einfach zu groß, insbesonders, wenn man sich überlegt, mit welchen Laufzeiten die von dir vorgestellten Ausweichfunktionen funktionieren.

Bis die Tage,
Matti

[Tom]

Hello,

Trotzdem würde _ich_ nicht auf die von dir vorgestellte Art, Daten zu speichern, ausweichen. Die Nachteile erscheinen mir einfach zu groß, insbesonders, wenn man sich überlegt, mit welchen Laufzeiten die von dir vorgestellten Ausweichfunktionen funktionieren.

Hast Du die denn mal getestet gegenüber der orthogonalen Standardlösung?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Matti Mäkitalo]

Hi,

Trotzdem würde _ich_ nicht auf die von dir vorgestellte Art, Daten zu speichern, ausweichen. Die Nachteile erscheinen mir einfach zu groß, insbesonders, wenn man sich überlegt, mit welchen Laufzeiten die von dir vorgestellten Ausweichfunktionen funktionieren.

Hast Du die denn mal getestet gegenüber der orthogonalen Standardlösung?

nein, deswegen nutzte ich das Wort "erscheinen". Was ich beschrieb, sind theoretische Überlegungen.

Beispiele aus deinem Artikel, n sei die Anzahl der Einträge, m die Anzahl der Eigenschaften pro Eintrag.

function get_record (&$_data, $recno)  
{  
    $_rec = array();  
  
    foreach ($_data as $colname => $field)  
    {  
        $_rec[$colname] = isset($_data[$colname][$recno])?$_data[$colname][$recno]:NULL;  
    }  
  
    return $_rec;  
}

Für die Laufzeit hast du die for-Schleife, welche du ganz durchlaufen musst (O(m)), und dann noch die Array-Zugriffe (O(log n)), also O(m log n) zusammen.
In der üblichen Speicherung brauchst du dafür nur O(log n).

Das zieht sich durch deine anderen Funktionen durch. Als Vorteil hast du, dass du bequemer die PHP-Array-Funktionen nutzen kannst. Mit erwähnten array_map/array_reduce/... kannst du aber hier jegliches Verhalten für Objekt-Arrays einigermaßen bequem nachbauen, insbesondere, wenn du Callback-Funktionen nutzen kannst. Für die Laufzeit sollte das keinen wesentlichen Unterschied machen.

Nun ist Laufzeit sicherlich nicht das Hauptproblem von PHP-Code. Bei großen Datenmengen macht man sich sicherlich Gedanken, ob man den dauerhaft im Speicher halten sollte (z.B. Datenbank-Resultsets können ja auch jeweils von der Datenbank einzeln abgeholt werden, ohne sie alle gleichzeitig im PHP-Speicher halten zu müssen; hier hätte man auch gleich die objektartige Speicherung).

Bis die Tage,
Matti

[Tom]

Hello,

Für die Laufzeit hast du die for-Schleife, welche du ganz durchlaufen musst (O(m)), und dann noch die Array-Zugriffe (O(log n)), also O(m log n) zusammen.
In der üblichen Speicherung brauchst du dafür nur O(log n).

Ja, das ist die Theorie an der Oberfläche.

Nur wenn Du Aufwandschätzung betreiben willst, musst Du das in der Schicht tun, die nachher tatsächlich die Ausführung betreibt.

Darum fragte ich ja, ob Du es _ausprobiert_ hättest.

Ich halte Deine Einwand durchaus für wichtig. Ich selber traue mir aber hier aufgrund der Hash-Algorithmen, die PHP bei den Arrays benutzt, keinerlei Schätzung mehr zu.

Meine (sehr privaten) Tests haben bisher ergeben, dass meine Lösung meistens schneller ist und weniger Speicher benötigt. Das liegt vermutlich auf der Reduzierung auf _numerische_ Indexe, die in der Hashtabelle dann doppelt weniger Aufwand haben - einmal der Wegfall der Hashbildung für einen Namen und dann die daraus resultierende einfachere Sortierung in der Kette, also den tatsächlichen Zugriffszeiten für ein Element.

Denn wir dürfen ja nicht vergessen, dass PHP für _jedes_ Element, also auch die Subelemente eines Records, einen Hashwert bilden muss.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Ich bin jetzt auf den objektorientierten Lösungsansatz gespannt. Der könnte geeignet sein, das Problem zu ein für alle mal beheben!
Ich habe darüber während meines stupiden Tages-Frondienstes nochmal nachgedacht. Ich glaube, dass das wirklich eine gute Idee wäre, dieses ständig wiederkehrende "Problem" einfach mal durch eine Klasse zu knacken.

Welches genau meinst du jetzt? Ich nehme mal an, du willst nicht das Geld-Int-Float-Problem angehen, sondern eine Klasse erstellen, die nach außen hin sich wie ein Zeilenarray gibt, innen jedoch mit einem Spaltenarray arbeitet.

Was müsste die denn Deiner Meinung nach alles leisten? Ich wede dann meine Gedanken auch noch sammeln und hinzufügen. Hier wäre natürlich toll, wenn PHP Überladung können würde. Dann könnten wir z.B. den []-Operator einfach ersetzen...

Mit der Funktionalität der SPL kann man eine Menge Array-Features in Klassen einbauen. Array-Zugriff, also [], geht mit der Implementation des Interfaces ArrayAccess und foreach mit Iterator (nur ein foreach zur selben Zeit) oder besser IteratorAggregate (mehrere unabhängige Iteratoren möglich).

Was alles rein muss, kommt später. Fang erstmal mit dem Grundgerüst an und implementiere ArrayAccess und IteratorAggregate.

Lo!

[Alexander (HH)]

Moin Moin!

Warum sollte man das tun?

Rundungsfehler bei der Darstellung als Float.

Es ist (außer bei Beträgen unter 1 Euro) im täglichen Leben nicht üblich, Preise in Cent anzugeben. Ein Programm sollte das widerspiegeln, also auch in Euro rechnen.

Nein, sollte es nicht. Es sei denn, man benutzt einen Datentyp, der keine solchen Rundungsfehler hat (z.B. durch BCD- oder Dezimal-Darstellung).

Alexander

[Gunnar Bittersmann]

@@Alexander (HH):

nuqneH

Es ist (außer bei Beträgen unter 1 Euro) im täglichen Leben nicht üblich, Preise in Cent anzugeben. Ein Programm sollte das widerspiegeln, also auch in Euro rechnen.

Nein, sollte es nicht.

Sehe ich anders.*

Es sei denn, man benutzt einen Datentyp, der keine solchen Rundungsfehler hat (z.B. durch BCD- oder Dezimal-Darstellung).

Bei Datenbanken den Typ DECIMAL, ja.

Wenn in Programmiersprachen kein solcher Datentyp zur Verfügung steht, kann man intern getrost mit Fließkommazahlen rechnen. Es stört überhaupt nicht, wenn 42 als 42.0…01 oder 41.9…9 repräsentiert ist. Bei der Übergabe nach außen (HTML, Datenbank, API) ist auf 2 Nachkommaziffern zu runden.

Qapla'

* Bei der Rechnung in Cent besteht die Gefahr, dass irgendwein Programmierer an irgendeiner Stelle (entsprechend der Verwendung im täglichen Leben!) davon ausgeht, dass der Betrag in Euro angegeben ist.

Das hätte fatalere Konsequenzen als ein Fehler in der x-ten Nachkommastelle.

[fastix®]

Moin!

Es stört überhaupt nicht, wenn 42 als 42.0…01 oder 41.9…9 repräsentiert ist.

Na? Und was passiert wenn man diese "42.001" zehn mal verkauft? Richtig: Man hat statt 420.00 420.01 Ocken auf der Rechnung. Wenn man nicht mit der "Bistromatic" fliegen will kann man diese zwar als Problem andere Leute an- oder übersehen - aber die Rechnung muss am Ende stimmen.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Es stört überhaupt nicht, wenn 42 als 42.0…01 oder 41.9…9 repräsentiert ist.

Na? Und was passiert wenn man diese "42.001" zehn mal verkauft? Richtig: Man hat statt 420.00 420.01 Ocken auf der Rechnung.

Falsch, du gehst irrsinnigerweise von 42.001 aus.

Qapla'

[fastix®]

Moin!

Falsch, du gehst irrsinnigerweise von 42.001 aus.

Use of undefined constant irrsinnigerweise a - assumed 'sinnigerweise' in ./?t=207640&m=1411436 line 9

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Use of undefined constant irrsinnigerweise a - assumed 'sinnigerweise' in ./?t=207640&m=1411436 line 9

Ich weiß nicht, was du willst. Kann dein System U+2026 '…' nicht darstellen?

Qapla'

[fastix®]

Moin!

Ich weiß nicht, was du willst. Kann dein System U+2026 '…' nicht darstellen?

Ich weiß nicht, was Du ausdrücken willst. Ich habe das '…' korrekt als "irgendwas oder nichts" interpretiert.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Ich weiß nicht, was Du ausdrücken willst.

Natürlich wollte ich die Ungenauigkeit ausdrücken, die bei der Berechnung mit endlichen Binärbrüchen und deren Umrechnung in Dezimalbrüche entsteht. Warst du es nicht, der die Verfolgung des Threadverlaufs einforderte?

Ich habe das '…' korrekt als "irgendwas oder nichts" interpretiert.

Nix korrekt. Die Ungenauigkeit tritt erst weiter hinten auf. Etliche Stellen weiter.

Qapla'

[ChrisB]

Hi,

Nix korrekt. Die Ungenauigkeit tritt erst weiter hinten auf. Etliche Stellen weiter.

Nein, eben nicht.
Nimm mein Beispiel von eben, Wert 42.001 mit nur zehn Iterationen* - und schon bekommst du den falschen Wert 420.01 heraus. Und ja, auch dieser eine Cent kann schon zu viel sein.

* und wenn du erst anschließend runden willst, dann genügen sogar schon 5 Iterationen.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Nimm mein Beispiel von eben, Wert 42.001 mit nur zehn Iterationen* - und schon bekommst du den falschen Wert 420.01 heraus.

Warum wundert mich das nicht, dass bei 42.001 · 10 eben 420.01 herauskommt?

Was mich aber wundert: Wo kommt die 42.001 her?

Qapla'

[ChrisB]

Hi,

Was mich aber wundert: Wo kommt die 42.001 her?

Die könnte bspw. daher kommen, dass bereits in vorhergehenden Rechenschritten jemand mit einer dusseligen „ach ist schon nicht so wild“-Einstellung an die Sache herangegangen ist.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Was mich aber wundert: Wo kommt die 42.001 her?

Die könnte bspw. daher kommen, dass bereits in vorhergehenden Rechenschritten jemand mit einer dusseligen „ach ist schon nicht so wild“-Einstellung an die Sache herangegangen ist.

Wie viele Iterationen hätten wir denn diesmal gern, damit aus x.0…01 42.001 wird? Doch orientalischer Basar? ;-)

Qapla'

[fastix®]

Moin!

Was mich aber wundert: Wo kommt die 42.001 her?

Mein Gott: 19% oder 7% Mehrwertsteuer. Oder:  Jemand kauft 1 Gramm von etwas, das pro Kg 42001 € kostet. Oder Du musst Kosten/Preise der Serienherstellung von technischen Geräten kalkulieren und hast Einkaufspreise für je 1000 Stück. Beispiel? Prozessoren.

Den konkreten Fall müssen wir nicht wissen. Es geht um eine allgemeine technische Aussage für Preisberechnungen oder solche in der Finanzwirtschaft. Und so ganz allgemein stellt es sich als ungünstig dar mit Fließkommazahlen zu arbeiten.

Also: Wo ist Dein Problem?

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Jemand kauft 1 Gramm von etwas, das pro Kg 42001 € kostet. Oder Du musst Kosten/Preise der Serienherstellung von technischen Geräten kalkulieren und hast Einkaufspreise für je 1000 Stück.

In den Fällen _willst_ du mit Fließkommazahlen rechnen. Du willst ja gerade _nicht_ die 42.001 auf 2 Dezimalstellen zu 42.00 runden, oder?

Also: Wo ist Dein Problem?

Ich sehe es als problematisch an, in einer anderen Einheit als der üblichen zu rechen. (Fußnote in https://forum.selfhtml.org/?t=207640&m=1411429)

Qapla'

[fastix®]

Moin!

Also: Wo ist Dein Problem?

Ich sehe es als problematisch an, in einer anderen Einheit als der üblichen zu rechen. (Fußnote in https://forum.selfhtml.org/?t=207640&m=1411429)

Ach so. Da kann ich Dich beruhigen. Der Cent ist (im Euro-Raum) die kleinste - und durchaus übliche Einheit - für den Geldwert.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Der Cent ist (im Euro-Raum) die kleinste - und durchaus übliche Einheit - für den Geldwert.

In meinem Raum hab ich noch nie „für nur 1999 Cent“ gehört.

Qapla'

[Der Martin]

Hallo,

Der Cent ist (im Euro-Raum) die kleinste - und durchaus übliche Einheit - für den Geldwert.
In meinem Raum hab ich noch nie „für nur 1999 Cent“ gehört.

wirklich nicht? Ich sehe alle paar Tage beim Tanken, dass der Spritpreis an der Zapfsäule in Cent pro Liter eingestellt wird, und das sogar mit einer sinnlosen Nachkommastelle. Heute beispielsweise auf 138.9, letzte Woche deutlich höher (Diesel).

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Ich sehe alle paar Tage beim Tanken, dass der Spritpreis an der Zapfsäule in Cent pro Liter eingestellt wird, und das sogar mit einer sinnlosen Nachkommastelle. Heute beispielsweise auf 138.9, letzte Woche deutlich höher (Diesel).

Hm, andere Ländle, andere Sitten? Ich würde denken, bei uns stünde 1.38₉ dran. Würde aber nicht meinen Arm darauf setzen. Muss ich mal dran denken, genau hinzusehen.

Qapla'

[Der Martin]

Hallo Gunnar,

Ich sehe alle paar Tage beim Tanken, dass der Spritpreis an der Zapfsäule in Cent pro Liter eingestellt wird, und das sogar mit einer sinnlosen Nachkommastelle. Heute beispielsweise auf 138.9, letzte Woche deutlich höher (Diesel).
Hm, andere Ländle, andere Sitten? Ich würde denken, bei uns stünde 1.38₉ dran.

an der großen, von der Straße aus sichtbaren Preistafel, ja. Nicht am geeichten Zählwerk der Zapfsäule, egal ob mechanisch (hat inzwischen Seltenheitswert) oder elektronisch.

Ciao,
 Martin

[Multi]

an der großen, von der Straße aus sichtbaren Preistafel, ja. Nicht am geeichten Zählwerk der Zapfsäule, egal ob mechanisch (hat inzwischen Seltenheitswert) oder elektronisch.

Also in meinem Umkreis ist da an allen Säulen ein Komma aufgeklebt. Mag bei der einen oder anderen abgefallen sein aber grundsätzlich ist bei der Mehrheit der Zapfsäulen das Komma noch dran.

Zum Rechnen mit Preisen: Es macht oft Probleme in Cent zu rechnen, vorallem, wenn man meit 4-6 Stellen hinter dem Komma rechnet (im Grosshandel absolut üblich, grad beim Im-/Export). Und dass die üblichen ERP und POS intern ebenfalls mit € als float rechnen, sollte zeigen, was üblich ist,  Sinn macht und was sich in der Programmierung eingebürgert hat.

[ChrisB]

Hi,

Zum Rechnen mit Preisen: Es macht oft Probleme in Cent zu rechnen, vorallem, wenn man meit 4-6 Stellen hinter dem Komma rechnet (im Grosshandel absolut üblich, grad beim Im-/Export).

Ach, und das soll hinsichtlich der Ungenauigkeit bei der Darstellung von Dezimalbrüchen in binär arbeitenden Systemen besser werden, wenn man stattdessen in Euro rechnet, und damit das Komma noch um zwei Stellen nach links verschiebt …?

Und dass die üblichen ERP und POS intern ebenfalls mit € als float rechnen, sollte zeigen, was üblich ist,  Sinn macht und was sich in der Programmierung eingebürgert hat.

Die „das haben wir schon immer so gemacht“- und „das machen die anderen auch so“-Argumentation überzeugt mich an dieser Stelle eher weniger.

MfG ChrisB

[Multi]

Ach, und das soll hinsichtlich der Ungenauigkeit bei der Darstellung von Dezimalbrüchen in binär arbeitenden Systemen besser werden, wenn man stattdessen in Euro rechnet, und damit das Komma noch um zwei Stellen nach links verschiebt …?

Du glaubst also, wenn ich ein 32-Bit float habe macht sich ein Rundungsfehler
 bemerkbar? Das würde ja bedeuten, dass die Finanzämter weltweit Systeme anerkennen, die völlig ungenau sind und damit nicht brauchbar.

ES gibt IMO einen Unterschied zwischen Theorie und Praxis. Und die Praxis zeigt, dass diese Rundungsfehler nicht relevant sind.

Die „das haben wir schon immer so gemacht“- und „das machen die anderen auch so“-Argumentation überzeugt mich an dieser Stelle eher weniger.

Liegt vermutlich daran, dass es keine solche Argbumentation ist. Hier geht es um Kompatibilität der verschiedenen Systeme um per POS auf ein ERP eines anderen Anbieters aufbauen zu können ohne jeden Furz konvertieren zu müssen (wobei hier wieder Rundungsfehler entstehen die nicht auftreten, wenn der Wert unverändert übernommen wird)

Du kannst mir aber gerne ein _praxistaugliches_ Beispiel nennen, bei dem ein Rundungsfehler relevant ist. Und das Beispiel mit 42.001 ist hier nicht interessant, weil, wie geschrieben, oft 4 und mehr stellen hinter dem Komma interessant sind. Praxistauglich ist ein Beispiel also erst dann, wenn Beträge im 1/1000-Cent Bereich so verfälscht werden, dass sie nicht mehr brauchbar sind.

[ChrisB]

Hi,

Du kannst mir aber gerne ein _praxistaugliches_ Beispiel nennen, bei dem ein Rundungsfehler relevant ist. Und das Beispiel mit 42.001 ist hier nicht interessant, weil, wie geschrieben, oft 4 und mehr stellen hinter dem Komma interessant sind. Praxistauglich ist ein Beispiel also erst dann, wenn Beträge im 1/1000-Cent Bereich so verfälscht werden, dass sie nicht mehr brauchbar sind.

Gerade dann, wenn du weiter nach rechts „hinter“ das Komma gehst, steigt doch die Chance, dass sich Float-Ungenauigkeiten signifikant auswirken.

MfG ChrisB

[Multi]

Gerade dann, wenn du weiter nach rechts „hinter“ das Komma gehst, steigt doch die Chance, dass sich Float-Ungenauigkeiten signifikant auswirken.

Bei einer 32-Bit float, die grundsätzlich gerundet wird, da mit so vielen Stellen keiner handelt, macht das absolut keinen Unterschied. Wie gesagt, wenn du mir ein Praxisbeispiel gibst, revidier ich meine Meinung, bis dahin bleib ich aber dabei.

[Der Martin]

Hallo,

Bei einer 32-Bit float, die grundsätzlich gerundet wird, da mit so vielen Stellen keiner handelt, macht das absolut keinen Unterschied.

führe dir bitte mal vor Augen, dass das 32bit-Fließkommaformat (IEEE binary32) gerade mal 23 Bits für die Mantisse vorsieht. Das entspricht in der dezimalen Darstellung nur 7 gültigen Stellen.
Wenn man also Beträge, wie sie beim Auto- oder Hauskauf durchaus auftreten, auf Cent genau erfassen will, versagt dieses Format schon.

So long,
 Martin

[dedlfix]

Hi!

Bei einer 32-Bit float, die grundsätzlich gerundet wird, da mit so vielen Stellen keiner handelt, macht das absolut keinen Unterschied.
führe dir bitte mal vor Augen, dass das 32bit-Fließkommaformat (IEEE binary32) gerade mal 23 Bits für die Mantisse vorsieht. Das entspricht in der dezimalen Darstellung nur 7 gültigen Stellen.

Beides ist nicht relevant, weil PHP mit "doppelter Genauigkeit" rechnet, also 64-Bit-Floats verwendet und 14 Stellen zur Verfügung hat.

Wenn man also Beträge, wie sie beim Auto- oder Hauskauf durchaus auftreten, auf Cent genau erfassen will, versagt dieses Format schon.

Bei 7-stelligen Zahlen braucht es ungefähr auch eine 7-stellige Anzahl von Rechenschritten, um zu versagen (wenn ich mich mal auf Gunnars Aussage verlasse, denn das Problem hatte ich selbst noch nicht). Und ob man solche großen Dimensionen noch mit PHP rechnet oder genauer gefragt, der OOP sie vorliegen hat, ...

Um den Rundungsfehlern generell aus dem Weg zu gehen, kann man jedenfalls in PHP mit GMP oder BC Math arbeiten.

Lo!

[Der Martin]

Hallo,

führe dir bitte mal vor Augen, dass das 32bit-Fließkommaformat (IEEE binary32) gerade mal 23 Bits für die Mantisse vorsieht. Das entspricht in der dezimalen Darstellung nur 7 gültigen Stellen.
Beides ist nicht relevant, weil PHP mit "doppelter Genauigkeit" rechnet, also 64-Bit-Floats verwendet und 14 Stellen zur Verfügung hat.

das dachte ich mir schon - Javascript anscheinend auch, wie ein
  alert(1e7+0.1)
zeigt. Würde die interne Rechnung auf single-precision float basieren, wäre das Ergebnis wieder 1E+07, weil der "Dynamikbereich" nicht mehr ausreicht, um die 0.1 dagegen noch darzustellen.

Wenn man also Beträge, wie sie beim Auto- oder Hauskauf durchaus auftreten, auf Cent genau erfassen will, versagt dieses Format schon.
Bei 7-stelligen Zahlen braucht es ungefähr auch eine 7-stellige Anzahl von Rechenschritten, um zu versagen

Nein, es braucht nur Zahlen, deren Größenordnung genügend weit auseinanderliegt. Nimm etwa eine Summe von 50'003 Euro und rechne unter Verwendung von 32bit-Floats die Märchensteuer drauf. Das geht gerade noch gut, du bekommst 59'503.57, aber damit ist auch der Genauigkeitsbereich dieser Zahlendarstellung nahezu ausgeschöpft. Jede weitere Rechenoperation mit diesem Wert könnte bereits einen Fehler auf der letzten Stelle erzeugen.

So long,
 Martin

[Sven Rautenberg]

Moin!

Nein, es braucht nur Zahlen, deren Größenordnung genügend weit auseinanderliegt. Nimm etwa eine Summe von 50'003 Euro und rechne unter Verwendung von 32bit-Floats die Märchensteuer drauf. Das geht gerade noch gut, du bekommst 59'503.57, aber damit ist auch der Genauigkeitsbereich dieser Zahlendarstellung nahezu ausgeschöpft. Jede weitere Rechenoperation mit diesem Wert könnte bereits einen Fehler auf der letzten Stelle erzeugen.

32-Bit-Integer, auf Cent geeicht, haben auch nur einen nutzbaren Wertebereich von neun Stellen. Und dann noch den Nachteil, keine Centbruchteile verarbeiten zu können. Rechnungen werden also zwar centgenau ausgeführt, aber jeder einzelne Rechenschritt wird implizit immer gerundet. Das ist nicht immer das, was man braucht.

Und Tankstellenbenzinpreise lassen sich eben auch nicht als Integer verwalten.

- Sven Rautenberg

[dedlfix]

Hi!

Wenn man also Beträge, wie sie beim Auto- oder Hauskauf durchaus auftreten, auf Cent genau erfassen will, versagt dieses Format schon.
Bei 7-stelligen Zahlen braucht es ungefähr auch eine 7-stellige Anzahl von Rechenschritten, um zu versagen
Nein, es braucht nur Zahlen, deren Größenordnung genügend weit auseinanderliegt. Nimm etwa eine Summe von 50'003 Euro und rechne unter Verwendung von 32bit-Floats die Märchensteuer drauf.

Ich meinte, dass bei einem 64-Bit-Float bei 7-stelligen Zahlen noch 7 weitere Stellen bis zum Ende der Genauigkeit übrigbleiben. Um diese Genauigkeit aufzubrauchen, muss man also den Rundungsfehler um diese weiteren 7 Stellen nach links bekommen. Die zweimal angeführte 7 war leider zufällig gleich der 7 bei der Genauigkeit der 32-Bit-Floats.

Lo!

[Der Martin]

Hallo,

Ich meinte, dass bei einem 64-Bit-Float bei 7-stelligen Zahlen noch 7 weitere Stellen bis zum Ende der Genauigkeit übrigbleiben. Um diese Genauigkeit aufzubrauchen, muss man also den Rundungsfehler um diese weiteren 7 Stellen nach links bekommen. Die zweimal angeführte 7 war leider zufällig gleich der 7 bei der Genauigkeit der 32-Bit-Floats.

alles klar, dann bin ich voll in die vorbereitete Missverständnis-Falle getappt. :-)

Ciao,
 Martin

[fastix®]

Moin!

Und dass die üblichen ERP und POS intern ebenfalls mit € als float rechnen, sollte zeigen, was üblich ist,  Sinn macht und was sich in der Programmierung eingebürgert hat.

Millionen Fliegen haben recht: Scheiße schmeckt gut!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Multi]

Millionen Fliegen haben recht: Scheiße schmeckt gut!

Heisst das jetzt, dass alles, was oft verwendet wird, scheisse ist oder das hier die Lösung scheisse ist, du aber nicht begründen kannst, wieso?

Denn dein Spruch allein ohne jegliche (praxistaugliche) Begründung kommt mir doch sehr nach Klugschiss vor, vorallem, weil es dein Einziger Beitrag zum Thema ist und dieser somit absolut keine Information enthält, sondern nur die entsprechenden Programmierer als Unfähig hingestellt.

[fastix®]

Moin!

und das sogar mit einer sinnlosen Nachkommastelle

Nun ja. Die selben Leute, die an Unterstützungen und Widerstände von Aktienkursen (und vor allem Indizes wie z.B. den Dax) glauben, die glauben auch, dass Spritkäufer psychologisch beeinflussbar sind und bei 139,9 Cent/Liter den Tank vollmachen, bei einem Kurs von 140 Cent/Liter aber nur halbvoll tanken und mal sehen, was die Preistafel am Mittwoch anzeigt.

An den mündigen, rationalen Käufer glaubt man in der universitären Volkswirtschaftslehre. Die Jungs in der PowerPoint-Abteilung wissen: 90% der Käufer verhalten sich genau so irre wie diese selbst.

Und wenn ich Leuten beim Einkaufen zusehe oder über das Einkaufen reden höre, dann muss ich dem PowerPointern sogar recht geben.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Was mich aber wundert: Wo kommt die 42.001 her?
Mein Gott: 19% oder 7% Mehrwertsteuer.

In dem Fall wird man so oder so auf ganze Cent (bzw. 0.01 €) runden, egal ob man in Cent oder in Euro rechnet.

Qapla'

[fastix®]

Moin!

In dem Fall wird man so oder so auf ganze Cent (bzw. 0.01 €) runden, egal ob man in Cent oder in Euro rechnet.

Ja, aber wenn man in Cent und mit Integer rechnet, dann kann es nicht passieren, dass die (nur für Ausgabe gerundeten) Einzelposten eine andere Summe ergeben als die aus den genauen Werten berechnete und erst dann gerundete Zahl.

Bei einem "Wir ziehen für 10 Stück "Sonstwas" zu je € 42,00 insgesamt € 420,01 ein."  wird man Dich nicht nur bei der Bank wegschicken.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Der Martin]

Hallo,

Bei einem "Wir ziehen für 10 Stück "Sonstwas" zu je € 42,00 insgesamt € 420,01 ein."  wird man Dich nicht nur bei der Bank wegschicken.

och, es gibt Firmen, die praktizieren das tatsächlich.
Vor einigen Jahren habe ich beim Elektronik-Versanhandel reichelt Kleinkram für insgesamt rund 30EU$ bestellt. Darunter waren Miniatur-Stecker, die im Katalog zu 17 Cent das Stück angeboten waren. Ich habe 10 Stück bestellt, und reichelt hat mir dafür 1.74EU$ in Rechnung gestellt.
Auf meine etwas empörte Nachfrage erklärte man mir, die Teile seien mit 17.4 Cent kalkuliert, aber im Katalog habe man natürlich nur auf Cent gerundete Preise. Gerechnet werde aber mit dem exakten Betrag.

Vermutlich hätte ich diese Masche damals schon anfechten können; die vier Cent waren's mir aber nicht wert, deswegen einen Zwergenaufstand zu machen.

Ciao,
 Martin

[Gunnar Bittersmann]

@@fastix®:

nuqneH

Ja, aber wenn man in Cent und mit Integer rechnet, dann kann es nicht passieren, dass die (nur für Ausgabe gerundeten) Einzelposten eine andere Summe ergeben als die aus den genauen Werten berechnete und erst dann gerundete Zahl.

Das kann bei Fließkomma-Arithmetik auch nur bei einer _sehr_ großen Anzahl von Summanden passieren …

"Wir ziehen für 10 Stück "Sonstwas" zu je € 42,00 insgesamt € 420,01 ein."

… keinesfalls bei 10.

Qapla'

[fastix®]

Moin!

Nix korrekt. Die Ungenauigkeit tritt erst weiter hinten auf. Etliche Stellen weiter.

Das ist Deine Meinung. Meine Meinung ist, das ich nicht wissen kann woher welche Ungenauigkeit kommt. Es geht hier um eine generelle Aussage.

Was glaubst Du, warum Microsoft in Excel (Menü Optionen, Register "Berechnen") eine Option für "Genauigkeit wie angezeigt" eingebaut hat. Sicher nicht aus Dummdidelei. Auf Integers zurückgreifen ging wohl noch schlechter.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[ChrisB]

Hi,

Wenn in Programmiersprachen kein solcher Datentyp zur Verfügung steht, kann man intern getrost mit Fließkommazahlen rechnen.

Nein, das sollte man möglichst nicht tun, wenn man bei Trost ist.

Es stört überhaupt nicht, wenn 42 als 42.0…01 oder 41.9…9 repräsentiert ist.

Doch, das „stört“:

$betrag = 42.001;  
$rechnungsSumme = 0;  
  
for($i=0; $i<10000; ++$i) {  
  $rechnungsSumme += $betrag;  
}  
  
echo $rechnungsSumme; // Ausgabe: 420009.99999993

Ups.

Bei der Übergabe nach außen (HTML, Datenbank, API) ist auf 2 Nachkommaziffern zu runden.

Eine Übergabe nach „außen“ ist in meinem Beispiel nicht erfolgt.

* Bei der Rechnung in Cent besteht die Gefahr, dass irgendwein Programmierer an irgendeiner Stelle (entsprechend der Verwendung im täglichen Leben!) davon ausgeht, dass der Betrag in Euro angegeben ist.

Das hätte fatalere Konsequenzen als ein Fehler in der x-ten Nachkommastelle.

Ja, der Depp, der keine Dokumentationen liest und nicht vernünftig testet, gehört natürlich gefeuert.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

$betrag = 42.001;

Wer hätte gedacht, dass du mit fastix unter einer Decke steckst. >;-)

Qapla'

[ChrisB]

Hi,

$betrag = 42.001;

Wer hätte gedacht, dass du mit fastix unter einer Decke steckst. >;-)

Nehme von mir aus gerne noch ein paar Nullen hinzu - das ändert nichts daran, dass bei ausreichend hoher Anzahl an Iterationen eine Abweichung auf einer signifikanten Stelle heraus kommt.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Nehme von mir aus gerne noch ein paar Nullen hinzu - das ändert nichts daran, dass bei ausreichend hoher Anzahl an Iterationen eine Abweichung auf einer signifikanten Stelle heraus kommt.

Wollen wir doch mal praxisbezogen bei handelsüblichen Mengen bleiben, ja?

Oder bist du es, Shihram?

Qapla'

[ChrisB]

Hi,

Nehme von mir aus gerne noch ein paar Nullen hinzu - das ändert nichts daran, dass bei ausreichend hoher Anzahl an Iterationen eine Abweichung auf einer signifikanten Stelle heraus kommt.

Wollen wir doch mal praxisbezogen bei handelsüblichen Mengen bleiben, ja?

Definiere „handelsüblich“.

Du willst doch wohl nicht behaupten, dass Transaktionen mit Postenanzahlen im sechs- oder siebenstelligen Bereich ungewöhnlich wären?
Erinnere dich, dass die „Rechenmaschine“ ursprünglich u.a. mal erfunden wurde, um solche Größenordnungen handhaben zu können.

Die Problematik ist längst nicht so praxisfern, wie du sie gerade hinstellen willst – ein Arbeitskollege hatte erst vor zwei Wochen mit einem solchen Problem Schwierigkeiten. In der Applikation wurde mit Eurobeträgen mit zwei Nachkommastellen gerechnet, als Datentyp in MySQL war dummerweise FLOAT gewählt – und das führte letztendlich dazu, dass die Schnittstelle eines Paymentanbieters dann die Validierung von Buchungen verweigerte, wegen einem Cent Differenz … und dabei ging es um weit weniger Rechnungsposten als im (bewusst überzogenen) obigen Beispiel.

MfG ChrisB

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

als Datentyp in MySQL war dummerweise FLOAT gewählt

Wie dumm. Wie war das mit dem Feuern von Deppen?

Qapla'

[ChrisB]

Hi,

als Datentyp in MySQL war dummerweise FLOAT gewählt

Wie dumm. Wie war das mit dem Feuern von Deppen?

Ich kann HR vom externen Dienstleister, der das erstellt hat, ja mal anrufen …

MfG ChrisB

[fastix®]

Moin!

Ich kann HR vom externen Dienstleister, der das erstellt hat, ja mal anrufen …

Die armen. Erst reichen die üblichen Zahlenformate nicht mehr für durch die Summierung vom gehebelten Pennystocks gebildeten Phantastilliarden aus und dann müssen sich die EDV-Fritzen noch den Vorwurf gefallen lassen, dass diese am Murks schuld sein sollen..

Dann gibt es künftig eben den bc statt PowerPoint!

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Gunnar Bittersmann]

@@ChrisB:

nuqneH

Ja, der Depp, der keine Dokumentationen liest und nicht vernünftig testet, gehört natürlich gefeuert.

Das kommt in den besten Familien vor.

Qapla'

[Sven Rautenberg]

Moin!

ich möchte einfach die Summe aus einem Array wiedergeben was wie folgt aussieht:

Array
(
    [0] => Array
        (
            [product_price] => 58.99
        )

[1] => Array
        (
            [product_price] => 146.00
        )

)

Ich speichere die Daten per while-Schleife in dem Array
Ein echo array_sum($preis); gibt mir nur den Wert "0" zurück.

Da array_sum() nur mit eindimensionalen Arrays arbeiten kann, wird das nicht funktionieren.

Aber es gibt eine allgemeine Funktion, die beliebige Arrays nach beliebigen Regeln auf einen Wert eindampfen kann: array_reduce().

Die reduce-Funktion muss zwei beliebige Array-Elemente nehmen, in die Unter-Arrays gehen, und die Summe der Preise zurückgeben.

In diesem Zusammenhang sei auch unbedingt auf array_map() hingewiesen. Mit dieser Funktion und array_sum() kann man's auch lösen.

Die map-Funktion muss ein Array-Element des Hauptarrays nehmen und den Preis aus dem Unter-Array zurückgeben. Das Funktionsergebnis von array_map() wird in array_sum() eingespeist.

Beide Funktionen zusammen machen das, was seit Google als Map-Reduce bekannt ist. Sollte man sich unbedingt mal mit beschäftigen. Insbesondere kann man seit PHP 5.3 die Callback-Funktionen direkt als Lambda-Funktionen angeben, muss sie also nicht irgendwo anders als Funktion definieren.

- Sven Rautenberg