Eingabe von Dezimalzahlen (bis zu zwei Kommastellen)

[Torschti]

Hallo zusammen, das Ausgeben von zwei Kommastellen habe ich fein nach Lehrbuch hinbekommen. Kann mir jemand helfen, dies auch bei der Eingabe hinzubekommen? Wäre echt toll. Ich danke schon mal im Voraus. lg Torschti

 

[Oneixee5]

Die Klasse Scanner sollte klar sein. Ich gehe auch davon aus, dass ein Nutzer nicht unbedingt immer 2 Nachkommastellen eingeben muss. Wozu sollte man 3.00 eingeben, 3 reicht völlig. Wegen der Einfachheit wird ein String für die Auswertung verwendet:

public static void main(String[] args) {

      String s = "Hello World! 3 + 3.0 = 6 true";

      // create a new scanner with the specified String Object
      Scanner scanner = new Scanner(s);

      // use US locale to be able to identify doubles in the string
      scanner.useLocale(Locale.US);

      // find the next double token and print it
      // loop for the whole scanner
      while (scanner.hasNext()) {

         // if the next is a double, print found and the double
         if (scanner.hasNextDouble()) {
            System.out.println("Found :" + scanner.nextDouble());
         }

         // if a double is not found, print "Not Found" and the token
         System.out.println("Not Found :" + scanner.next());
      }

   }

Ausgabe:

Not Found :Hello
Not Found :World!
Found :3.0
Not Found :+
Found :3.0
Not Found :=
Found :6.0
Not Found :true

 

[KonradN]

Erst einmal muss ich sagen: Die Anforderung ist mir nicht klar! Was genau erwartest Du bei einer Eingabe von genau zwei Nachkommastellen?

Da sind also mehrere Punkte, die da interessant sind:
a) Was soll bei der Eingabe von 3 der 3.1 passieren? Soll das akzeptiert werden oder soll zwingend immer mit 2 Nachkommastellen eine Eingabe erfolgen?
b) Was soll bei der Eingabe von 3.123 erfolgen?

Hier ist also genau zu spezifizieren, was denn erwartet wird. Also Soll die Eingabe abgelehnt werden als illegale Eingabe? Oder soll die Eingabe angenommen werden und z.B, nur 2 Nachkommastellen berücksichtigt werden? Soll gerundet werden oder abgeschnitten?

Dann ist die Anforderung auch problematisch. Denn eine Dezimale Nachkommazahl mit 2 Nachkommastellen ist nicht zwingend in einem double abbildbar. Statt dessen wird ein Wert gespeichert, der mit möglichst großer Genauigkeit an diese Zahl heran kommt. Die Zahl 0.1 wäre so ein Beispiel. Das System gleicht das etwas aus, so dass Du tatsächlich die 0.1 angezeigt bekommst, aber wenn Du die Zahl z.B. als float nimmst und dann in ein double umwandelst, dann bekommst Du das mit. Also etwas wie:
double d = 0.1f; System.out.println(d);

Es gibt also prinzipiell einiges zu beachten.

In der reinen Programmierung hast Du die Begrenzung auf zwei Stellen im Code eher selten. Wenn sowas vorkommt (z.B. bei Geld!), dann sind diese Ungenauigkeiten durchaus mal schnell problematisch, weshalb man dann auf andere Lösungen setzt. (z.B. Beträge in Cent speichern oder die Nutzung einer Library wie z.B. JavaMoney) Und bei Grafischen Oberflächen begrenzt man dann die Eingabe z.B. im Textfeld.

Du hast in Deinem Code Werte Zeilenweise mit einem BufferedReader gelesen. Hier könntest Du in Deinem Code einfach das Integer.parseInt ersetzen durch Double.parseDouble. Dann hättest Du die Double Werte gelesen. (Ohne eine Abhängigkeit auf zwei Nachkommastellen. Es ist aber nicht notwendig, da vom BufferedReader auf einen Scanner zu wechseln!)

Ja nach Antwort zu den oberen Fragen kann man:

