ebody: toLocaleString() Nachkommastellen nicht runden

problematische Seite

Hallo,

ich wandel mit toLocaleString() eine Zahl wie -1.55555 in ein lokales (Deutsches) Format um mit 1000ender Trennzeichen und Nachkommastellen.

Die Zahl soll in diesem Beispiel 4 Stellen nach dem Komma haben.

In einigen Fällen (wenn die letzten beiden Ziffern eine 5 sind) soll verhindert werden, dass die letzte Ziffer gerundet wird. Ich habe verschiedene Parameter ausprobiert, aber habe keinen gefunden der das Runden vermeidet.

Seht ihr einen Parameter oder eine Kombination von Parametern, mit denen man das hinbekommen könnte?

Gruß ebody

  1. problematische Seite

    11.3.3

    Intl.NumberFormat.prototype.resolvedOptions ()

    This function provides access to the locale and formatting options computed during initialization of the object.

    The function returns a new object whose properties and attributes are set as if constructed by an object literal assigning to each of the following properties the value of the corresponding internal property of this NumberFormat object (see 11.4): locale, numberingSystem, style, currency, currencyDisplay, minimumIntegerDigits, minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, maximumSignificantDigits, and useGrouping. Properties whose corresponding internal properties are not present are not assigned.

    Wenn das die Optionen sind, die empfangen und gefunden werden, dann sollte man die auch setzen können.

    • Meine erste Idee wäre aber, NumberFormat() auf eine VORHER nach Deinen Regeln gerundete Zahl b anzuwenden und diese Methode nur unmittelbar für die Ausgabe zu benutzen. z.B.
    o.innerHTML=b.toLocaleString(
        'de-DE',
        { 
           style:    'currency',
           currency: 'EUR'
        }
    );
    

    Und was die Sache mit den letzten beiden Stelle betrifft: Du hast ja zunächst einen String. Willst Du wissen, wie man fest stellt, dass die letzten beiden Zeichen jeweils eine 5 sind? Jedenfalls dürfte toLocaleString() Deine sehr speziellen „Rundungs“-regeln eher nicht erkennen können. Also VORHER selbst „runden“. Bau Dir dazu eine Funktion.

  2. problematische Seite

    Hi,

    In einigen Fällen (wenn die letzten beiden Ziffern eine 5 sind) soll verhindert werden, dass die letzte Ziffer gerundet wird.

    das ist eine sehr ungewöhnliche Anforderung. Magst du mehr darüber verraten - vielleicht Beispiele, Anwendungszweck, oder wie du zu einer solchen Forderung kommst?

    Was noch am ehesten in die Richtung geht, bezeichnet man umgangssprachlich als Runden auf 2½ Stellen, wobei die dritte Stelle nur 0 oder 5 sein soll. Also 3.172 wird auf 3.170 gerundet, 3.174 aber auf 3.175.

    Das erreicht man, indem man den Wert zunächst verdoppelt, dann normal auf 2 Stellen rundet und das Ergebnis wieder durch 2 teilt. Hilft dir das eventuell weiter?

    Einen schönen Tag noch
     Martin

    --
    Fortschrittlich: In Kentucky ist es gesetzlich vorgeschrieben, mindestens einmal im Jahr zu baden.
    1. problematische Seite

      Hallo Martin,

      vielen Dank schon mal. Es kommt doch nicht darauf an, ob die letzten beiden Ziffern eine 5 sind, sondern ab 4 Stellen nach dem Komma soll nicht gerundet werden, bis 3 Stellen soll gerundet werden.

      Sinn und Zweck kann ich leider nicht sagen, es ist einfach eine Vorgabe.

      Gruß ebody

      1. problematische Seite

        n'Abend ebody,

        Es kommt doch nicht darauf an, ob die letzten beiden Ziffern eine 5 sind, sondern ab 4 Stellen nach dem Komma soll nicht gerundet werden, bis 3 Stellen soll gerundet werden.

        das verstehe ich jetzt nicht. Also 1.396 (drei Nachkommastellen) soll gerundet werden? Auf wieviele Stellen? Und 1.3967 soll nicht gerundet werden?

        Sinn und Zweck kann ich leider nicht sagen, es ist einfach eine Vorgabe.

        Das macht es schwierig, hier einen brauchbaren Hinweis zu geben.

        Einen schönen Tag noch
         Martin

        --
        Fortschrittlich: In Kentucky ist es gesetzlich vorgeschrieben, mindestens einmal im Jahr zu baden.
      2. problematische Seite

        Sinn und Zweck kann ich leider nicht sagen, es ist einfach eine Vorgabe.

        Vorsichtig und zurückhaltend ausgedrückt hätte der Vorgabenersteller mit mir alsbald das Problem, dass er das Angebot bekommt, „seinen Scheiß allein zu machen“. Denn womöglich schützt er sich vor Kritik an seiner Programmplanung in dem er den Kontext der Vorgabe nicht nennt. Oder traust Du Dich nicht zu fragen, bzw. zu sagen, dass es nach einer schlechten Idee klingt?

        Vorliegend würde ich nämlich vermuten, dass er eine universelle Behandlung von Daten aus ganz verschiedenen Kontexten haben will, dabei anhand von Eigenschaften der Daten (hier anhand der Nachkommastellen) und nicht anhand des Kontextes unterscheiden will. In jedem mir gegenwärtigem Szenario ist das ein Fehler.

        1. problematische Seite

          Hallo Raketenwilli,

          je nach Strukturierung eines Unternehmens hat der Programmierer tatsächlich nur stumpf Vorgaben umzusetzen, die von einem Requirement Engineer erstellt wurden. Der RE bekommt die fachlichen Vorgaben von einem Business Analyst, und der BA wiederum redet mit dem Fachbereich.

          Trotzdem ist es legitim, als Programmierer einen Blick auf Vorgaben zu haben und sich zu fragen, ob da Sinn hintersteckt oder Unsinn. Vor allem dann, wenn Vorgaben schwer umsetzbar erscheinen. Fachbereiche denken nämlich gerne mal zu viel und formulieren Dinge, von denen sie glauben, dass die Technik das gut versteht. De facto hätten sie das besser dem BA und RE überlassen und lieber formulieren sollen, was sie warum wollen. Aber leider...

          Rolf

          --
          sumpsi - posui - obstruxi