Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > What shall return "0.0 ? 1 : 0" ?

Reply
Thread Tools

What shall return "0.0 ? 1 : 0" ?

 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Martin Shobe <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote in news:kfnwr1w1jgh.fsf@x-
> alumni2.alumni.caltech.edu:
>
>> Ralf Damaschke <(E-Mail Removed)> writes:
>>
>>> Tim Rentsch <(E-Mail Removed)> wrote:
>>>
>>>> I believe it is possible in principle for 0.0 to be seen as
>>>> true (that is, != 0) in a conforming implementation, if that
>>>> implementation (a) does not have an exact FP representation for
>>>> zero, and (b) has implementation-defined rounding rules which
>>>> are defined suitably. AFAIK both (a) and (b) may be true in a
>>>> conforming implementation, that is, I don't know of any
>>>> requirement that prevents the possibility of either (or of both
>>>> together).
>>>
>>> There is one. An implementation (a) would not suffice C99 5.2.4.2.2
>>> "Characteristics of floating types <float.h>"; esp. the sum used to
>>> define a floating-point number gives 0 if f(k) = 0 for all
>>> 1 <= k <= p.

>>
>> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
>> I think you'll agree that the condition you describe need not
>> be an actual representable value in a particular conforming
>> implementation. The value does exist in the model, but the
>> model may not reflect what the implementation actually uses,
>> and even if it does, the implementation might not provide FP
>> numbers with f(1) == 0. Needless to say, I did consult this
>> section (and these paragraphs) before making my earlier
>> comments. So I still think it's possible for an implementation
>> to not have zero as a representable FP value.
>>
>>

> What about 6.7.9 paragraph 10?
>
> 10 If an object that has automatic storage duration is not initialized
> explicitly, its value is
> indeterminate. If an object that has static or thread storage duration
> is not initialized
> explicitly, then:
> * if it has pointer type, it is initialized to a null pointer;
> * if it has arithmetic type, it is initialized to (positive or unsigned)
> zero;
> * if it is an aggregate, every member is initialized (recursively)
> according to these rules,
> and any padding is initialized to zero bits;
> * if it is a union, the first named member is initialized (recursively)
> according to these
> rules, and any padding is initialized to zero bits;
>
> How could a real type be initialized to positive or unsigned zero if
> there isn't one?


I take this to mean the initialization is done the same as saying
'={0}' for the initializer, except also saying the result will
never be (a representation for) negative zero. Of course it's
possible that it indicates a requirement elsewhere, and it's also
possible that it indicates a subconscious assumption that is not
actually a requirement, but I don't think this passge is meant to
/impose/ a requirement that zero be representable. So basically
I don't draw any conclusions just from this paragraph one way or
the other.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Ralf Damaschke <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
>
>> Ralf Damaschke <(E-Mail Removed)> writes:
>>
>>> Tim Rentsch <(E-Mail Removed)> wrote:
>>>
>>>> I believe it is possible in principle for 0.0 to be seen as
>>>> true (that is, != 0) in a conforming implementation, if that
>>>> implementation (a) does not have an exact FP representation
>>>> for zero, and (b) has implementation-defined rounding rules
>>>> which are defined suitably. AFAIK both (a) and (b) may be
>>>> true in a conforming implementation, that is, I don't know of
>>>> any requirement that prevents the possibility of either (or of
>>>> both together).
>>>
>>> There is one. An implementation (a) would not suffice C99
>>> 5.2.4.2.2 "Characteristics of floating types <float.h>"; esp.
>>> the sum used to define a floating-point number gives 0 if f(k)
>>> = 0 for all 1 <= k <= p.

>>
>> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
>> I think you'll agree that the condition you describe need not
>> be an actual representable value in a particular conforming
>> implementation.

>
> Sorry, I won't. The only weak point I see is that the standard
> uses the term "model" which admittedly might mean that the
> implementation may use complete different approaches. But my
> preferred interpretation is that "model" means that the
> representation is not broken down to bits (such that e.g. digits
> might be represented by BCD) and that there must be a homomorphism
> to the implementation.
>
> The footnote says that the floating-point _arithmetic_ [emphasis by
> me] may differ from the model; that does not affect the definition
> of a model's floating-point number in p2.
>
> P3 only introduces additional FP numbers (and only for value != 0).


The point of mentioning paragraph 3 is that it only uses the word
'may'; it doesn't state any actual requirements that any
particular numbers, or forms of numbers, be representable.

The point of mentioning the footnote is that it gives a fairly
general licennse for implentations to use different schemes. For
example, I think it would be conforming to implement "floating
point" numbers using scaled, fixed-point arithmetic and use
hundreds or thousands of bits in each 'float' or 'double'.
Focusing on the word 'arithmetic' in the footnote seems like a
red herring to me - a change in how numbers are represented will
naturally lead to a change in how arithmetic works, but if
representation is kept constant then we wouldn't expect a big
variation in how arithmetic works.

