Nicht float, sondern decimal

volkard

akari schrieb:

Hallo

In Builder gibt es den Datentyp Currency, der eine Festkommazahl darstellen soll.
Ich würde aber empfehlen lieber int oder __int64 zu verwenden, und lieber in Cent-Werten statt in Euro-Werten zu rechnen.

bis bald
akari

Decimal hat nichts mit Korrektheit zu tun - es geht um Nachvollziehbarkeit.
Problem 1: Kannst Dich auf den Kopf stellen, wenn Du 1000000000 Euro fair auf drei Parteien verteilen sollst, macht ein Cent verschwindibus.
Problem 2: Es gibt Fälle, wo man gar nicht gut vorhersagen kann, von wo er verschwindet.
Und jetzt haben sich Kunden b4eschwert, daß das Programm falsch rechnet. Da kann man nur Decimal nehmen, denn wenn der Chef, der von Diskreter Mathematik oder von der internen Darstellung von Fließkommazahlen nach IEEE keinebn Schimmer hat, zu Dir geht, und mal genau wissen will, wohin der Cent verschwunden ist, was machste da? Ihn erst auf ne Vorlesung zu DM schicken? Oder sagen "Lies erstmal http://de.wikipedia.org/wiki/Gleitkommazahl . Erst danach bin ich bereit, mich mit Dir darüber zu unterhalten." Nö, ich denke, das wäre nicht so toll.
Decimal bringt's, denn nun rechnet der Rechner bis in die letzte Stelle wie in der Grundschule und ist Chefkompatibel. Fehler kann man jagan, nachvollziehen und erklären.

Aber Decimal ist nicht korrekter als was anderes. Es ist nur für Außenstehende leichter nachzuvollziehen, dafür frißt es 10-mal mehr Rechenzeit.

witte

volkard schrieb:

Decimal hat nichts mit Korrektheit zu tun - es geht um Nachvollziehbarkeit.
Problem 1: Kannst Dich auf den Kopf stellen, wenn Du 1000000000 Euro fair auf drei Parteien verteilen sollst, macht ein Cent verschwindibus.

Und wie löst das decimal? In dem es dir sagt dass du einen Cent durchzusägen hast?

volkard

witte schrieb:

volkard schrieb:

Decimal hat nichts mit Korrektheit zu tun - es geht um Nachvollziehbarkeit.
Problem 1: Kannst Dich auf den Kopf stellen, wenn Du 1000000000 Euro fair auf drei Parteien verteilen sollst, macht ein Cent verschwindibus.

Und wie löst das decimal? In dem es dir sagt dass du einen Cent durchzusägen hast?

Indem es sich ganz normal verrechnet, nämlich nicht anders, als der Chef, der es auf einem Blatt Papier mal nachrechnet.

Braunstein

Wenn euch das Thema Festkommaarithmetik so interessiert habe ich hier mal zwei Links für euch
Allgemeine Erläuterung
http://en.wikipedia.org/wiki/Fixed-point_arithmetic
Die englische Version ist besser als die deutsche.

und hier etwas schöner (ganz oben)
http://www.digitalsignallabs.com/papers.htm

-**xXx**-

Da schließt sich für mich mal eine Frage an:
Wenn ich eine Rechnung schreibe über einen Artikel für 2,99€ zzgl. 19% Steuer und davon 100Stk., wie berechne ich die Steuer richtig?

A)
2,99€*0,19 = 0,57€
0,57€ * 100Stk. = 57€

oder

2,99€*100*0,19 = 56,81€

mfg
xXx

Jansen

Die Mehrwertsteuer wird auf die Gesamt-Nettosumme einer Rechnung erhoben, also B.

volkard

-=]xXx[=- schrieb:

Da schließt sich für mich mal eine Frage an:
Wenn ich eine Rechnung schreibe über einen Artikel für 2,99€ zzgl. 19% Steuer und davon 100Stk., wie berechne ich die Steuer richtig?

A)
2,99€*0,19 = 0,57€
0,57€ * 100Stk. = 57€

oder

2,99€*100*0,19 = 56,81€

Scherzkeks.
2,99100/0,81=369,14
369,14-2,99100=70,14

KlausB

Hallo

noch besserer Scherzkeks

2,99 * 100 = 299,00
MwSt = 299,00 * 0,19 = 56,81
ges: 355,81

Mfg
Klaus

volkard

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

VergissEs

volkard schrieb:

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

Schlagen würden die dich nicht, aber sicher richtig nachrechnen:

355,81 / 1,19 = 299,00
299,00 * 0,19 = 56,81

und dann kommen die auf die 19%

maikmueller

...ein Thema mit dem ich mich auch gerade rumschlage, aber zurück zur Frage, wie lautet denn nun der genaue Datentyp, "decimal" bzw. "Decimal" kennt der Builder ja nicht...

