Denke Wolfram Research wird ihren eigenen Kram haben, aber der Rest der Welt kann sowas nutzen
https://en.wikipedia.org/wiki/GNU_Multi ... ic_Library
https://en.wikipedia.org/wiki/GNU_MPFR
Spacerat hat geschrieben:Das war aber nicht mein Anliegen. Die Frage war, ob man, wie in Java oder anderen Sprachen auch, die Genauigkeit von Konstanten explizit berechnen muss oder ob das diese Programme selbstständig machen, wenn man irgendwo im Code BigFloats verwendet.
Spacerat hat geschrieben:In Java also statt "java.lang.Math.PI" BigMath.pi(int precision) aufrufen muss. Ich vermute mal, dass es in Mathematica auch einen Unterschied macht, ob man die Formelsymbole vor der Verwendung mit höherer Genauigkeit neu definiert oder schlicht die Standardwerte durch simples nutzen dieser Symbole verwendet. Standardwerte wären eben die durch den Datentyp Double vorgegebenen 15 Nachkommastellen, welche für die korrekte Berechnung z.B. des de Vries-Algos auf beliebig viele Nachkommastellen zu wenig sind.
In[1]:= N[Pi,1]
Out[1]= 3.
In[2]:= Sin[3.]
Out[2]= 0.14112
In[3]:= Sin[N[Pi,1]]
Out[3]= 0.
In[4]:= N[Pi,4]
Out[4]= 3.142
In[5]:= Sin[3.142]
Out[5]= -0.000407346
In[6]:= Sin[N[Pi,4]]
Out[6]= 0.*10^-3
In[7]:= N[Pi,6]
Out[7]= 3.14159
In[8]:= Sin[3.14159]
Out[8]= 2.65359*10^-6
In[9]:= Sin[N[Pi,6]]
Out[9]= 0.*10^-5
In[10]:= N[Sin[Pi],1000000000]
Out[10]= 0
Spacerat hat geschrieben:....
Hinzu kommt, dass wenn man das alles auch noch automatisieren wollte, stets eine Abfrage der geforderten Genauigkeit stattfinden muss, zumindest aber diese Genauigkeit durch den gesamten Berechnungsprozess durchgeschleift werden muss. Das sind alles Argumente, die eindeutig gegen eine solche Automatisierung sprechen. Von daher wäre es mal interessant zu erfahren, ob es auch nur eine Software gibt, welche dies tut.
hat geschrieben:Und als nächstes solltest du dem erstaunten Publikum mal erklären, was du hier so großkotzig rechnest. Denn ist es nicht so, dass eine 1.000000000000305 durchaus, wenn man mit Wurzeln und Winkelfunktionen rechnet, Systemfehler in mindestens den letzten 4 Nachkommastellen beinhalten kann (IEEE 754-Double), was dann u.U. auch bedeuten könnte, dass der Faktor 1 ist, wie man es von Orten auf der Oberfläche einer Kugel auch erwarten würde? Jedes Vorschulkind dürfte das wissen. [ironie]Ihr habt es echt drauf.[/ironie]
hat geschrieben:@JucktDieFress: Was soll der Spam? In welchem Teil deiner Berlin-Melbourne-Berechnung hast du BigFloats verwendet? Du denkst doch wohl nicht wirklich, dass dein tolles Matheprogramm das automatisch macht?
hat geschrieben:RTFM (Read the fucking Manual)
hat geschrieben:Aber der xxx bist schon wieder mal du! Denn sicher ist, dass jedwede Anwendung (unabhängig ob Wolfram-System oder nicht) bedarfsweise mit Double- oder Double-Extended-Minimum arbeitet, solange nichts anderes (z.B. BigFloat) angegeben wurde. Aber ganz sicher denkst du, dein System würde es mal wieder anders machen und braucht dafür etwa genau so lange.
hat geschrieben:Denn von Programminterna hast du offensichtlich keinen Plan. Programme verwenden für Berechnungen von Dezimalzahlen standardmäßig die Möglichkeiten der FPU des Prozessors, damit die Berechnungen schneller gehen. Es gibt weltweit keinen einzigen Prozessor, dessen FPU standardmäßig mit BigFloats arbeitet. Und solange das Programm nicht noch für bestimmte Prozessoren (z.B. AMD-Bulldozer oder -Piledriver) optimiert wurde, bleibt es bei den besagten 64-Bit-Zahlenformaten aus IEEE 754.
hat geschrieben:Zu dem Programmtechnischen: Zumindest ist Mathematika in einer Programmiersprache geschieben und kann nur auf entsprechenden Prozessoren ausgeführt werden. All diese Programmiersprachen haben eine Gemeinsamkeit - die nutzbare Hardware. Damit sind nicht nur die Programmiersprachen von solchen Beschränkungen betroffen, sondern auch die damit erzeugten Produkte. Programmtechnisch hat man natürlich die Möglichkeit, Mechanismen zu implementieren, die z.B. eine höhere Genauigkeit zulässt (z.B. BigFloat in c++ oder BigDecimal in Java). Solche Mechanismen benutzen aber nicht mehr direkt die Hardware, wodurch sie unter Umständen recht langsam werden, weswegen man die Nutzung solcher Mechanismen stets explizit angeben muss, auch in Mathematica. JucktDieFress denkt (du etwa auch?), Mathematika würde dies automatisch machen. Dies aber ist definitiv unmöglich, weil man früher oder später (z.B. bei der Berechnung von PI) auf Endlosbrüche (und damit auf Endlosschleifen!) stößt.
hat geschrieben:Nicht großkotzig rumeiern... den Algo implementieren und zeigen, was bei rauskommt!
Spacerat hat geschrieben:M.S hat geschrieben:Stellt sich noch die Frage, warum gibt es eigentlich Software wie mathematica? Warum benutzen die Leute für gewisse Anforderungen nicht eine konventionelle Progammiersprache wie z.B. dein geliebtes java oder von mir aus C,C++ oder gleich Assembler?
Rate mal!
Nö, die Frage stellt sich eben nicht und auch nicht, warum sie ihren Preis hat.
Spacerat hat geschrieben:Aber den Sinn und Unsinn einer solchen Automatisierung hast du (ihr) schon verstanden, ja?
Spacerat hat geschrieben:Die andere allerdings schon, erst recht, wenn man selbst weder die Software noch das Manual hat. Und bei dem, was Yukterez an anderer Stelle gezeigt hat, steht kein Wort über die "Problematik" von der ich hier spreche. Euch scheint diese auch nicht klar zu werden. Naja, was solls, dann dann beteiligt ihr euch halt nicht an dieser Diskussion. Aber dann würde ich auch raten (das geht hauptsächlich an Yukterez) nicht immer so großkotzig euren Senf zu Themen dazuzugeben, wenn ihr nicht mal ahnt, worum es geht.
Mitglieder in diesem Forum: 0 Mitglieder und 23 Gäste