schnellste art 2 double werte zu vergleichen





  • Ah vielen dank - klasse - bin gespannt das durchzugehen.



  • hmm...ginge denn auch so ein vergleich:

    double a = 1.234569888344
    double b = 1.234569888345
    
    if ((a xor b) == 0) dann gleich
    sonst net
    


  • Abgesehen davon, dass der xor-Operator nur ganzzahlige Typen akzeptiert und der Test für den Fall a = b = 0 versagt, funktioniert das theoretisch.

    MfG,

    Probe-Nutzer



  • Also bei mir braucht ein Double Vergleich aufm FPU genau einen Takt.
    Was soll da denn noch schneller gemacht werden?



  • Also bei mir braucht ein Double Vergleich aufm FPU genau einen Takt.
    Was soll da denn noch schneller gemacht werden?

    Kannst du mir mal den code snippen? würd mich mal interessieren...



  • Ich weiß ja nicht, warum man sich über den Deltavergleich aufregt, wenn die meisten anderen Vergleichsformen von Gleitkommazahlen in der Regel nicht das gewünschte liefern.

    Wenn du einen schnelleren Vergleich haben willst, der auch noch sinnvoll arbeitet, darfst du nunmal keine Gleitkommazahlen verwenden, sondern musst auf eine andere Datenrepräsentation wechseln (z.B. Festkommazahlen). Gleitkommazahlen sind nunmal ungenau.



  • asc schrieb:

    Gleitkommazahlen sind nunmal ungenau.

    Ich weiss nicht ob "ungenau" hier das passende Wort ist. Aber ehrlich gesagt fällt mir ein passenderes gerade auch nicht ein 😃



  • Tim schrieb:

    asc schrieb:

    Gleitkommazahlen sind nunmal ungenau.

    Ich weiss nicht ob "ungenau" hier das passende Wort ist. Aber ehrlich gesagt fällt mir ein passenderes gerade auch nicht ein 😃

    Ich halte es für genau das richtige Wort. Je nach Rechenreihenfolge etc. können bei Rechnungen, die an sich das gleiche Ergebnis liefern müssten, am Schluß Differenzen entstehen. Was bitte außer "ungenau" soll hier denn noch treffen?

    Es gibt nicht wenige, die sich erst einmal verinnerlichen sollten was Gleitkommazahl denn eigentlich bedeutet, und warum eine solche Zahl auch nur eine gewisse "Genauigkeit" hat (und warum es schon bei so einfachen Aktionen wie zusammenaddieren vieler solcher Zahlen Sinn machen kann, diese Vorher zu sortieren - und erst die kleinsten aufzuaddieren).

    cu André



  • Danke für die Hinweise.
    Ich möchte gerne stellung nehmen...

    Ich weiß ja nicht, warum man sich über den Deltavergleich aufregt, wenn die meisten anderen Vergleichsformen von Gleitkommazahlen in der Regel nicht das gewünschte liefern.

    ich rege mich ja nicht auf - es ist ein Problem was mich beschäftigt und wo ich gerne eine effiziente Lösung für mein Problem finde würde...

    Wenn du einen schnelleren Vergleich haben willst, der auch noch sinnvoll arbeitet, darfst du nunmal keine Gleitkommazahlen verwenden, sondern musst auf eine andere Datenrepräsentation wechseln (z.B. Festkommazahlen). Gleitkommazahlen sind nunmal ungenau.

    Ich verstehe Dich. Leider handelt es sich um numerische Eingaben die nunmal ungenau sind.

    Außerdem zeigt der Link von Probe-Nutzer schon wirklich ein gutes paper auf...
    Meine Gedanken reichen leider nicht so weit - ich wollte mich mit der XOR Operation nur ein wenig austauschen mit Leuten die vielleicht schon mal in die Richtung Lösungen gefunden haben oder sich damit beschäftigt haben....



  • Würde aus dem Paper die Version für 64 Bit Gleitkommazahlen (Seite 11 Listing 😎 trivialerweise nur so aussehen, dass ich statt 31 rshifts 63 rshifts mache?...

    ganz schön tricky das zeug...


Anmelden zum Antworten