For paragraph 1, I think the right word to focus on is not
'model' but 'characteristics' - "The /characteristics/ of
floating types are defined in terms of a model". The point of
this abstraction is to be able to talk about aspects of floating
point numbers without knowing anything about how they will be
represented. Indeed, if floating point numbers are required to
be represented in terms of the model of paragraphs 1 and 2, then
all that is needed is the parameters listed in paragraph 1 -
everything else can be derived from these (plus a little more
information like infinities, NaN's, unnormalized/subnormals, etc,
but that's fairly negligible). The point of the model is to be
able to talk about how we can expect floating-point numbers will
behave /without/ knowing spefically how they are represented.

Finally, last point - even if floating-point numbers are known to
be represented using the form shown in paragraph 2, I don't see
anything in the standard that requires any particular values be
representable; they just have to satisfy the various macro
definitions laid out in 5.2.4.2.2. I believe all of these can
be satisfied using a representation of the form shown in
paragraph 2, but without there being a representation that
is exactly zero.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Phil Carmody <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> Ralf Damaschke <(E-Mail Removed)> writes:
>>
>> > Tim Rentsch <(E-Mail Removed)> wrote:
>> >
>> >> I believe it is possible in principle for 0.0 to be seen as
>> >> true (that is, != 0) in a conforming implementation, if that
>> >> implementation (a) does not have an exact FP representation for
>> >> zero, and (b) has implementation-defined rounding rules which
>> >> are defined suitably. AFAIK both (a) and (b) may be true in a
>> >> conforming implementation, that is, I don't know of any
>> >> requirement that prevents the possibility of either (or of both
>> >> together).
>> >
>> > There is one. An implementation (a) would not suffice C99 5.2.4.2.2
>> > "Characteristics of floating types <float.h>"; esp. the sum used to
>> > define a floating-point number gives 0 if f(k) = 0 for all
>> > 1 <= k <= p.

>>
>> If you read the footnote to 5.2.4.2.2 p1, and also 5.2.4.2.2 p3,
>> I think you'll agree that the condition you describe need not
>> be an actual representable value in a particular conforming
>> implementation. The value does exist in the model, but the
>> model may not reflect what the implementation actually uses,
>> and even if it does, the implementation might not provide FP
>> numbers with f(1) == 0. Needless to say, I did consult this
>> section (and these paragraphs) before making my earlier
>> comments. So I still think it's possible for an implementation
>> to not have zero as a representable FP value.

>
> I don't see how there can be any meaningful values for 5.2.4.2.2 p13
> if zero is non-zero.


I don't see what you're getting at here. Taking 'double' as
the canonical floating-point type, are you talking about
DBL_EPSILON, DBL_MIN, or DBL_TRUE_MIN? I don't see any
problem with any one of these, under a working assumption of
no reprsentation for zero. What am I missing?

> Zero must be less than epsilon, as epsilon must
> be greater than it.


Certainly zero must be less than any positive number. That
doesn't mean zero is representable.

> And zero must me expressible.


Isn't that exactly the question we are trying to answer, ie,
whether floating point types must have a representation for
zero? I don't see that the Standard's requirements imply
that.

> And zero must compare equal to negative zero. That can only be true
> if zero is zero.


Yes, if there is a zero, and if there is a negative zero. I
think the Standard is pretty clear that an implementation
need not have a floating-point negative zero.

> Anyway, logic aside, in this particular case does F.1 apply?
> """
> An implementation that de#nes _ _STDC_IEC_559_ _ shall conform to the
> speci#cations in this annex.
> """
> Which, if it applies, makes them bang to rights.


I'm pretty sure you're right that supprting IEEE floating-point
means there will be a representation for zero. In fact I would be
surprised (though not astonized) if any actual implementation
didn't have a floating-point representation for zero. My question
is, do the Standard's requirements imply that the floating-point
types /must/ have a representation for zero? So far I still think
the answer is no (at least in the hypothetical world of DS9000's,
etc).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
map shall not return an Enumerator ( was re guru help ) Robert Dober Ruby 8 06-23-2009 06:11 PM
What easy technique shall i use in developing a java program that will output to screen or to a file changes/updates made inside a specific directory ...? bronby Java 6 04-22-2005 12:05 PM
what value does lack of return or empty "return;" return Greenhorn C Programming 15 03-06-2005 08:19 PM
DataGrid: Carriage Return in HtmlInputText shall save row Wolfgang Schmidt ASP .Net 2 03-02-2004 12:54 PM
shall I reuse a variable/signal or not? walala VHDL 1 09-14-2003 07:46 PM



Advertisments