• den String vor dem Parsen prüfen, ob er die Anforderungen erfüllt (so dies wirklich erforderlich ist. Bei dem bisherigen Code glaube ich das irgendwie nicht).
• du kannst nach dem Parsen den Wert runden auf zwei Stellen (oder Abschneiden),

Hier ist aber dann wichtig, dass man die Anforderung genau beschreibt um diese dann entsprechend umzusetzen.

 

[KonradN]

der reguläre Ausdruck ist zu kompliziert gewesen (das kommt, wenn man copy-pasted ).

Je nach Anforderung sollte der einfach

"^\\d+\\.\\d{0,2}$"

sein.

Da würde ich den Bereich mit den Nachkommastellen noch optional machen, damit eine ganze Zahl auch angenommen wird (Also der Fall keine Nachkommastellen). Denn bei "bis zu zwei Nachkommastellen" ist das vermutlich auch mit inbegriffen.

Aber hier ist die Frage tatsächlich, was da genau die Anforderung ist.

 

[mihe7]

Meines Erachtens sollte man reguläre Ausdrücke nur einsetzen, wenn man ein klar definiertes Format zwingend einhalten muss, das mit Bordmitteln nicht oder nur schwer erzielt werden kann. Oft ist man bei der Ausgabe strikt, beim Einlesen lieber tolerant, aber auch das ist natürlich eine Frage der Anforderungen.

 

[mihe7]

Um das mal zu verdeutlichen:

1. Vorzeichen optional, Vorkommastellen ggf. mit optionalen Gruppierungen
2. Vorzeichen optional, Vorkommastellen (ggf. mit optionalen Gruppierungen) + Dezimalpunkt
3. Vorzeichen optional, Dezimalpunkt + Nachkommastellen
4. Vorzeichen optional, Vorkommastellen (ggf. mit optionalen Gruppierungen) + Dezimalpunkt + Nachkommastellen

Das ist schon einiges, was man für einen regulären Ausdruck berücksichtigen muss. Und die e-Notation ist damit auch noch nicht abgedeckt. Hinzu kommt, dass Dezimalpunkt, Gruppierungszeichen und -breite abhängig vom Gebietsschema sind.

 

[Torschti]

Erst mal vielen Dank für die Antworten. Ich benötige die Angaben für ein Programm für meinen Verein zur Berechnung des Strom- und Wasseverbrauch der einzelnen Kleingärten. Besonders beim Berechnen des Stromverbrauchs sind diese wichtig, z.B. für die Angabe von Offshorezulage 0,06 € oder anderer Zusatzparameter bei der Zusammensetzung der Stromkosten. Ich habe für den gesamten Verein (100 Kleingärten und 37 Garagen) nur einen Hauptstromanschluss und Untermessungen für jeden Garten und jede Garage separat. Bisher habe ich alles über Excel gerechnet, will aber für den Verein keine Office - Lizenz mehr nutzen. Jeder Garten hat noch eine Wasseruhr; hier reicht aber die Berechnung ohne Komma.

 

[KonradN]

Bisher habe ich alles über Excel gerechnet, will aber für den Verein keine Office - Lizenz mehr nutzen.

Evtl. ist es einfacher, über OpenOffice zu gehen als da alles selbst zu programmieren, denn da kommt ja noch einiges mehr zusammen.

Ansonsten haben wir natürlich noch nicht viel gesehen, aber ich habe den Eindruck, dass Du da direkt versuchst, etwas als Konsolen-Anwendung zu bauen. Der Ansatz bei so einer Anwendung sollte aber ein etwas anderer sein (aus meiner Sicht):

