Re: [racket-users] Defining algebraic data types?

[HiPhish]

That makes perfect sense, thank you.

On Tuesday, February 6, 2018 at 12:43:07 AM UTC+1, Sam Tobin-Hochstadt 
wrote:

> The problem is that the definition of `(Dual-Number N)` includes `N`, 
> and therefore 
>
> (Dual-Number (Dual-Number String)) might either be a (D (D "x" "y") (D 
> "x" "y")) or just (D "x" "y"). Therefore checking D? can't tell that 
> you're in the `D` case because both cases could be a `D` case. 
>
> Sam 
>
>

-- 
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" ?

[ben rudgers]

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.

Re: [racket-users] (number->string -nan.0) == "+nan.0" ?

[Norman Gray]

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.

[racket-users] Re: (number->string -nan.0) == "+nan.0" ?

[ben.rudgers]

The question reminded me of a passage in Plauger's *The Standard C Library* 
(1992):

  "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." 

Ben


On Monday, February 5, 2018 at 5:42:00 PM UTC-6, David K. 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.

Re: [racket-users] (number->string -nan.0) == "+nan.0" ?

[David Storrs]

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" ?

[Jos Koot]

(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" ?

[Laurent]

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.