PureBoard

Hab es mir gerade mal kurz angeschaut und muss sagen das Include gefällt mir kann ich gewiss mal brauchen wenn es fertig ist. Werde es morgen mal noch gründlicher testen dann kann ich dir vielleicht noch etwas mehr Feedback dazu geben.
Was das „Sowas wie nächte Primzahl nach 10^100 ist in Arbeit“ angeht darauf bin ich auch mal gespannt habe in letzter Zeit ja etwas mit Primzahlen experimentiert.

mfg Christian+

STÅRGATE hat geschrieben:eine Million hoch eine Million
wäre eine 1 mit 9 Millionen Nullen diese Zahl rechnet das Programm zwar schnell aus aber darf nicht mehr als String dargestellt werden ! weil 9 Millionen Nullen ca 9 GIGABYTE ! verschligen würden.

Also bei mir sind neun Millionen Bytes (ASCII bzw. UTF8) ja immer noch neun Megabyte.

jo habs korrigiert : 1'000'000'000 ist natürlich Milliarde und damit wäre es tatsächlich 9GigaByte wenn ich das hoch eine Milliarde nehme

Um mal zu zeigen, dass Interesse besteht:
Ich hab vor langer Zeit intensiv nach etwas dergleichen gesucht,
und bin nicht wirklich fündig geworden.
(Eine alte Userlib von... Freedimension? Hat aber nicht mehr funktioniert)
Leider studiere ich jetzt sein ein paar Monaten Informatik und werde gerade mit den Midterms zugehagelt.
Danach werde ich dein Inlude gerne mal ausgiebig testen

So, ich habe nun mal n paar Fragen an die Tester :

Division
Dort kann man ja eine Precision angeben, derzeit bezieht sich das auf die Anzahl der Nachkommastellen ...
Problem ist das dadurch der "Sinn" der Präzision verloren geht, denn wenn man 1/1000 dividiert und nur Precision=2 angibt kommt 0 raus ... sinnvoller wäre meiner Meinung nach hier die echte Präzision zu nutzen, also anzahl der Ziffern.
was dann jedoch zur Folge hat das 1024/2 mit Präzision 2 nur noch 510 wäre weil 5 und 1 bereits zwei Ziffern sind.
dafür kommt bei 1/400 das richtige raus: 0.0025
Präzision gibt dann also wirklich den Platz der Dezimalzahl an, denn 1·10²² verbraucht den gleichen Platz wir 2·10³²³, denn beide sind halt nur von der Präzision her eine stelle genau ...
Was sollte ich euer Meinung nach benutzen, oder eine Art Kombination ?


Runden
Das Runden ist auch wieder die selbe sache .... Dort würde ich es auch so machen, das Volgende Zahlen so gerundet werden:
Runden mit Präzision 3: RoundDecimal()
123456789 --> 123000000
987654 --> 988000
0.123456 --> 0.123
0.000456789 --> 0.000457
Als Abwandlung würde ich dann ncoh ein Abschneiden (ohne Runden) nach dem Komma einbauen:
Abschneiden nach 3. stelle nach dem Komma: CutDecimal()
0.123456 -> 0.123
0.000456789 -> 0
0.000789 -> 0


Stand der Dinge:
- Berechung von e und π schneller gemacht
- Write- und Read-Decimal für Datein
- Mehr Typenumwandlungen Decimal <-> String, Integer, Double
- Was ich jetzt verbessere ist: Dividieren, warum dort immer wieder Bugs (ungegelmäßig) auftreten ist mir unklar ...
unteranderem werden Felder in einer Dezimalzahl negativ, was garnicht sein darf
Genauso verstehe ich nicht, wieso mein Pi bei 200 Stellen irgendwo in der mitte genau 3 Ziffern anders sind

Update kommt vermutlich irgendwann am Wochenende

So Leute, das ist jetzt erst mal die vorläufig fertige Version:

Decimal.pbi
(Link aktuallisiert 9.7.2010)

Alles läuft soweit stabil, nur Wurzeln ziehen ist bei hohen Zahlen (woführ es ja eigentlich gedacht ist) zu langsam.
Es ist dort eindeutig der Falsche Weg das ganze als Iteration laufen zu lassen, zumal die genauigkeit darunter leidet!

Der seltsamme Bug in "Pi" ist immer noch da:
mein Pi
3.141592653589793238462643383279502884197169403375105820974944592307816
echtes Pi
3.141592653589793238462643383279502884197169399375105820974944592307816

Da liegt irgendwo ein Übertragfehler bei Addition oder Multiplikation vor, denn ein genauigkeitsfehler ist es nicht, da er immer auftritt egal wie genau ich Pi errechnen lasse.

Also vorerst viel spaß mir dem Include, bei Detail-Fragen könnt ihr mich auch direkt (PN, ICQ) ansprechen, um das Thema hier nicht "zu zu texten".

Irgendwann nach Weihnachten werde ich mich mal hinsetzen und eine Detailierte Hilfe schreiben

Tachchen,

leider gibs noch keine neue Version des Decimal-Include, trotzdem will ich euch aber auf dem Laufenden halten:

Wie ihr vllt selber schon gemerkt habt, sind meine Prozeduren zwar schneller als viele andere Beispiel beim rechnen von großen Zahlen, jedoch können sie immer noch nciht mit "großen" Programmen mithalten.
Darum führe ich nun intensive Geschwindigkeits-Tests durch, welche schon in den Grundrechenarten anfangen.