• Du könntest Dir einmal überlegen, was für Daten Du brauchst und daraus Dein Model entwickeln. Dann hast Du Klassen für die Kleingärten mit Zählern. Die Zähler haben dann Ablesungen (Also vermutlich ein Datum mit einem Zählerstand) und all sowas.
• Dann müssen darauf Operationen möglich sein. Unter anderem auch das Lesen und Speichern. Wobei das dann relativ einfach sein kann, wenn man z.B. So Daten in eine Datennbank speichert oder als JSON oder so. (Dazu gibt es dann Libraries, die eigentlich die ganze Arbeit übernehmen).
• Das Model würde ich dann etwas mit Unit Tests testen. Auch wenn man das noch nicht so sehr kennt, lohnt es sich, da automatische Tests zu haben. Das können ja noch ganz grobe Funktionstest sein wie neue Einträge hinzufügen und wieder auslesen und so ... Also mehr etwas wie Regression Tests als Unit Tests ...
• Dann kommt erst die Oberfläche. Das kann dann durchaus eine Konsolenanwendung sein, aber das macht es schnell deutlich komplizierter als es sein muss. Da kann es fast interessant sein, sowas wie Spring Boot mit Thymeleaf zu nutzen oder so. Aber das ist bei der Entwicklung der ersten Schritte erst einmal egal.

 

[Robert Zenz]

Erst mal vielen Dank für die Antworten. Ich benötige die Angaben für ein Programm für meinen Verein zur Berechnung des Strom- und Wasseverbrauch der einzelnen Kleingärten. Besonders beim Berechnen des Stromverbrauchs sind diese wichtig, z.B. für die Angabe von Offshorezulage 0,06 € oder anderer Zusatzparameter bei der Zusammensetzung der Stromkosten. Ich habe für den gesamten Verein (100 Kleingärten und 37 Garagen) nur einen Hauptstromanschluss und Untermessungen für jeden Garten und jede Garage separat. Bisher habe ich alles über Excel gerechnet, will aber für den Verein keine Office - Lizenz mehr nutzen. Jeder Garten hat noch eine Wasseruhr; hier reicht aber die Berechnung ohne Komma.

Also eigentlich willst du irgendwas in der Form einer Low-Code Plattform. So ziemlich alle davon sind aber kommerziell, also vielleicht nicht so interessant wenn du nicht gerade eine Probeversion bekommst welche ausreicht.

Ansonsten ist der Vorgang genauso wie @KonradN gesagt hat, zuerst Anforderungen sammeln, daraus eine Datenstruktur entwickeln und dann am besten eine grafische Oberflaeche dazu, weil, sehen wir's ein, du wirst eine grafische Oberflaeche wollen.

Hehe, als ganz dumme Idee, wenn die Berechnung recht gerade und einfach sind, koenntest du dir sowas sogar mit jMathPaper bauen. Also jMathPaper ist ein Projekt von mir wo ich mir einfach einen Rechner bauen wollte der genau so funktioniert wie ich mir das vorstelle, quasi eine einspaltige Tabellenkalkulation. Man kann Variablen und Funktionen definieren, und man kann auch Dateien laden und speichern. Also theoretisch kann man sich auch komplexe Berechnungen bauen solange man sie als eine lange Liste an Rechnungen/Operationen ausdruecken kann.

Ich hatte gerade ueberlegt dass man eigentlich sich sowas schreiben koennen sollte:

ANZAHL_GRUNDSTUECKE               37
STROM_2022                      5960.41
STROM_2022/ANZAHL_GRUNDSTUECKE

Und dieses dann laden, aber der Lade-Code ist dafuer leider (noch?) nicht ausgelegt und nicht flexibel genug. Es muss mit etwas Zusatz geschrieben werden:

$ ANZAHL_GRUNDSTUECKE=37 =
$ STROM_2022=5960.41 =
STROM_2022/ANZAHL_GRUNDSTUECKE

Aber das kann man dann einfach laden und bekommt sowas:

ANZAHL_GRUNDSTUECKE         ANZAHL_GRUNDSTUECKE=37 =                                37
STROM_2022                      STROM_2022=5960.41 =                          5,960.41
#1                  STROM_2022/ANZAHL_GRUNDSTUECKE = 161.09216216216216216216216216216

Optionen (setzen vom Zahlenformat) kann man auch nicht laden, bin ich etwas enttaeuscht von mir, haette ich besser bauen koennen den Code.

 

[KonradN]

Also eigentlich willst du irgendwas in der Form einer Low-Code Plattform. So ziemlich alle davon sind aber kommerziell, also vielleicht nicht so interessant wenn du nicht gerade eine Probeversion bekommst welche ausreicht.

Das ist ein guter Hinweis. Und das kann man ja durchaus einmal etwas beleuchten / ein paar Links geben!

a) Eine Low-Code Plattform, über die ich gestolpert bin: FlutterFlow - Build beautiful, modern apps incredibly fast!

Da gibt es auch einen kostenlosen Account und mit dem kann man ggf. sowas bauen. API und data integration ist da bereits mit drin, aber ich weiss nicht, in welcher Form. Es scheint auf Firebase gesetzt zu werden, was dann da ggf. Kosten verursacht (Habe ich schon lange nicht mehr geschaut).

Generell ist hier aber die Gefahr gegeben, dass so ein kostenloser Account auch einmal eingestellt werden kann.

b) The best time-to-market for Java - OpenXava
OpenXava ist eine freie Lösung. Es gibt da zwar auch noch XavaPro, aber das braucht man gerade am Anfang nicht. User, Module und all sowas ist bei so einer Lösung vermutlich nicht besonders interessant.

Hier ist aber die Problematik, dass man eben etwas baut, das einer Java EE Anwendung entspricht und die will gehostet werden. Das kommt dann mit gewisser Komplexität daher. Wenn man aber nur einen User hat, dann nutzt man ggf. die Entwicklungsumgebung.

c) High productivity application development platform (jmix.io)
jmix ist der Nachfolger von Cuba. Es beruht auf einem Open Source Kern, der frei verfügbar ist. Aber man hat dann halt nicht den vollen Editor. Mit Subscription hat man dann einen Editor und alles wird total easy: Man gestaltet seine Data Entities in der Entwicklungsumgebung, erzeugt darauf seine Screens und hat dann auch seine vollwertige Java Enterprise Anwendung (mit Spring Boot / Vaadin Basis)
Wenn man es ohne den Editor versucht und alles so aufbaut: Warum nicht. Aber das kostet viel Zeit.

d) JHipster - Full Stack Platform for the Modern Developer!
Das ist auch ein interessanter Ansatz für eine Full Stack Lösung. Man bekommt Frontend und Backend beides zusammen.

Meine Bewertung

So interessant das auch alles zu sein scheint: Ich selbst halte von diesen Lösungen relativ wenig. Ich bin da streng genommen gleich zwei Mal heftig auf die Nase gefallen.

Erst einmal meine Erfahrung:
1) Microsoft Lighswitch (Schon eingestellt)
Das war eine interessante Lösung. Man hat seine Entities erstellt und darauf dann sein Frontend zusammen geklickt. Das ging erstaunlich gut.
Das Thema hat aber eine gewisse Komplexität - das hat sich bei Fehlern böse bemerkbar gemacht - der Anwender hat dann mal eben 10-30 kryptische Fehlermeldungen wegklicken müssen. Und Das war dann schwer zu finden. Ein Fehler war mal, dass ich etwas nach "Anleitung" gemacht habe und die war leider nicht ganz korrekt. MSDN Forum war da dann sehr hilfreich

Das zweite Problem sind Anpassungen. Es ist toll: Man klickt sich eine Lösung zusammen. Das Kernproblem damals war: Entwicklungsteam war ausgelastet. Andere hatten eine MS SQL Datenbank erstellt und dazu brauchte es dringend ein Frontend. Dann habe ich mit Lightswitch mal eben eine UI zusammen geklickt und deployed (Alles an nur 1 Tag!). Also 1 Tag bis Produktion für eine komplexe Datenbank: Das war schon etwas

Aber dann kamen weitere Anforderungen und die waren dann plötzlich nicht 1:1 umsetzbar. Dann find die Suche nach Workarounds an. Das kostet mehr Zeit, als es einmal richtig zu machen.

Und dann das Problem von Updates. Es war enorm nervig, dass kleine Anpassungen an der Datenbank plötzlich irgendwo etwas kaputt gemacht haben. Du änderst etwas an Tabelle1 und bei einer anderen Tabelle, an der nichts geändert wurde, gehen die Screens nicht mehr.
==> Enormer manueller Testaufwand.