Wäre toll wenn jemand kurz Helfen könnte...

Gruss

Maik

akari

Hallo

akari schrieb:

In Builder gibt es den Datentyp Currency, der eine Festkommazahl darstellen soll.

bis bald
akari

berniebutt

Currency ist kein echter Datentyp, sondern eine Struktur mit zwei Integers für Vorkomma- und Nachkommastellen. Die Anzahl der Nachkommastellen soll auf 4 beschränkt sein. Ist für Dinge mit Geld gedacht. Löst aber auch nicht alle Probleme. Z.B. bei Zinsberechnungen gibt es nun einmal leicht viele Nachkommastellen. Irgendwo muss bei Integer etwas "verschwinden". Ich bleibe bei float und double und runde selbst, wo ich es für nötig befinde.

Hier soll schon einmal ein Bankangestellter die "abgeschnittenen" Zinserträge zu seinem Gunsten addiert und auf sein eigenes Konto überwiesen haben. Musste nur noch die Überweisung aus dem Datenbestand entfernt und ein anderes Bankprogramm ohne "Abschneidung" angepasst werden. Ist aber aufgefallen!

Das Thema liegt darin: Rechnen kann man beliebig genau. Die Bewegungen auf einem Konto sind aber auf Cent begrenzt.

volkard

VergissEs schrieb:

volkard schrieb:

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

Schlagen würden die dich nicht, aber sicher richtig nachrechnen:

355,81 / 1,19 = 299,00
299,00 * 0,19 = 56,81

und dann kommen die auf die 19%

Nimm einfach mal einen Kassenbon und rechne nach, ub Du mit Deiner Rechnung 16% oder 19% hast.

-**xXx**-

volkard schrieb:

VergissEs schrieb:

volkard schrieb:

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

Schlagen würden die dich nicht, aber sicher richtig nachrechnen:

355,81 / 1,19 = 299,00
299,00 * 0,19 = 56,81

und dann kommen die auf die 19%

Nimm einfach mal einen Kassenbon und rechne nach, ub Du mit Deiner Rechnung 16% oder 19% hast.

Hä?

Gesamtsumme:
€ 56,85*
inkl. 19% MwSt. € 9,08

(Gesamtsumme - MwSt) * 0,19 = 9,0763
=> Die MwSt sind 19%, nix mit 16...

Edit: Oder is mein Ironiedetektor hinüber?

volkard

-=]xXx[=- schrieb:

Edit: Oder is mein Ironiedetektor hinüber?

Nein. Ich kann einfach keine Prozentrechnung. Muß mal meinen Mathelehrer danach fragen.

witte

Fowler hat sich mal Gedanken um eine "perfekte" Money-Klasse gemacht. Hier hat sich ein Student dran versucht:
https://kaul.inf.fh-brs.de/wiki2/index.php/Money

berniebutt

@volkard Der Mathelehrer hat gesagt: Prozent heisst 'Anteil von Hundert'. Wenn du 100 Hühner hast und 10% davon legen täglich ein Ei, so hast du 10 Eier jeden Tag. 10,5 % Hühner können aber keine Eier legen, weil es weder halbe Hühner noch halbe Eier gibt. So ähnlich ist das mit allen Berechnungen bei Geldbeträgen auch, wenn alles auf ganze Cent sein soll. Hierin liegt die Frage!

VergissEs

volkard schrieb:

VergissEs schrieb:

volkard schrieb:

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

Schlagen würden die dich nicht, aber sicher richtig nachrechnen:

355,81 / 1,19 = 299,00
299,00 * 0,19 = 56,81

und dann kommen die auf die 19%

Nimm einfach mal einen Kassenbon und rechne nach, ub Du mit Deiner Rechnung 16% oder 19% hast.

Kommt auf den Rechenweg an.
Rechnet man Finanziell (was ja bei einem Kassenbon üblich ist) also mit Netto+Tara=Brutto dann kommt 19% raus.

Rechnet man als Mathematker "ala" nun ist das Brutto die 100% dann kommen die 15,97% raus.

Und was sagt uns das jetzt ?

Als Mathematiker muss man nur die 15,97% bezahlen alle anderen 19%, also Leute alle Mathematik studieren dann müsst Ihr weniger Steuern zahlen

Nun ja, meiner bescheidenen Meinung nach sollten beide auf das gleiche Ergebnis kommen.

volkard schrieb:

Aber
56,81/355,81=0,1597=15,97%
, ich glaube, das Finanzamt würde mich hauen, wenn im Verkaufspreis von 355,81 nur 16% Mehrwertsteuer drin wären.

Wie VergissEs schon geschrieben hat, gehst Du einfach von der falschen Basis aus. Die 355.81 sind nicht 100%, sondern 119%, da schon inkl. MwSt.