Hey all.

Rechnen mit Strings ist mit + und - ja ur easy.
Ich habe irgendwann versucht ein Programm zu schreiben was PI annährt, aber der DOUBLE-wert ist auf 16 stellen nach dem komma abgebrochen.

Nun habe ich überlegt wie ich ungenauigkeiten verhindern kann, und bin zu dem Schluss gekommen, das zumindest + und - wunderbar als String behandelt werden können, so ist es möglich Zahlen in N-Stellenbereich zu addiren oder Subtrahieren.

Nur wie sieht es aus mit * und /.... Weil:

15023 / 239 ~ 62,86

Als String würde ich immer 3er blocks nehmen, nur würde dann
"023" / "239" = 0,096
und
"15" / "0,239" = 62,761

0,096 + 62,761 ~62,86
ergeben auch 62,86 aber da muss ich auch wieder mit Variablen arbeiten...


Gibt es irgendeine Möglichkeit quasi nur mit Int werden einen String durch einen String zu teilen?
Ich dachte bevor ich wieder irgendwas kaputtes ausdenke schmeiße ich diese These mal ins Forum mal sehen wer hier konstruktive Kritik ansagt.
Währe mal an eurer Meinung interessiert ob mein kleines vorhaben (die 4 Rechengrundarten nur mit Strings und Ints durchzuführen) aufgeht...

Dann gibs ja noch Extended.Ich meine mit 20 Stellen hinter'm Komma!

Naja es geht jetzt ja um meine These mit String-rechnerei...

Sowas hab ich mir auch schon überlegt. 20 Stellen nach dem Komma... Naja, aber irgendwo her muss das ja kommen, dass so viel mehr Stellen bekannt sind.

Wie hast du das mit dem Pi gemacht? Ich hatte das mal so, natürlich aber mit Standardtypen:



Und natürlich mit deg als Winkelformat. Du kannst diese Rechnung natürlich nicht für Forschungszwecke gebrauchen, weil du ja sonst DEG wieder in RAD umrechnen müsstest, und dann wird ja mit dem vorhandenen, "ungenauen" Pi gearbeitet.

Zu deinem Problem: Rechne doch einfach schriftlich, so wie man das in der Schule gelernt hat.

Abgesehen davon das ich ca. 0 Verstanden habe...
Wikipedia -> Kreiszahl PI -> formel suchen...


Und dann mit Double arbeiten, ist aber wegen compiler-ungenauigkeit bei 16 tellen nach dem komma abgeriegelt.


Das ding ist mit dem String könnte ich die Stellen nach dem komma wiederum al ganze Zahl verwenden und somit unendlich stellen als Zahlenwert haben.
Egal wieviele Stellen vor oder nach dem Komma, solange die Festplatte ausreicht, is alles Chillig.
Man könnte es sogar so umwandeln dass man pro Byte 256Zahlen speichern könnte...


Aber erstmal müsste ich die Grundrechenarten damit rechnen können...
Ich weiß aber nicht ob ich dafür genug Kopf habe, um alles so hinzubiegen das möglichst keine komma-zahlen beim rechnen entstehen...

Das ist keine Compilerungenauigkeit sondern eine Prozessorungenauigkeit. Ich würde dir auch vorschlagen, dass du einfach wie in der Schule in der dritten Klasse Zahlen addierst. Gerade mit Multiplikation und Division geht das selbst bei Kommazahlen praktisch analog zu ganzen Zahlen. Nur beim addieren und subtrahieren musst du bei Kommazahlen die strings dann üblicherweise "ausrichten".

Es gibt hierzu eine Menge Threads im Forum die teilweise bignum heißen unter langzahlarithmetik sollte man auch was finden und große Zahlen erst recht.

Ich würde auch empfehlen statt strings ein

zu nehmen, oder gleich mit der basis 256 zu rechnen (Speichersparender).

Boldar hat folgendes geschrieben :

... oder gleich mit der basis 156 zu rechnen (Speichersparender).

Meinst wohl 256?

ja...
habs oben korrigiert.

Theoretisch wär doch auch möglich, mit BigNum und auf Basis des wissenschaftlichen Formats zu rechnen:


Wenn du für x und n jeweils ein BigNum einsetzt, kannst du beliebig genau rechnen. Im Gegensatz zur Normdarstellung allerdings rechnest du mit einer ganze Zahl für x, die Kommaverschiebung ist in n gespeichert.

Die Methode als solches ist eig. schon ziemlich speicherschonend.

Jap. bedarf aber etwas Book Keeping. Hierzu einfach mal die Implementierungen von BigNum_Lib und Bignum2 vergleicht.

In BigNum2 ist dieses Book Keeping bisher nicht implementiert, dazu fehlt mir bisher die Zeit ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.