2) cuba (jetzt jmix)
Das lief auch super. Damit habe ich dann auch auf die Schnelle eine Lösung für eine existierende Datenbank gebaut. War echt super.
-> Reporting funktioniert manchmal aber nicht. Bei mir waren es dann teilweise viele Daten und da gibt es irgendwelche Probleme. War aber nicht analysierbar. Extrem nervtötend
-> Problem mit Updates. Bei einem cuba Update war dann das Projekt nicht mehr aktualisierbar. Das war der Punkt, an dem ich es dann fallen gelassen habe!

Mein Fazit:

1. Komplexität zu verstecken ist nicht gut! Wenn man die zugrunde liegende Technik nicht kennt und nicht im Zugriff hat, dann ist man bei Problemen auf verlorenem Posten! Das funktioniert nur in Bereichen, in denen die Komplexität gut dokumentiert und durch eine breite Masse benutzt wird! (Also typische Beispiele wie Spring Boot, Quarkus, Angular, React, ....) Also vulgär ausgedrückt: "Selbst wenn es sich als Schei.... heraus stellen sollte für Dich: Du hast Millionen Fliegen, die Dir helfen können, weil sie drauf fliegen"

2. Anpassungen: Immer wenn Du plötzlich Anforderungen hast, die so nicht vorgesehen sind, hast Du ein massives Problem. Du bist bei RAD Tools halt nur noch auf einem hohen Level unterwegs. Anpassungen im Low Level Bereich sind einfach nicht vorgesehen! Das muss einem klar sein!

3. Es ist deutlich entspannter, etwas von der Basis aufwärts zu lernen. Es ist sehr nervtötend, wenn Du irgendwo auf hohem Level bist und dann in andere Technologien einsteigen musst, um da einen Fehler zu verstehen oder so. Und wenn Du mit der Basis anfängst, dann hast Du solides Wissen und kannst damit auch leichter auf neue Versionen adaptieren.

==> Mein Tipp ist ganz deutlich: Eine saubere Basis nutzen. Ein Low Code Tool sehe ich als nicht wirklich zielführend, wenn es um die Produktentwicklung geht. Wenn man nur für sich Daten verwalten will: Excel und co. Das wurde schon eingesetzt, das ist bekannt. Der Wechsel zu OpenOffice oder so dürfte nicht zu schwer sein.
Ansonsten eine solide Basis nutzen. Das kann Spring Boot mit Thymeleaf sein (Setzt aber auch HTML voraus. Nicht so durchdacht von mir, als ich es genannt habe) oder einfach Vaadin. Zu Vaadin gibt es gute Videos und man kann alles rein in Java aufbauen. Sowas in der Art sehe ich eher als zielführend und vor allem lernt man dann (hoffentlich) die Grundlagen. Das hilft einem dann in Zukunft auch weiter.

 

[Robert Zenz]

@KonradN Sehr guter Beitrag! Ich stimme aber mit deinem Konklusio nicht ganz ueberein, gerade fuer so "Kleinstprojekte" mit sehr eng definierten Verhalten und Ziel denke ich dass ein Low-Code-Teil sehr gut funktionieren kann. So viel erzeugt man da nicht, Datenmenge hat man auch keine Nennenswerte und gegenueber Tabellenprogrammen kann das schon ein guter Gewinn sein. Wenn man ein Programm hat welches man nach Kundenwunsch und Kundebeduerfnissen ueber die naechsten zehn Jahre weiterentwickelt und erweitert, dann kann so ein Low-Code-Teil wirklich im Weg stehen wenn es nicht genau fuer diesen Bereich gedacht ist. Verdammt, das gleiche Problem hatte ich auch schon mit Spring (ist halt Kacke wenn man ploetzlich Anforderungen hat ueber die die Spring-Heinis noch nie nachgedacht haben). Das "richtige" Low-Code-Werkzeug aussuchen und dann noch die Sache dass eigentlich alle kommerziell sind ist aber ein Problem.

 

[Torschti]

Ok, ich denke verstanden zu haben. Mit diesem Projekt verabschiede ich mich erst mal. (Ein Sreenshot im Anhang zeigt die Excel - Variante). Ich werde aber sicher noch ab und an mal "vorbeikommen".