[racket-users] (number->string -nan.0) == "+nan.0" ?
I noticed that (number->string -nan.0) yields "+nan.0" instead of "-nan.0" as I would have expected. It's not an issue for me, but I was wondering why this is? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (number->string -nan.0) == "+nan.0" ?
Looks like its for the same reason that (number->string -0) yields "0". +nan.0 is special, but -nan.0 is the same as (- +nan.0) http://docs.racket-lang.org/reference/numbers.html On Mon, Feb 5, 2018 at 6:41 PM, David Storrs wrote: > I noticed that (number->string -nan.0) yields "+nan.0" instead of "-nan.0" > as I would have expected. It's not an issue for me, but I was wondering why > this is? > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (number->string -nan.0) == "+nan.0" ?
Not sure there should be a -nan.0 to start with. NaN is an absorbing value that shouldn't have a sign. I suspect it's because the + is a convenience to trigger the number reader, and then an appeal to symmetry and analogy to +inf.0 led to -nan.0? On Mon, Feb 5, 2018 at 11:46 PM, Ben Greenman wrote: > Looks like its for the same reason that (number->string -0) yields "0". > > +nan.0 is special, but -nan.0 is the same as (- +nan.0) > > http://docs.racket-lang.org/reference/numbers.html > > On Mon, Feb 5, 2018 at 6:41 PM, David Storrs > wrote: > > I noticed that (number->string -nan.0) yields "+nan.0" instead of > "-nan.0" > > as I would have expected. It's not an issue for me, but I was wondering > why > > this is? > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [racket-users] (number->string -nan.0) == "+nan.0" ?
(eq? +nan.0 -nan.0) -> #t This is documented: The datum -nan.0 refers to the same constant as +nan.0, and -nan.f is the same as +nan.f. Jos _ From: racket-users@googlegroups.com [mailto:racket-users@googlegroups.com] On Behalf Of David Storrs Sent: martes, 06 de febrero de 2018 00:42 To: Racket Users Subject: [racket-users] (number->string -nan.0) == "+nan.0" ? I noticed that (number->string -nan.0) yields "+nan.0" instead of "-nan.0" as I would have expected. It's not an issue for me, but I was wondering why this is? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (number->string -nan.0) == "+nan.0" ?
Huh. Okay, thanks. On Mon, Feb 5, 2018 at 6:46 PM, Ben Greenman wrote: > Looks like its for the same reason that (number->string -0) yields "0". > > +nan.0 is special, but -nan.0 is the same as (- +nan.0) > > http://docs.racket-lang.org/reference/numbers.html > > On Mon, Feb 5, 2018 at 6:41 PM, David Storrs > wrote: > > I noticed that (number->string -nan.0) yields "+nan.0" instead of > "-nan.0" > > as I would have expected. It's not an issue for me, but I was wondering > why > > this is? > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (number->string -nan.0) == "+nan.0" ?
Greetings. On 6 Feb 2018, at 13:00, ben.rudgers wrote: "The library [math.h] doesn't try to distinguish +0 from -0. IEEE 754 worries quite a bit about this distinction. All the architectures I mentioned above can represent both flavors of zero. But I have trouble accepting (or even understanding) the rationale for this extra complexity. I can sympathize with recent critiques of the IEEE 754 Standard that challenge that rationale. Most of all, I found the functions quite hard enough to write without fretting about the sign of nothing." If I recall correctly, this is included in the IEEE standard in order to support various functions which have a cut along the real axis in the complex plane, and so which have a significantly different values on that real line, when approached from above and below the line (in the complex plane). But this is a rather hand-waving explanation, and I'll defer to those with more detailed knowledge of the relevant numerical analysis. Norman -- Norman Gray : https://nxg.me.uk -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] (number->string -nan.0) == "+nan.0" ?
Thanks Norman. Sorry for not being as clear as I might wish. I was trying to provide an example suggesting significance divided by difficulty often influences the design of programming languages and libraries. For me the critique of the standard is context for the last sentence. The interesting bit for me is the inference "(working) programs are logical -> programming languages are logical" may not be a sound basis for invoking the principle of least surprise. Perhaps apart from this being the general character of human endeavor (as Plauger's remarks about IEEE 754 seem to suggest in light of your comments), it may also be a symptom of most widely used programming languages having a linguistic heritage aligned with English. Caveat that my remark was regarding the literature of programming rather than mathematics. Cheers. Ben On Tue, Feb 6, 2018 at 7:07 AM, Norman Gray wrote: > > Greetings. > > On 6 Feb 2018, at 13:00, ben.rudgers wrote: > > "The library [math.h] doesn't try to distinguish +0 from -0. IEEE 754 >> worries quite >> a bit about this distinction. All the architectures I mentioned above >> can >> represent >> both flavors of zero. But I have trouble accepting (or even >> understanding) the >> rationale for this extra complexity. I can sympathize with recent >> critiques of the >> IEEE 754 Standard that challenge that rationale. Most of all, I found >> the >> functions >> quite hard enough to write without fretting about the sign of nothing." >> > > If I recall correctly, this is included in the IEEE standard in order to > support various functions which have a cut along the real axis in the > complex plane, and so which have a significantly different values on that > real line, when approached from above and below the line (in the complex > plane). > > But this is a rather hand-waving explanation, and I'll defer to those with > more detailed knowledge of the relevant numerical analysis. > > Norman > > > -- > Norman Gray : https://nxg.me.uk > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.