3. Library für große Zahlen

Library für große Zahlen

  • G

    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.

    0
  • S

    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

    0
  • ?

    [VC++]Ich denke mal, dass sich long double ändert, wenn man für 64Bit compiliert, genauso wie sich long int dann ändert.[/VC++]

    0
  • G

    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?

    0
  • S

    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 128bit 🙂

    wobei int 64bit auch vernünftig wäre - int sollte einfach der schnellste datentyp bleiben - je nachdem was die CPU halt am besten kann.

    0
  • S

    int == schnellster Datentyp (wäre dann meistens int32)
    int8, int16, int32, int64, int128

    Eine 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

    0
  • J

    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.

    0
  • G

    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. 😃

    0
  • S

    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.

    0
  • O

    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...

    0
  • ?

    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)?

    0
  • ?

    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. 🙄

    0
  • S

    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.

    0
  • R

    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

    🙂

    0
  • O

    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.

    0
  • ?

    Solange die Datentypen keine feste Größe haben wird es immer so einen Schwachsinn wie INT, DWORD, ULONG und FLOAT geben. Geil. 👍

    0
  • S

    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 😞

    0
  • ?

    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.

    0
  • R

    😕

    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 🙄

    0
  • S

    Optimizer schrieb:

    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.

    also ist int doch besser? 😕
    Was für Typen hättest du denn gerne?
    int willst du ja nicht, oder doch? Oder soll ein int immer 32 Bit haben, nur darf er nicht int32 heissen?

    Wenn mich die anzahl der bits interessiert, dann verwende ich ich gerne
    int32_t oder uint64_t. Also ich brauche das schon.

    0
Anmelden zum Antworten