Library für große Zahlen
-
virtuell Realisticer schrieb:
Vielleicht reicht es ja schon, wenn du den Nachkommaanteil einfach in den Vorkommaanteil reinnimmst und dann damit rechnest
hast du wirklich verstanden, wie fließkommazahen funktionieren?
-
Shade Of Mine schrieb:
Naja, ich verwende jetzt einfach long double - das muss reichen.
Wobei long double meines Wissens nach zumindest auf Win32 Plattformen die gleiche Auflösung wie double hat.
-
groovemaster2002 schrieb:
Shade Of Mine schrieb:
Naja, ich verwende jetzt einfach long double - das muss reichen.
Wobei long double meines Wissens nach zumindest auf Win32 Plattformen die gleiche Auflösung wie double hat.
Hmm, zumindest wenn du den MSVC benützt:
Microsoft Specific ?>
The long double contains 80 bits: 1 for sign, 15 for exponent, and 64 for mantissa. Its range is +/?1.2E4932 with at least 19 digits of precision. Although long double and double are separate types, the representation of long double and double is identical.
END Microsoft Specific
Mit der Plattform hat das weniger zu tun, da der Compiler einfach mehr Speicher holen müsste und fertig.
MfG SideWinder
-
[VC++]Ich denke mal, dass sich long double ändert, wenn man für 64Bit compiliert, genauso wie sich long int dann ändert.[/VC++]
-
Optimizer schrieb:
genauso wie sich long int dann ändert
Ist das so? Fänd ich irgendwie net richtig. Immerhin gibts für 64 bit Integer doch long long (naja zumindest bei C99). Was ich eher akzeptieren könnte, wäre, wenn sich int ändert.
16 bit (zB DOS) -> 2 Bytes
32 bit (zB Win32) -> 4 Bytes
64 bit (zB Win64) -> 8 Bytes ???btw:
Auf SideWinder's Link http://www.oonumerics.org/oon/ hab ich ne Implementierung einer doubledouble Klasse gefunden. Kennt jemand sowas für Integer?
-
groovemaster2002 schrieb:
Ist das so? Fänd ich irgendwie net richtig. Immerhin gibts für 64 bit Integer doch long long (naja zumindest bei C99).
Wozu wäre dann long gut?
Ich würde sagen: long sollte 64bit sein und long long 128bitwobei int 64bit auch vernünftig wäre - int sollte einfach der schnellste datentyp bleiben - je nachdem was die CPU halt am besten kann.
-
int == schnellster Datentyp (wäre dann meistens int32)
int8, int16, int32, int64, int128Eine striktere Haltung mit den Größen von Typen würde imho C++ ganz gut tun, wär was für C++0x [in manchen Kreisen ja bereits C++1x :p]
MfG SideWinder
-
groovemaster2002 schrieb:
Shade Of Mine schrieb:
Naja, ich verwende jetzt einfach long double - das muss reichen.
Wobei long double meines Wissens nach zumindest auf Win32 Plattformen die gleiche Auflösung wie double hat.
also bei mir winme+mingw(gcc) ist sizeof(double)=8 und sizeof(long double)=10 was im prinzip auch den formaten entspricht die von der x86 fpu unterstütz werden.
-
japro schrieb:
also bei mir winme+mingw(gcc) ist sizeof(double)=8 und sizeof(long double)=10
Kommst etwas spät. SideWinder hat mich ja bereits korrigiert.
SideWinder schrieb:
Eine striktere Haltung mit den Größen von Typen würde imho C++ ganz gut tun
Seh ich genauso.
Shade Of Mine schrieb:
Wozu wäre dann long gut?
Für 32 bit.
Shade Of Mine schrieb:
Ich würde sagen: long sollte 64bit sein und long long 128bit
Was machst du dann, wenn die 128 bit Prozessor Generation kommt? Wieder alles im eins nach vorn schieben? Da bekommst du dann irgendwo ne Lücke.
-
groovemaster2002 schrieb:
Was machst du dann, wenn die 128 bit Prozessor Generation kommt? Wieder alles im eins nach vorn schieben? Da bekommst du dann irgendwo ne Lücke.
so macht man es in C++
oder willst du dann einmal ein
long long long long long long
haben?wenn ich wirklich die typen nach bits verwenden will - dann verwende ich zB die boost typedefs
aber ansonsten erwarte ich von int, dass es der schnellste typ ist, long müsste etwas größer sein und short etwas kleiner.
-
Auf den 64-bittern ist int AFAIK 32bit.
Ich habe ehrlich gesagt noch nie den Sinn hinter den C-Typen verstanden... Die sprechenden Namen könnten genauso gut in einem typedef-Header definiert werden, und dann würde highlevel auf lowlevel aufbauen - nicht andersrum...
-
Sehe ich das eigentlich richtig, dass es zukünftig von jedem Native-Code Programm mindestens 2 ausführbare Dateien gibt, eine für AMD64, eine für Itanium (und evtl. noch eine für x86 die nächsten paar Jahre)?
-
aber ansonsten erwarte ich von int, dass es der schnellste typ ist, long müsste etwas größer sein und short etwas kleiner.
Auf mich hört zwar keiner, aber sowas würde mir für die Zukunft gefallen:
byte, dbyte, short (32Bit), int (64Bit), long (128Bit)Ich sollte mal an das Standardkomitee schreiben.
Aber die wollen sich wahrscheinlich von ihrer Nicht-Festlegung gar nicht trennen. 
-
Optimizer schrieb:
aber ansonsten erwarte ich von int, dass es der schnellste typ ist, long müsste etwas größer sein und short etwas kleiner.
Auf mich hört zwar keiner, aber sowas würde mir für die Zukunft gefallen:
byte, dbyte, short (32Bit), int (64Bit), long (128Bit)Ich sollte mal an das Standardkomitee schreiben.
Aber die wollen sich wahrscheinlich von ihrer Nicht-Festlegung gar nicht trennen. Natürlich werden sie das nicht wollen, wegen der Abwärtskompatibilität.
Finde die derzeitige Lösung bis jetzt nicht schlimm, hatte bisher noch keine Probleme damit.
-
der Standard schreibt doch eh nichts wegen der größen vor, außer die Verhältnisse.
Naja, ich wünsch mir einfach in C++0x ein stdint.h so wie es auch C99 hat und dann nimmt man wenn man ein 16Bit Signed Integer braucht einfach std::int16_t
-
Doch, durch die Makros aus <limits.h> werden Mindestgrößen impliziert. Ist zwar eh alles hypothetisch, aber immerhin kann so keine perverse Implementierung mit int=int8_t an so harmlosen Sachen wie "for (int i = 0; i < 500; ++i)" ersticken.
-
Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben. Geil.
-
Optimizer schrieb:
Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben. Geil.
Weil die Leute zu dumm sin boost zu benützen - da kann man leider nix machen
-
Das war ja mal n richtig verständlicher Kommentar. Was ist bitte an int32_t schöner als an INT?
int32_t kannst du in die Schwachsinns-Liste aufnehmen. Nicht, weil es eine schlechte Idee ist, sondern, weil es Schwachsinn ist, dass man sowas braucht.
-
was willst du sagen?
warum sollte man nicht ein sigend integer der größe 32bit brauchen? Auch wenn int auf den meisten 32Bit Platformen 32Bit groß ist, aber es gibt mehr als nur IA32 und es gibt sogar Leute, die portable Software schreiben wollen