Gundlegende Sachen, wie die Doppelschleife beim Multiplizieren, werde ich kaum wegbekommen.
Somit wird es dort weiterhin einen Quadratischen anstieg der Rechnezeit geben, wenn die beiden Faktoren linear steigende Längen haben.
Trotzdem konnte ich die Rechenzeit von TimesDecimal halbieren, indem ich den Übertrag beim Addieren besser "eingebunden habe".

Desweiteren muss ich mir übenlegen, ob und wieviel Speicher ich reservieren könnte, um Prozeduren in denen viele neue zwischen Speicher erstellt werden, zu beschleunigen, indem ich ein großen erstelle in dem ich mich dann bewege.

Auch habe ich überlegt nun nicht mehr mit AllocateMemory speicher für Dezimalzahlen zu reservieren, sonden eine Structure mit einem Array zu nehmen.
Leider habe ich dabei festgestellt das dort ein Array langsammer "ReDim't" als ein Speicher "ReAllocate't"

Leider habe ich auch noch keinen Weg gefunden, der es mit erlaubt "einfacher" mit errechneten Dezimalen zu hantieren.
Denn wenn man hier die Prozeduren falsch nutzt, kommt es sehr schnell zu Speicherüberfüllung.

Wenn man sowas hier macht: Dann würde hier bei normalen Integers "c" immer wieder überschrieben werden.
bei meinem Code. würde zwar immer wieder *Decimal selber überschrieben werden, jedoch würde der Speicher der alten Zahlen weiterhin im Speicher bleiben.
Es wäre immer "nerviges mitschleifen" von FreeDecimal() nötig.

Vllt werde ich das nun so lösen, indem ich keine Rückgabe von Dezimalzahlen mehr erlaube.
Stattdessen muss man die "Result-Varable" immer mit in den Parametern angeben. Falls dann dort *ResultDecimal bereits einene SpeicherAdresse hat, wird diese automatisch freigegeben.

Eine andere Variante wäre, wenn ich mit Interface arbeite Wäre nett, wenn der eine Oder andere dazu ein paar Tips/Ideen hätte.

STARGÅTE hat geschrieben:Gundlegende Sachen, wie die Doppelschleife beim Multiplizieren, werde ich kaum wegbekommen.
Somit wird es dort weiterhin einen Quadratischen anstieg der Rechnezeit geben, wenn die beiden Faktoren linear steigende Längen haben.
Trotzdem konnte ich die Rechenzeit von TimesDecimal halbieren, indem ich den Übertrag beim Addieren besser "eingebunden habe".

Ich hatte da mal eine schnellere Multiplizier-Methode gepostet, am besten bindest du die ein:
Karatsuba-Algorithmus

Eine andere Variante wäre, wenn ich mit Interface arbeite

Code: Alles auswählen

*ResultDecimal\TimesDecimal(*Decimal1, *Decimal2)

Wäre nett, wenn der eine Oder andere dazu ein paar Tips/Ideen hätte.

So würde ich es nicht ganz machen.
Vielleicht so. Solche Sachen stelle ich mir da vor. Schade nur, dass man in PB keine Methoden überladen kann.

Danke NicTheQuick,

Hab mir gerade den Wiki-Artikel dazu durchgelesen ...
Werde mal versuchen es einzubinden.
Da ich eh bei meinen Zahlen mit einer Magnitude rechne, sollte das sogar noch schneller sein.
Weil ich halt normal multiplizieren kann und diese Basis-Erweiterung automatisch dabei ist.
(wenn ich das richtig gesehen habe)


Im Prinzip verwende ich diese Methode "des Halbierens" schon bei Power()
Da ich dort bei 2^16 nicht 16 mal *2 nehme, sonden den Exponenten zerlege sodass es nur noch das hier ist:
(((2^2)^2)^2)^2 Sodass nur noch 2*2 -> 4*4 -> 16*16 -> 256*256 gemacht wird also 4 multiplikationen.

Danke für die Ideen bei dem Interface.
Die Idee mit dem \times() gefällt mir sehr, so wären alle Vorteile dabei ... jenachdem ob man nur dazu multip. will oder eine neue Zahl haben will, ohne die alten zu verlieren.


EDIT:
Nach meinem ersten Test ist Karatsuba bei mir langsammer ...
Karatsuba: 27,4 µs
Meins: 5,63 µs
Multiplikation von zwei 2568-Stelligen Zahlen

Allerding wird der Karatsuba schneller wenn ich wirklich nur noch größere Zahlen spalte.
Du hattest ja : "Bei weniger als 4 Stellen nutze die Schulmethode"
Das ist bei mir wahrscheinlich zu wenig ...
weil dann die Zeit der zusätzlichen Speichererstellung, die verbesserung des Spaltens wieder futsch macht.

Aber ich bleibe dran ...

Na toll, die Include kannte ich ja gar nicht. Hab mich seit ner Woche an sowas rangewagt. Aber naja ich werd mal weiter machen. Vielleicht is ja meine Funktionen schneller . Und wird vielleicht auch ein paar mehr Features haben . Konkurrenz belebt ja das Geschäft.
Was ich aber sagen muss, unsere beiden Ansätze sind schon verblüffend ähnlich. Also ich habs nur mal überflogen. Ich will nur anmerken, falls ich meine Include rausbringe, dass ich also nichts abgeguckt hab . Ich kenns ja auch erst seit heute.
Na also dann, möge der bessere Programmierer gewinnen (oder so ähnlich) .

lg kevin