---

Hej...

Kan det passe at NaN kommer fra math.h ? Hvordan ser bit-mønsteret ud
for NaN / hvordan virker NaN?

Jeg er interesseret i at få NaN ud nogen specielle steder:

double function_f(double x)
{
double function;

function = sqrt( r*r - x*x ); /* y=f(x) for en cirkel */

return(function);
}


På et tidspunkt bliver x > r og der har jeg et problem, med at finde ud
af hvordan jeg tackler det bedst... Nu får jeg -1.#IND000000000 ud som
resultat og kan det passe at det betyder -uendeligt ?

Bagefter det sted hvor jeg kalder programmet vil jeg gerne entydigt
kunne sige:

if( function_f( 4483.4943 ) == -1.#IND0000 ) /* eller tilsvarende ? */
do ....

Men det virker nok ikke... Måske er det noget ala:

if( function_f( 4483.4943 ) == NaN ) /* eller tilsvarende ? */
do ....

Jeg leder efter???


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
> Hej...
>
> Kan det passe at NaN kommer fra math.h ? Hvordan ser bit-mønsteret ud
> for NaN / hvordan virker NaN?
>
> Jeg er interesseret i at få NaN ud nogen specielle steder:
>
> double function_f(double x)
> {
> double function;
>
> function = sqrt( r*r - x*x ); /* y=f(x) for en cirkel */
>
> return(function);
> }
>
>
> På et tidspunkt bliver x > r og der har jeg et problem, med at finde ud
> af hvordan jeg tackler det bedst... Nu får jeg -1.#IND000000000 ud som
> resultat og kan det passe at det betyder -uendeligt ?

Jeg ville bruge den strategi helt at undgå at prøve at regne ting ud,
som ikke kan regnes korrekt ud. Hvis du f. eks. prøver at lave
beregninger på en almindelig cirkel, blot med ikke-positiv radius, går
ting galt. Derfor ville jeg indbygge i funktionen (function_f, som du
kalder den) at den først checker at parametrene har gyldige værdier.

Hvis ikke, kan man så returnere null uden at prøve at beregne noget.

Det er muligt at c understøtter at man kan tage kvadratroden af et
negativt tal, men så vidt jeg kan se, er det lidt forskelligt hvad man
kan regne med at få retur.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler wrote:
> Martin Jørgensen wrote:
-snip-

> Jeg ville bruge den strategi helt at undgå at prøve at regne ting ud,
> som ikke kan regnes korrekt ud. Hvis du f. eks. prøver at lave
> beregninger på en almindelig cirkel, blot med ikke-positiv radius, går
> ting galt. Derfor ville jeg indbygge i funktionen (function_f, som du
> kalder den) at den først checker at parametrene har gyldige værdier.

Problemet er at funktionen skal være helt generel og hvis man ændrer
noget i den, så gider jeg helst ikke at ændre for mange ting forskellige
steder... Lad os sige: Nu er f(x) = x^4 -x^3 +x^2-6...

> Hvis ikke, kan man så returnere null uden at prøve at beregne noget.

Den returnerer jo i forvejen double... Så du mener jeg skal returnere 0.0?

> Det er muligt at c understøtter at man kan tage kvadratroden af et
> negativt tal, men så vidt jeg kan se, er det lidt forskelligt hvad man
> kan regne med at få retur.

Nej, det går ikke. Jeg vil gerne skelne 0.000 udfra NaN... Så jeg vil
gerne have den til at returnere NaN, hvis muligt. Hvordan gør jeg det?
hmm... Ellers returnerer jeg selvfølgeligt bare -1.0 og søger på det,
men jeg er lidt nervøs for om -1.0 nogengange bliver -0.99999999999998
og andre gange -1.000000000002 osv og at en logisk test vil fejle?

Alternativt kunne jeg indsætte endnu en parameter som skifter fra 0 til
1, men det orker jeg næsten ikke.... Der er en hel masse der så skal
ændres...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
>
> Nej, det går ikke. Jeg vil gerne skelne 0.000 udfra NaN...

I C kan du bruge isnan() fra <math.h>. I C++ skulle man vel i princippet
kunne bruge std::numeric_limits<double>::quiet_NaN til et eller andet,
men jeg ved ikke lige hvad. Borland compilere har en _isnan funktion som
en ikke-standard udvidelse, andre compilere har formentlig noget
tilsvarende.

Hvis du vil skrive din egen isnan-funktion, så se
http://en.wikipedia.org/wiki/IEC_559

>Så jeg vil
> gerne have den til at returnere NaN, hvis muligt. Hvordan gør jeg det?

Den del er nemt nok - når først NaN er sluppet ind i din beregning, så
slipper du aldrig af med den.

Formentlig vil det være nemmere forud at sætte errno=EOK og checke
værdien bagefter.

mvh. Anders

---

Anders J. Munch wrote:
> Martin Jørgensen wrote:
-snip-

> Hvis du vil skrive din egen isnan-funktion, så se
> http://en.wikipedia.org/wiki/IEC_559
>
>> Så jeg vil gerne have den til at returnere NaN, hvis muligt. Hvordan
>> gør jeg det?
>
>
> Den del er nemt nok - når først NaN er sluppet ind i din beregning, så
> slipper du aldrig af med den.

Jeg har fundet løsningen, ved at snyde lidt og søge flere informationer
rundt omkring... Den bedste løsning er vist at sige:

if(value != value)
printf("NaN found!\n");

> Formentlig vil det være nemmere forud at sætte errno=EOK og checke
> værdien bagefter.

Den løsning kunne jeg godt tænke mig at forstå. Jeg læste lidt om det på
nettet, men forstod ikke helt hvordan man gjorde det. Altså man
inkluderer "math.h"... Og errno er en variable der stammer fra math.h?


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
> Jeg har fundet løsningen, ved at snyde lidt og søge flere informationer
> rundt omkring... Den bedste løsning er vist at sige:
>
> if(value != value)
> printf("NaN found!\n");

Efter min mening var Kahan midlertidigt sindssyg da han designede lige
dét aspekt af IEEE 754. Hvis du vil bruge det, så test det på hver ny
compiler du bruger, for du kan nemt støde ind i en compiler der
betragter == som en ækvivalensrelation. Og som derfor vil optimere din
if-sætning helt væk.

> Anders J. Munch wrote:
>> Formentlig vil det være nemmere forud at sætte errno=EOK og checke
>> værdien bagefter.
>
> Den løsning kunne jeg godt tænke mig at forstå. Jeg læste lidt om det på
> nettet, men forstod ikke helt hvordan man gjorde det. Altså man
> inkluderer "math.h"... Og errno er en variable der stammer fra math.h?

errno bruges til lidt af hvert i C standardbibliotekerne.

#include <stdlib.h> // for errno
....
{
errno = EOK;
langvarige_og_komplicerede_beregninger();
switch(errno)
{
case EOK: resultat("Det gik godt!"); break;
case EDOM: resultat("Fejl - måske kvadratrod af negativt tal?");
break;
default: resultat("Et eller andet gik galt"); break;
}
}

- Anders

---

Anders J. Munch wrote:
> Martin Jørgensen wrote:
> > Jeg har fundet løsningen, ved at snyde lidt og søge flere informationer
>
>> rundt omkring... Den bedste løsning er vist at sige:
>>
>> if(value != value)
>> printf("NaN found!\n");
>
>
> Efter min mening var Kahan midlertidigt sindssyg da han designede lige
> dét aspekt af IEEE 754. Hvis du vil bruge det, så test det på hver ny
> compiler du bruger, for du kan nemt støde ind i en compiler der
> betragter == som en ækvivalensrelation. Og som derfor vil optimere din
> if-sætning helt væk.

Det var da godt du sagde det, fordi det giver mening. Men jeg har testet
det 2 steder og det gik godt begge steder så det var heldigvis en start...

>> Anders J. Munch wrote:
>>
>>> Formentlig vil det være nemmere forud at sætte errno=EOK og checke
>>> værdien bagefter.
>>
>>
>> Den løsning kunne jeg godt tænke mig at forstå. Jeg læste lidt om det
>> på nettet, men forstod ikke helt hvordan man gjorde det. Altså man
>> inkluderer "math.h"... Og errno er en variable der stammer fra math.h?
>
>
> errno bruges til lidt af hvert i C standardbibliotekerne.

Ja, jeg har set den ifb. med noget "opret et bibliotek" kode, så det er
også derfor jeg spørger fordi den virker ret praktisk...

> #include <stdlib.h> // for errno
> ...
> {
> errno = EOK;
> langvarige_og_komplicerede_beregninger();
> switch(errno)
> {
> case EOK: resultat("Det gik godt!"); break;
> case EDOM: resultat("Fejl - måske kvadratrod af negativt tal?");
> break;
> default: resultat("Et eller andet gik galt"); break;
> }
> }

Den sakser jeg lige og prøver at bruge senere... Takker...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Anders J. Munch wrote:
> Martin Jørgensen wrote:
>> if(value != value)
>> printf("NaN found!\n");
>
> Efter min mening var Kahan midlertidigt sindssyg da han designede lige
> dét aspekt af IEEE 754. Hvis du vil bruge det, så test det på hver ny
> compiler du bruger, for du kan nemt støde ind i en compiler der
> betragter == som en ækvivalensrelation. Og som derfor vil optimere din
> if-sætning helt væk.

Det er vel ret logisk.

I SQL er NULL=NULL også false.

Og så vidt jeg ved understøtter x86 FCOM og fætre
funktionaliteten.

Arne

---

Arne Vajhøj wrote:
> Anders J. Munch wrote:
>> Martin Jørgensen wrote:
>>> if(value != value)
>>> printf("NaN found!\n");
>>
>> Efter min mening var Kahan midlertidigt sindssyg da han designede lige
>> dét aspekt af IEEE 754. Hvis du vil bruge det, så test det på hver ny
>> compiler du bruger, for du kan nemt støde ind i en compiler der
>> betragter == som en ækvivalensrelation. Og som derfor vil optimere din
>> if-sætning helt væk.
>
> Det er vel ret logisk.
>
> I SQL er NULL=NULL også false.

Hvis du tror på det, hvad tror du så NULL<>NULL er?

Men du har ret, SQL har tilsvarende problemer. Og det er et problem i
SQL af samme grund: Det spolerer de allermest grundlæggende og ligetil
ækvivalens- og ordningsrelationer, hvilket gør det sværere at ræssonere
om sin kode. Jeg bruger som hovedregel "NOT NULL" i min SQL DDL af samme
grund.

> Og så vidt jeg ved understøtter x86 FCOM og fætre
> funktionaliteten.

Ja naturligvis, det er jo standard.

mvh. Anders

---

Den Fri, 19 May 2006 17:37:00 +0200 skrev Anders J. Munch:
> Arne Vajhøj wrote:
>> Anders J. Munch wrote:
>>> Martin Jørgensen wrote:
>>>> if(value != value)
>>>> printf("NaN found!\n");
>>>
>>> Efter min mening var Kahan midlertidigt sindssyg da han designede lige
>>> dét aspekt af IEEE 754. Hvis du vil bruge det, så test det på hver ny
>>> compiler du bruger, for du kan nemt støde ind i en compiler der
>>> betragter == som en ækvivalensrelation. Og som derfor vil optimere din
>>> if-sætning helt væk.
>>
>> Det er vel ret logisk.
>>
>> I SQL er NULL=NULL også false.
>
> Hvis du tror på det, hvad tror du så NULL<>NULL er?

Og så kan vi jo lige tage NOT ( NULL = NULL ) nu vi er igang...

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>> Det er vel ret logisk.
>>
>> I SQL er NULL=NULL også false.
>
> Hvis du tror på det, hvad tror du så NULL<>NULL er?

FALSE

SQL og FP er ikke ens.

Men Nan/NULL har specielle regler i begge-

> Men du har ret, SQL har tilsvarende problemer. Og det er et problem i
> SQL af samme grund: Det spolerer de allermest grundlæggende og ligetil
> ækvivalens- og ordningsrelationer

Hvorfor skulle de overholde ækvivalens- og ordningsrelationer ?

Floating point følger heller ikke almindelige algebraiske
regler.

Det er en computer ikke matematik.

Folk med praktisk erfaring har fundet nogle løsninger
som virker i praksis.

> > Og så vidt jeg ved understøtter x86 FCOM og fætre
> > funktionaliteten.
>
> Ja naturligvis, det er jo standard.

Pointen er at compileren ikke skal gøre noget specielt
for at implementere det.

Arne

---

Arne Vajhøj wrote:
>>> I SQL er NULL=NULL også false.
>>
>> Hvis du tror på det, hvad tror du så NULL<>NULL er?
>
> FALSE

Og da FALSE=FALSE, så kan vi konkludere at (NULL=NULL) = (NULL<>NULL) er
sandt, ikke? Det er det bare ikke.

Se http://en.wikipedia.org/wiki/Null_(SQL).

>> Men du har ret, SQL har tilsvarende problemer. Og det er et problem i
>> SQL af samme grund: Det spolerer de allermest grundlæggende og ligetil
>> ækvivalens- og ordningsrelationer
>
> Hvorfor skulle de overholde ækvivalens- og ordningsrelationer ?

Fordi det er umådeligt praktisk.

>
> Floating point følger heller ikke almindelige algebraiske
> regler.

Jo da! Fx gælder der for en floating-point repræsentation F, at
hvis
reelle tal A, B og C er repræsenterbare i F
og F(OP) er en korrekt implementation af OP:RxR->R
og C = A OP B,
så er
F(C) = F(A) F(OP) F(B)

mvh. Anders

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>>>> I SQL er NULL=NULL også false.
>>>
>>> Hvis du tror på det, hvad tror du så NULL<>NULL er?
>>
>> FALSE
>
> Og da FALSE=FALSE, så kan vi konkludere at (NULL=NULL) = (NULL<>NULL) er
> sandt, ikke? Det er det bare ikke.

Nej det er det ikke.

FALSE=FALSE gælder tilsyneladende ikke for alle slags FALSE.

Hvilket netop understreger min pointe: du kan ikke
regne med at programmerings sprog opfører sig matematisk.

>> Floating point følger heller ikke almindelige algebraiske
>> regler.
>
> Jo da! Fx gælder der for en floating-point repræsentation F, at
> hvis
> reelle tal A, B og C er repræsenterbare i F
> og F(OP) er en korrekt implementation af OP:RxR->R
> og C = A OP B,
> så er
> F(C) = F(A) F(OP) F(B)

Det gælder kun hvis A, B og C er eksakt repræsenterbare i F.

Da der formentligt ikke er et eneste program i den virkelige
verden, hvor alle FP er eksakt repræsenterbare, så er dit
udsagn ret misvisende.

Arne

---

Arne Vajhøj wrote:
> FALSE=FALSE gælder tilsyneladende ikke for alle slags FALSE.

Før du sætter dig for at forsvare SQLs ternære logik, var det måske en
idé at sætte dig ind i hvad det går ud på. Følger du ikke engang de
links, jeg giver?

> Det gælder kun hvis A, B og C er eksakt repræsenterbare i F.
>
> Da der formentligt ikke er et eneste program i den virkelige
> verden, hvor alle FP er eksakt repræsenterbare, så er dit
> udsagn ret misvisende.

Jeg kunne godt skrive noget mere kompliceret, der dækkede større
delmængder af de regneoperationer der forekommer almindeligt i
programmer, ved brug af nærmere definerede begreber såsom "nærmeste
repræsenterbare tal". Og det ville alt sammen være ren matematik, og jo
flere særregler à la NaN der var at beskrive, des mere matematik ville
jeg bruge for at beskrive det.

Det er ingen sag at beskrive den formelle semantik af SQL NULL og IEC
559 NaN i matematisk sprog. Men jeg vil nu gerne kunne ræssonere om mine
programmer med almindelig snusfornuft, uden alt for tit at skulle gribe
til den store hammer der hedder matematisk formalisering. Det er derfor
jeg gerne vil se pæne, gennemførte ækvivalens- og ordningsrelationer i
mine programmeringssprog: For det øger sandsynligheden for at en
algoritme, der overfladisk set ser korrekt ud, rent faktisk er korrekt.

mvh. Anders

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>> FALSE=FALSE gælder tilsyneladende ikke for alle slags FALSE.
>
> Før du sætter dig for at forsvare SQLs ternære logik, var det måske en
> idé at sætte dig ind i hvad det går ud på. Følger du ikke engang de
> links, jeg giver?

Jo.

Og ?

>> Det gælder kun hvis A, B og C er eksakt repræsenterbare i F.
>>
>> Da der formentligt ikke er et eneste program i den virkelige
>> verden, hvor alle FP er eksakt repræsenterbare, så er dit
>> udsagn ret misvisende.
>
> Jeg kunne godt skrive noget mere kompliceret, der dækkede større
> delmængder af de regneoperationer der forekommer almindeligt i
> programmer, ved brug af nærmere definerede begreber såsom "nærmeste
> repræsenterbare tal". Og det ville alt sammen være ren matematik, og jo
> flere særregler à la NaN der var at beskrive, des mere matematik ville
> jeg bruge for at beskrive det.
>
> Det er ingen sag at beskrive den formelle semantik af SQL NULL og IEC
> 559 NaN i matematisk sprog. Men jeg vil nu gerne kunne ræssonere om mine
> programmer med almindelig snusfornuft, uden alt for tit at skulle gribe
> til den store hammer der hedder matematisk formalisering. Det er derfor
> jeg gerne vil se pæne, gennemførte ækvivalens- og ordningsrelationer i
> mine programmeringssprog: For det øger sandsynligheden for at en
> algoritme, der overfladisk set ser korrekt ud, rent faktisk er korrekt.

Så du poster noget matematik. Og da det bliver påvist
at det er irrelevant i praktisk programmering, så hævder du
at kunne poste noget andet men vil ikke fordi det ikke skal
være matematik det hele ?

Du er lidt svær at tage seriøs.

Alle der har programmet med FP ved at man ikke kan
regne med at almindelige matematiske regler gælder.

Et af de simple eksempler er:

if(x + 1 > x)

som ikke nødvendigvis er opfyldt i FP.

Hvis man studerer numerisk analyse for begyndere er noget
af det første man lærer at den associativer lov ikke gælder
for addition og multiplikation i FP.

Så du skal ikke undre dig over at NaN != NaN, fordi
der er rigtigt mange ting i FP som er anderledes
end reelle tal i matematik.

Arne

---

Arne Vajhøj wrote:

> Så du skal ikke undre dig over at NaN != NaN, fordi
> der er rigtigt mange ting i FP som er anderledes
> end reelle tal i matematik.

Matematik behøver ikke at have noget med de reelle tal at gøre.
Der er forskel på matematik og regning.

- Anders

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>> Så du skal ikke undre dig over at NaN != NaN, fordi
>> der er rigtigt mange ting i FP som er anderledes
>> end reelle tal i matematik.
>
> Matematik behøver ikke at have noget med de reelle tal at gøre.
> Der er forskel på matematik og regning.

Ja. Og ?

Vil du mene at associative lov for addition og
multiplikation er regning fremfor matematik ?

Hvilken kendte type tal i matematik gælder
associative lov for addition og multiplikation ikke
for ?

Arne

---

Arne Vajhøj wrote:
> Anders J. Munch wrote:
>> Arne Vajhøj wrote:
>>> Så du skal ikke undre dig over at NaN != NaN, fordi
>>> der er rigtigt mange ting i FP som er anderledes
>>> end reelle tal i matematik.
>>
>> Matematik behøver ikke at have noget med de reelle tal at gøre.
>> Der er forskel på matematik og regning.
>
> Ja. Og ?

You tell me. Det er dig, der syntes de reelle tal havde en eller anden
form for relevans for hvorvidt sammenligningsoperationen på IEC 559-tal
burde være en ækvivalensrelation.

- Anders

---

Anders J. Munch wrote:
> Arne Vajhøj wrote:
>> Anders J. Munch wrote:
>>> Arne Vajhøj wrote:
>>>> Så du skal ikke undre dig over at NaN != NaN, fordi
>>>> der er rigtigt mange ting i FP som er anderledes
>>>> end reelle tal i matematik.
>>>
>>> Matematik behøver ikke at have noget med de reelle tal at gøre.
>>> Der er forskel på matematik og regning.
>>
>> Ja. Og ?
>
> You tell me. Det er dig, der syntes de reelle tal havde en eller anden
> form for relevans for hvorvidt sammenligningsoperationen på IEC 559-tal
> burde være en ækvivalensrelation.

I did tell you.

Men jeg gentager da gerne:

#Et af de simple eksempler er:
#
#if(x + 1 > x)
#
#som ikke nødvendigvis er opfyldt i FP.

#Hvis man studerer numerisk analyse for begyndere er noget
#af det første man lærer at den associativer lov ikke gælder
#for addition og multiplikation i FP.

# fordi
#der er rigtigt mange ting i FP som er anderledes
#end reelle tal i matematik.

#Hvilken kendte type tal i matematik gælder
#associative lov for addition og multiplikation ikke
#for ?

Du må meget gerne besvare det sidste spørgsmål !

Arne

PS: Jeg kan desværre ikke forklare hvor regning som
modsætning til matematik kom ind i billedet.
Det var nemlig dig der bragte det på bane. Og
jeg spurgte faktisk eksplicit i forrige post
om hvorfor.

---

Arne Vajhøj wrote:
>> You tell me. Det er dig, der syntes de reelle tal havde en eller anden
>> form for relevans for hvorvidt sammenligningsoperationen på IEC
>> 559-tal burde være en ækvivalensrelation.
>
> I did tell you.
>
> Men jeg gentager da gerne:
>
> #Et af de simple eksempler er:
> #
> #if(x + 1 > x)
> #
> #som ikke nødvendigvis er opfyldt i FP.
>
> #Hvis man studerer numerisk analyse for begyndere er noget
> #af det første man lærer at den associativer lov ikke gælder
> #for addition og multiplikation i FP.
>
> # fordi
> #der er rigtigt mange ting i FP som er anderledes
> #end reelle tal i matematik.

Du præsenterer argumenter for, at floating-point tal og reelle tal er to
forskellige ting, som om der nogensinde er nogen der kunne være uenig i
det, og så går du ud fra at du dermed har demonstreret, at det ikke
ville tjene noget formål hvis sammenligningsoperationen på IEC 559-tal
var en ækvivalensrelation.

Der mangler et par mellemregninger i den argumentationskæde.

>
> #Hvilken kendte type tal i matematik gælder
> #associative lov for addition og multiplikation ikke
> #for ?
>
> Du må meget gerne besvare det sidste spørgsmål !

Oktonioner. Er der andre irrelevante fakta du gerne vil have oplyst?

- Anders

---

Anders J. Munch wrote:
> Du præsenterer argumenter for, at floating-point tal og reelle tal er to
> forskellige ting, som om der nogensinde er nogen der kunne være uenig i
> det, og så går du ud fra at du dermed har demonstreret, at det ikke
> ville tjene noget formål hvis sammenligningsoperationen på IEC 559-tal
> var en ækvivalensrelation.
>
> Der mangler et par mellemregninger i den argumentationskæde.

Du misforstår både forudsætningerne og logikken.

Vi har vist fået vist at floating point opfører sig
andeledes end reelle tal og andre kendte tal typer
indenfor matematikken.

Deraf fremgår det, at din påstand om at almindelige
matematisk/algebraiske regler også gælder for floating
point ikke holder vand.

Og at min pointe om, at det ikke giver mening at argumentere
for at et enkelt aspekt af floating point skal ændres til at
opføre sig matematisk, når der er så mange aspekter der
ikke gør det, må give en vis mening.

Jeg har ikke observeret nogen i tråden som har påstået
at det ikke ville tjene noget formål at x==x var sand for
alle FP. Det må du have drømt.

Man kan have masser af andre grunde til, at mene at NaN burde
afskaffes eller at NaN==NaN bør returnere true.

>> #Hvilken kendte type tal i matematik gælder
>> #associative lov for addition og multiplikation ikke
>> #for ?
>>
>> Du må meget gerne besvare det sidste spørgsmål !
>
> Oktonioner. Er der andre irrelevante fakta du gerne vil have oplyst?

Prøv og slå ordet "kendte" op i en ordbog. Oktonioner er vist ikke
kvalificeret til at være kendte.

Arne

---

Arne Vajhøj wrote:
>
> Jeg har ikke observeret nogen i tråden som har påstået
> at det ikke ville tjene noget formål at x==x var sand for
> alle FP. Det må du have drømt.
>
> Man kan have masser af andre grunde til, at mene at NaN burde
> afskaffes eller at NaN==NaN bør returnere true.

Jeg er glad for at høre, at du slet ikke er uenig med mig, og at du
aldrig har været det. Så er der jo ikke mere at sige om den sag.

>>> #Hvilken kendte type tal i matematik gælder
>>> #associative lov for addition og multiplikation ikke
>>> #for ?
>>>
>>> Du må meget gerne besvare det sidste spørgsmål !
>>
>> Oktonioner. Er der andre irrelevante fakta du gerne vil have oplyst?
>
> Prøv og slå ordet "kendte" op i en ordbog. Oktonioner er vist ikke
> kvalificeret til at være kendte.

Aha, så du mener _almindeligt_ kendte, det kunne du jo bare have sagt.
Jamen så lad os sige de irrationelle tal. Hverken multiplikation eller
addition på de irrationelle tal er associative. Eller primtallene.

- Anders

---

>Jeg er glad for at høre, at du slet ikke er uenig med mig, og at du
>aldrig har været det. Så er der jo ikke mere at sige om den sag.

Jeg er og har hele tiden været meget uenig i dine påstand om
at floating point følger almindelige matematiske regler.

> Aha, så du mener _almindeligt_ kendte, det kunne du jo bare have sagt.
> Jamen så lad os sige de irrationelle tal. Hverken multiplikation eller
> addition på de irrationelle tal er associative. Eller primtallene.

Suk.

Selvfølgelig gælder den associative lov for addition
multiplikation og irrationelle tal og primtal. Den gælder
for alle reelle tal.

Arne

---

Arne Vajhøj wrote:
> >Jeg er glad for at høre, at du slet ikke er uenig med mig, og at du
> >aldrig har været det. Så er der jo ikke mere at sige om den sag.
>
> Jeg er og har hele tiden været meget uenig i dine påstand om
> at floating point følger almindelige matematiske regler.

Du kan til enhver tid fabrikere en kunstig uenighed ved at lægge mig ord
i munden. Det kan dog ikke slå skår i min glæde over, at du ikke er
uenig i det synspunkt, jeg har holdt på helt fra starten.

>
>> Aha, så du mener _almindeligt_ kendte, det kunne du jo bare have sagt.
>> Jamen så lad os sige de irrationelle tal. Hverken multiplikation eller
>> addition på de irrationelle tal er associative. Eller primtallene.
>
> Suk.
>
> Selvfølgelig gælder den associative lov for addition
> multiplikation og irrationelle tal og primtal. Den gælder
> for alle reelle tal.

Associativitet er ikke en egenskab, som et enkelt tal har. Det er en
egenskab ved en mængde og en funktion. Lad P=primtallene og +:PxP->P
være almindelig addition på primtallene. (P,+) er ikke associativ, da
der findes et modeksempel: (3+2)+2=3+(2+2) gælder ikke, da 2+2 ikke er
veldefineret.

Selv suk.

mvh. Anders

---

Martin Jørgensen wrote:
> Michael Zedeler wrote:
>
>> Martin Jørgensen wrote:
>
> -snip-
>
>> Jeg ville bruge den strategi helt at undgå at prøve at regne ting ud,
>> som ikke kan regnes korrekt ud. Hvis du f. eks. prøver at lave
>> beregninger på en almindelig cirkel, blot med ikke-positiv radius, går
>> ting galt. Derfor ville jeg indbygge i funktionen (function_f, som du
>> kalder den) at den først checker at parametrene har gyldige værdier.
>
> Problemet er at funktionen skal være helt generel og hvis man ændrer
> noget i den, så gider jeg helst ikke at ændre for mange ting forskellige
> steder... Lad os sige: Nu er f(x) = x^4 -x^3 +x^2-6...

Der er ikke voldsomt mange operationer, hvor man skal være opmærksomme
på indgående parameterværdier.

>> Hvis ikke, kan man så returnere null uden at prøve at beregne noget.
>
> Den returnerer jo i forvejen double... Så du mener jeg skal returnere 0.0?

DUH. Jeg er blevet Java-hjernevasket. Du er faktisk nødt til at
returnere NaN selv. Så er det en kende omsonst.

>> Det er muligt at c understøtter at man kan tage kvadratroden af et
>> negativt tal, men så vidt jeg kan se, er det lidt forskelligt hvad man
>> kan regne med at få retur.
>
> Nej, det går ikke. Jeg vil gerne skelne 0.000 udfra NaN... Så jeg vil
> gerne have den til at returnere NaN, hvis muligt. Hvordan gør jeg det?

Der findes en funktion ved navn nan, som returnerer en double med de
rigtige bits sat. På Linux, se nan(3) (og isnan(3) for at checke om
noget er NaN).

> hmm... Ellers returnerer jeg selvfølgeligt bare -1.0 og søger på det,
> men jeg er lidt nervøs for om -1.0 nogengange bliver -0.99999999999998
> og andre gange -1.000000000002 osv og at en logisk test vil fejle?

Det duer ikke.

> Alternativt kunne jeg indsætte endnu en parameter som skifter fra 0 til
> 1, men det orker jeg næsten ikke.... Der er en hel masse der så skal
> ændres...

Ditto. Min eneste indvending er, at det er fjollet at prøve at regne
noget ud, som ikke giver mening og at man bør sikre at man slet ikke
prøver at foretage beregningen i første omgang.

Derudover ser det ud til at sqrt ikke altid returnerer det samme,
afhængigt af platformen. Nogle steder får man sqrt(-1) == NaN og andre
steder giver det -uendelig. Det er også noget snask.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Michael Zedeler wrote:
> Martin Jørgensen wrote:
-snip-

>> Nej, det går ikke. Jeg vil gerne skelne 0.000 udfra NaN... Så jeg vil
>> gerne have den til at returnere NaN, hvis muligt. Hvordan gør jeg det?
>
>
> Der findes en funktion ved navn nan, som returnerer en double med de
> rigtige bits sat. På Linux, se nan(3) (og isnan(3) for at checke om
> noget er NaN).

Virker isnan mon også på windows med visual studio 2005?

>> hmm... Ellers returnerer jeg selvfølgeligt bare -1.0 og søger på det,
>> men jeg er lidt nervøs for om -1.0 nogengange bliver -0.99999999999998
>> og andre gange -1.000000000002 osv og at en logisk test vil fejle?
>
>
> Det duer ikke.
>
>> Alternativt kunne jeg indsætte endnu en parameter som skifter fra 0
>> til 1, men det orker jeg næsten ikke.... Der er en hel masse der så
>> skal ændres...
>
>
> Ditto. Min eneste indvending er, at det er fjollet at prøve at regne
> noget ud, som ikke giver mening og at man bør sikre at man slet ikke
> prøver at foretage beregningen i første omgang.

Årsagen er, at jeg har nogle data som jeg ikke på forhånd kender til
nøjagtigt og jeg vil meget meget gerne undgå at skulle rette funktionen
adskillige steder, når den ændres.

F.eks. f(x) = bla.bla ændres til f(x) = blibblob. Så gider jeg ikke også
at skulle ændre flere steder noget med if(x >= noget), så lad være med
at kald f(x).

Derfor: Jeg tror isnan og venner er løsningen.

> Derudover ser det ud til at sqrt ikke altid returnerer det samme,
> afhængigt af platformen. Nogle steder får man sqrt(-1) == NaN og andre
> steder giver det -uendelig. Det er også noget snask.

Er du sikker? Det var dog irriterende

Nogen der ved hvordan man undersøger om noget er +/- uendeligt? Jeg har
kigget lidt på "man isinf" mv. men den åbner "FPCLASSIFY(3)" og der står
ikke så voldsomt meget om det...


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk

---

Martin Jørgensen wrote:
> Michael Zedeler wrote:
>
>> Martin Jørgensen wrote:
>
> -snip-
>
>>> Nej, det går ikke. Jeg vil gerne skelne 0.000 udfra NaN... Så jeg vil
>>> gerne have den til at returnere NaN, hvis muligt. Hvordan gør jeg det?
>>
>> Der findes en funktion ved navn nan, som returnerer en double med de
>> rigtige bits sat. På Linux, se nan(3) (og isnan(3) for at checke om
>> noget er NaN).
>
> Virker isnan mon også på windows med visual studio 2005?

Har aldrig prøvet. Det ser ud til at være standard, men prøv og se hvad
der sker.

>> Ditto. Min eneste indvending er, at det er fjollet at prøve at regne
>> noget ud, som ikke giver mening og at man bør sikre at man slet ikke
>> prøver at foretage beregningen i første omgang.
>
> Årsagen er, at jeg har nogle data som jeg ikke på forhånd kender til
> nøjagtigt og jeg vil meget meget gerne undgå at skulle rette funktionen
> adskillige steder, når den ændres.
>
> F.eks. f(x) = bla.bla ændres til f(x) = blibblob. Så gider jeg ikke også
> at skulle ændre flere steder noget med if(x >= noget), så lad være med
> at kald f(x).
>
> Derfor: Jeg tror isnan og venner er løsningen.

Så har du bare en ny flok undtagelser at håndtere, for hvis sqrt(-1)
returnerer minus uendelig, kan du ikke regne videre med resultatet og
regne med at få NaN ud i den anden ende.

>> Derudover ser det ud til at sqrt ikke altid returnerer det samme,
>> afhængigt af platformen. Nogle steder får man sqrt(-1) == NaN og andre
>> steder giver det -uendelig. Det er også noget snask.
>
> Er du sikker? Det var dog irriterende

Nej. Jeg er ikke 100% sikker. Jeg har ikke rodet med aritmetik i c, men
bemærkede i forbifarten at de skrev om det på en side på nettet, men der
står så meget på nettet. Hvad med at du checker hvad du faktisk får ud
af sqrt(-1) på din platform til en start. Du kan jo bare hælde det
igennem isnan().

> Nogen der ved hvordan man undersøger om noget er +/- uendeligt? Jeg har
> kigget lidt på "man isinf" mv. men den åbner "FPCLASSIFY(3)" og der står
> ikke så voldsomt meget om det...

Men det er også den rigtige funktion, du har fat i. Læs siden - den er
god nok.

Mvh. Michael.
--
Which is more dangerous? TV guided missiles or TV guided families?
Visit my home page at http://michael.zedeler.dk/
Get my vcard at http://michael.zedeler.dk/vcard.vcf

---

Martin Jørgensen wrote:
> Kan det passe at NaN kommer fra math.h ? Hvordan ser bit-mønsteret ud
> for NaN / hvordan virker NaN?

> På et tidspunkt bliver x > r og der har jeg et problem, med at finde ud
> af hvordan jeg tackler det bedst... Nu får jeg -1.#IND000000000 ud som
> resultat og kan det passe at det betyder -uendeligt ?

http://en.wikipedia.org/wiki/NaN
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.xlf81m.doc/pgs/ug34.htm

fortæller lidt om de kære Signalling NaN og quiet NaN.

Arne

---

Arne Vajhøj wrote:
> Martin Jørgensen wrote:
>
>> Kan det passe at NaN kommer fra math.h ? Hvordan ser bit-mønsteret ud
>> for NaN / hvordan virker NaN?
>
>
>> På et tidspunkt bliver x > r og der har jeg et problem, med at finde
>> ud af hvordan jeg tackler det bedst... Nu får jeg -1.#IND000000000 ud
>> som resultat og kan det passe at det betyder -uendeligt ?
>
>
> http://en.wikipedia.org/wiki/NaN
> http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=/com.ibm.xlf81m.doc/pgs/ug34.htm
>
>
> fortæller lidt om de kære Signalling NaN og quiet NaN.

Ok, tak.


Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk