Answer-ID
Mai mult

O mică deviere în precizia punctului de plutire (im), partea 1

Cei mai mulți matematicieni sunt de acord că:

e ? i + 1 = 0

Cu toate acestea, majoritatea implementărilor punctului în flotare nu sunt de acord. Cât de bine putem rezolva această dispută?

Sunt dornic să aud despre diferite limbi și implementări și diferite metode pentru a face rezultatul cât mai aproape de zero posibil. Fii creativ!

Programare
language-agnostic
math
floating-point
Comentarii la întrebare (0)

Minimizatorul $ m $ este cea mai apropiată proiecție de punct de $ X $ pe subspațiul $ L ^ p $ format de funcțiile constante ($ p = 3 $ în cazul tău). Acest $ m $ este uneori numit $ p $ -prediction sau $ p $ -predictor de $ X $. Aparent, această terminologie a început cu Andô și Amemiya . Unele dintre lucrările ulterioare sunt Landers and Rogge (care a scris câteva alte lucrări, de ex. aceasta ) și Cuesta și Matrán . A apărut și termenul "așteptare generalizată (condiționată)".

E (| X-EX | ^ k) se numește momentul centrului k (sau centrat) al variabilei aleatoare X.

Fie f (x) funcția densității de probabilitate a lui X. Putem defini momentele dreapta și stânga și dreapta ale lui X cu privire la m după cum urmează:

Măsura stânga cu un singur moment al lui k în raport cu m = int _ [- inf m] (m-x) ^ k f (x) dx

(X-m) k = f (x) dx (x-m) x (x)

Se observă următoarele analogii

  1. Mediana este statistica pentru care zeroul stânga și mâna dreaptă sunt momente egale (momentele zeroth sunt doar probabilități)

  2. Pentru medie, primele momente din stânga și din dreapta sunt egale.

  3. Pentru statisticile definite în întrebare, cele două momente stângi și drepte sunt egale.

Iată o scurtă listă de implementări și limbi pe care le-am încercat. Este sortat după apropierea de zero:

  • Scheme: (+ 1 (make-polar 1 (atan 0 -1)))
    • ? 0.0+1.2246063538223773e-16i (Chez Scheme, MIT Scheme)
    • ? 0.0+1.22460635382238e-16i (Guile)
    • ? 0.0+1.22464679914735e-16i (Chicken with numbers egg)
    • ? 0.0+1.2246467991473532e-16i (MzScheme, SISC, Gauche, Gambit)
    • ? 0.0+1.2246467991473533e-16i (SCM)
  • Common Lisp: (1+ (exp (complex 0 pi)))
    • ? #C(0.0L0 -5.0165576136843360246L-20) (CLISP)
    • ? #C(0.0d0 1.2246063538223773d-16) (CMUCL)
    • ? #C(0.0d0 1.2246467991473532d-16) (SBCL)
  • Perl: use Math::Complex; Math::Complex->emake(1, pi) + 1
    • ? 1.22464679914735e-16i
  • Python: from cmath import exp, pi; exp(complex(0, pi)) + 1
    • ? 1.2246467991473532e-16j (CPython)
  • Ruby: require 'complex'; Complex::polar(1, Math::PI) + 1
    • ? Complex(0.0, 1.22464679914735e-16) (MRI)
    • ? Complex(0.0, 1.2246467991473532e-16) (JRuby)
  • R: complex(argument = pi) + 1
    • ? 0+1.224606353822377e-16i

Este posibil să rezolvăm această dispută?

Primul meu gând este să vă uit la un limbaj simbolic, cum ar fi Maple . Nu cred ca asta conteaza ca punct plutitor.

De fapt, cum reprezintă i (sau j pentru ingineri) într-un limbaj de programare convențional?

Poate că un exemplu mai bun este păcatul (?) = 0? (Sau am pierdut din nou punctul?)

Sunt de acord cu Ryan, va trebui să te muți la un alt sistem de reprezentare a numerelor. Soluția se află în afara domeniului de matematică cu virgulă mobilă pentru că aveți nevoie de pi ca reprezentând o zecimală infinit de lungă, astfel încât orice schemă de precizie limitată nu va funcționa (cel puțin fără a utiliza un fel de factor fudge pentru a compensa pierderea precizie).