En liten avledning inn i flytepunkt (im) presisjon, del 1

stemmer
18

De fleste matematikere er enige om at:

e πi + 1 = 0

Men de fleste flyttall implementeringer uenige. Hvor godt kan vi avgjøre denne tvisten?

Jeg er opptatt av å høre om forskjellige språk og implementeringer, og ulike metoder for å gjøre resultatet så nær null som mulig. Vær kreativ!

Publisert på 04/08/2008 klokken 06:21
kilden bruker
På andre språk...                            


10 svar

stemmer
17

Det er ikke slik at de fleste flyt implementeringer uenig, det er bare at de ikke kan få nøyaktigheten nødvendig for å få en 100% svar. Og det riktige svaret er at de ikke kan.

PI er en uendelig serie med tall som ingen har vært i stand til å betegne av noe annet enn en symbolsk representasjon, og e ^ X er den samme, og dermed den eneste måten å få til 100% nøyaktighet er å gå symbolsk.

Svarte 26/12/2008 kl. 20:22
kilden bruker

stemmer
10

Her er en kort liste over implementeringer og språk jeg har prøvd. Det er sortert etter nærhet til null:

  • ordning: (+ 1 (make-polar 1 (atan 0 -1)))
    • 0.0+1.2246063538223773e-16i(Chez ordningen, MIT Skjema)
    • 0.0+1.22460635382238e-16i(Guile)
    • 0.0+1.22464679914735e-16i(kylling med numbersegg)
    • 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)
  • Rubin: 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
Svarte 04/08/2008 kl. 06:22
kilden bruker

stemmer
7

Er det mulig å avgjøre denne tvisten?

Min første tanke er å se til en symbolsk språk, som Maple . Jeg tror ikke at teller som flyttall skjønt.

Faktisk, hvordan representerer en jeg (eller j for ingeniører) i en vanlig programmeringsspråk?

Kanskje et bedre eksempel er sin (π) = 0? (Eller har jeg gått glipp av poenget igjen?)

Svarte 04/08/2008 kl. 06:29
kilden bruker

stemmer
5

Ditt spørsmål virker litt rart for meg, som du synes å være noe som tyder på at flyttall matematikk implementeres av språket. Det er vanligvis ikke sant, som FP matematikk gjøres ved hjelp av et flyttall prosessor i maskinvare. Men programvare eller maskinvare, flyttall vil alltid være unøyaktig. Det er bare hvordan flyter arbeid.

Hvis du trenger bedre presisjon du trenger å bruke et annet nummer representasjon. Akkurat som om du gjør heltall matte på tall som ikke passer i en int eller lang. Noen språk har biblioteker for at bygget (jeg vet java har BigInteger og BigDecimal), men du må eksplisitt bruke disse bibliotekene i stedet for innfødte typer, og resultatene vil være (noen ganger vesentlig) dårligere enn om du brukte flyter.

Svarte 25/08/2008 kl. 13:37
kilden bruker

stemmer
5

@Ryan Fox

Faktisk, hvordan representerer en i (eller j for ingeniører) i en vanlig programmeringsspråk?

Native komplekse datatyper er langt fra ukjent. Fortran hadde det ved midten av sekstitallet, og OP viser en rekke andre språk som støtter dem i hist oppfølging.

Og komplekse tall kan legges til andre språk som biblioteker (med operatør overbelastning de selv ser ut akkurat som innfødte typer i koden).

Men med mindre du gir en spesiell sak for dette problemet, "ikke-avtale" er bare et uttrykk for upresis maskin aritmetikk, nei? Det er som klager på at

float r = 2/3;
float s = 3*r;
float t = s - 2;

ender med (t! = 0) (I hvert fall hvis du bruker en dum nok kompilator) ...

Svarte 25/08/2008 kl. 13:29
kilden bruker

stemmer
5

Jeg er enig med Ryan, ville du trenger å flytte til et annet nummer representasjon system. Løsningen er utenfor riket av flyttall matematikk fordi du trenger pi å framstå som en uendelig lang desimal så noen begrenset presisjon ordningen bare ikke kommer til å fungere (i hvert fall ikke uten å bruke noen form for fudge-faktor for å gjøre opp den tapte presisjon).

Svarte 25/08/2008 kl. 01:10
kilden bruker

stemmer
3

Jeg hadde laaaange kaffe samtaler med min beste venn snakker om Irrasjonelle tall og diference mellom andre tall. Vel, begge av oss er enige i denne annen synsvinkel:

