Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9709 > unrolled thread

Re: NaN

Back to article view | Back to comp.lang.c

Contents

  Re: NaN HENRY Eshbaugh <henryeshbaugh@gmail.com> - 2011-08-29 05:49 -0700
    Re: NaN James Kuyper <jameskuyper@verizon.net> - 2011-08-29 11:42 -0400
      Re: NaN Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-29 11:27 -0700
        Re: NaN James Kuyper <jameskuyper@verizon.net> - 2011-08-29 15:49 -0400
      Re: NaN HENRY Eshbaugh <henryeshbaugh@gmail.com> - 2011-08-29 21:09 -0700
        Re: NaN Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-08-30 02:36 -0700

#9709 — Re: NaN

IME the NaN is the result of an error raised when you try to operate
on it.

But that's just Python talking.

[toc] | [next] | [standalone]

#9710

On 08/29/2011 08:49 AM, HENRY Eshbaugh wrote:
> IME the NaN is the result of an error raised when you try to operate
> on it.
> 
> But that's just Python talking.

Your subject line contains "Re:", implying that it's a response to some
other message with a Subject: of "NaN". However, your message headers
don't indicate which message it's a response to, and a Google Groups
search turns up no obvious candidates. Is this just a random comment?

It would be more appropriate to say that a NaN indicates a special case,
rather than an error. You can write code that detects the special case,
and avoids performing a calculation that might otherwise result in
creation of a NaN. However, when using a system known to produce
non-signaling NaN's when appropriate, it can be entirely appropriate to
write code which relies upon that behavior (it can also be a big
mistake, depending upon the context). It's often more convenient to deal
with special cases by detecting a NaN, rather than by avoiding creation
of the NaN.

[toc] | [prev] | [next] | [standalone]

#9711

On Aug 29, 6:42 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>
> It would be more appropriate to say that a NaN indicates a special case,
> rather than an error.
>
Nan's a bit like null pointer. It sounds rather specialised, but once
you have it, you use it in all sorts of places.

[toc] | [prev] | [next] | [standalone]

#9713

On 08/29/2011 02:27 PM, Malcolm McLean wrote:
> On Aug 29, 6:42 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>>
>> It would be more appropriate to say that a NaN indicates a special case,
>> rather than an error.
>>
> Nan's a bit like null pointer. It sounds rather specialised, but once
> you have it, you use it in all sorts of places.

I think you're using "specialized" in a different sense than I was. When
I said that a NaN indicates a special case, I was referring to the fact
that expressions which are permitted (or required, if __STDC_IEC_559__
is pre#defined by the implementation) to have a value of NaN can
generally do so only for special values of their operands: acos(2.0),
log(-1.0), pow(-1.0, 0.5), tgamma(-1.0), fmod(0.0, 0.0).

[toc] | [prev] | [next] | [standalone]

#9724

On Aug 29, 11:42 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 08/29/2011 08:49 AM, HENRY Eshbaugh wrote:
>
> > IME the NaN is the result of an error raised when you try to operate
> > on it.
>
> > But that's just Python talking.
>
> Your subject line contains "Re:", implying that it's a response to some
> other message with a Subject: of "NaN". However, your message headers
> don't indicate which message it's a response to, and a Google Groups
> search turns up no obvious candidates. Is this just a random comment?
>
> It would be more appropriate to say that a NaN indicates a special case,
> rather than an error. You can write code that detects the special case,
> and avoids performing a calculation that might otherwise result in
> creation of a NaN. However, when using a system known to produce
> non-signaling NaN's when appropriate, it can be entirely appropriate to
> write code which relies upon that behavior (it can also be a big
> mistake, depending upon the context). It's often more convenient to deal
> with special cases by detecting a NaN, rather than by avoiding creation
> of the NaN.

No, I fucked up replying. Slip-up.

[toc] | [prev] | [next] | [standalone]

#9726

On Aug 30, 7:09 am, HENRY Eshbaugh <henryeshba...@gmail.com> wrote:
>
> No, I ----- up replying. Slip-up.
>
Please. We're mostly educated professionals here, and we like to keep
up standards.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web