Irrasjonale tall er relasjoner, som fungerer på en måte, hvilken måte? Vel, tenk om "hvis du vil ha en perfekt sirkel, gi meg en perfekt pi", men sirkler er ulike til de andre figurene (4 sider, 5, 6 ... 100, 200), men ... hvor mange flere sider gjøre du har, mer som en sirkel det ser ut som. Hvis du har fulgt meg så langt, koble alle disse ideene her er pi formelen: skriv bildebeskrivelse her

Så, er pi en funksjon, men en som aldri tar slutt! på grunn av ∞ parameter, men jeg liker å tro at du kan ha "forekomst" av pi, hvis du endrer ∞ parameter for en veldig stor Int, vil du ha en veldig stor pi eksempel.

Samme med e, gi meg en stor parameter, vil jeg gi deg en stor e.

Sette alle ideer sammen:

Som vi har begrensninger minne, språket og libs gir oss stor forekomst av irrasjonale tall, i dette tilfellet, pi og e, som endelig resultat, vil du har langt aproach å få 0, som eksemplene som tilbys av @Chris Jester-Young

Svarte 06/05/2017 kl. 03:07
kilden bruker

stemmer
3

Det er en begrensning av våre nåværende flytberegnings arkitekturer. Floating point aritmetikk er bare en tilnærming av numeriske stolper som e eller pi (eller noe utover presisjonen din biter tillater). Jeg liker virkelig disse tallene fordi de trosse klassifisering, og ser ut til å ha større entropi (?) Enn selv primtall, som er en kanonisk serien. Et forhold Defy numeriske representasjon, noen ganger enkle ting som det kan blåse en persons sinn (jeg elsker det).

Heldigvis hele språk og biblioteker kan være dedikert til presisjon trigonometriske funksjoner ved hjelp av notasjonskonsepter (tilsvarende de som er beskrevet av Lasse V. Karlsen ).

Vurdere et bibliotek / språk som beskriver begreper som e og pi i en form som en maskin kan forstå. Har en maskin har noen forestilling om hva en perfekt sirkel er? Sannsynligvis ikke, men vi kan skape et objekt - sirkel som tilfredsstiller alle de kjente egenskapene vi tillegger den (konstant radius, forholdet mellom radius for omkretsen er 2 * pi * r = C). En gjenstand som pi er kun beskrevet ved den tidligere nevnte forhold. r & C kan være numeriske objekter beskrevet av hva presisjon du ønsker å gi dem. e kan defineres "som e er det unike reelt tall slik at verdien av den deriverte (helningen til tangenten linje) av funksjonen f (x) = ex ved punktet x = 0 er nøyaktig 1" fra Wikipedia .

Fun spørsmålet.

Svarte 20/11/2009 kl. 20:37
kilden bruker

stemmer
3

Numerisk analyse lærer oss at du ikke kan stole på den nøyaktige verdien av små forskjeller mellom store tall.

Dette gjelder ikke bare påvirker ligningen i spørsmålet her, men kan bringe ustabilitet til alt fra å løse en nesten enestående sett av likninger, gjennom å finne nuller av polynomer, for å evaluere log (~ 1) eller exp (~ 0) ( jeg har selv sett spesialfunksjoner for evaluering av log (x + 1) og (exp (x) -1) for å komme rundt dette).

Jeg vil oppfordre deg til ikke å tenke i form av nullstilling forskjellen - du ikke kan - men snarere i å gjøre de tilhørende beregninger på en slik måte at den minste feil.

Jeg beklager, det er 43 år siden jeg hadde denne trommet inn i meg på uni, og selv om jeg kunne huske referansene, er jeg sikker på at det finnes bedre ting rundt nå. Jeg foreslår dette som et utgangspunkt.


Hvis det høres litt nedlatende, beklager jeg. Min "Numerical Analysis 101" var en del av min kjemi selvfølgelig, så det var ikke mye CS i disse dager. Jeg har egentlig ikke en følelse av stedet / viktig numerisk analyse har i en moderne CS kurset.

Svarte 26/12/2008 kl. 21:22
kilden bruker

stemmer
3

Faktisk, hvordan representerer en i (eller j for ingeniører) i en vanlig programmeringsspråk?

På et språk som ikke har en innfødt representasjon, er det vanligvis lagt bruke OOP å opprette en Complexklasse for å representere iog jmed operatøren overbelastning å riktig håndtere operasjoner med andre Complextall og eller andre nummer primitiver innfødt til språket.

F.eks: Complex.java , C ++ <kompleks>

Svarte 25/08/2008 kl. 13:48
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more