Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > zero up memory

Reply
Thread Tools

zero up memory

 
 
Malcolm McLean
Guest
Posts: n/a
 
      01-25-2012
On Jan 24, 10:43*pm, James Kuyper <(E-Mail Removed)> wrote:
>
> The case that I'm most familiar with, IEEE 754 double precision,
> sub-normal numbers have an exponent of 0,
> Within this scheme, could you provide an example of the "many possible
> representations for each number" that you're referring to?
>

IEEE denormalised numbers have an exponent of 0 (represents 2^-1023),
but no implicit leading set bit. So very small numbers can be
represented.
Now imagine that instead of an implict set bit, we have a real bit,
which can be toggled on or off, and a floating exponent. Now we can
represent very many numbers in several ways. We can shift the mantissa
right, clear the leading bit, and increment the exponent by one,
without changing the value, assuming that the lost low bit of the
mantissa was clear.

So my question was, how to do efficent tests for equality, on such an
architecture?
--
MPI tutorial. Learn parallel programming in C.
http://www.malcolmmclean.site11.com/www
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      01-25-2012
On 01/24/2012 07:29 PM, Malcolm McLean wrote:
> On Jan 24, 10:43�pm, James Kuyper <(E-Mail Removed)> wrote:
>>
>> The case that I'm most familiar with, IEEE 754 double precision,
>> sub-normal numbers have an exponent of 0,
>> Within this scheme, could you provide an example of the "many possible
>> representations for each number" that you're referring to?
>>

> IEEE denormalised numbers have an exponent of 0 (represents 2^-1023),
> but no implicit leading set bit. So very small numbers can be
> represented.


Am I right in assuming that you concede the feasibility of efficiently
implemented equality comparisons involving IEEE 754 sub-normals?

> Now imagine that instead of an implict set bit, we have a real bit,
> which can be toggled on or off, and a floating exponent. Now we can
> represent very many numbers in several ways. We can shift the mantissa
> right, clear the leading bit, and increment the exponent by one,
> without changing the value, assuming that the lost low bit of the
> mantissa was clear.


You're no longer talking about IEEE 754 sub-normals, I presume.
Incrementing the exponent on a sub-normal would make it non-zero, so it
would no longer be considered sub-normal. As a normal number, it would
be interpreted as having an implicit leading bit, which would change the
value. Therefore, I presume you're talking about some alternative
floating point representation.

....
> So my question was, how to do efficent tests for equality, on such an
> architecture?


I don't know. Has anyone other than you been talking about such an
architecture on this thread?

There is some ambiguity about terminology here. I've heard terms such as
unnormalized, denormalized, and sub-normal all used to refer to the same
basic idea. According to the documentation I've seen, sub-normal seems
to be IEEE's preferred term. When you read Ben's first message about
"unnormalized numbers" it's quite clear that he was talking about what
IEEE calls sub-normals, for which the exponent must be 0; and not about
anything resembling the architecture you describe.
--
James Kuyper
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      01-25-2012
On Jan 25, 2:43*am, James Kuyper <(E-Mail Removed)> wrote:
>
> Am I right in assuming that you concede the feasibility of efficiently
> implemented equality comparisons involving IEEE 754 sub-normals?


I'm answering this:

Ben Bacarisse

In systems where the mantissa is not normalised (i.e. there is no
implicit leading 1) then zero is specified quite naturally with a
zero
mantissa. A zero sign bit and exponent (even it biased) makes no
difference. Systems like this are common: IEEE decimal floating
point
and IBM's hexadecimal floating point come to mind.

With IEEE 754 sub-normals, the problem doesn't arise, because the
exponent is fixed.

 
Reply With Quote
 
Kleuske
Guest
Posts: n/a
 
      01-25-2012
On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish the
following:

> Johann Klammer <(E-Mail Removed)1.net> writes:
>> Malcolm McLean wrote:
>>> So how does the processor do equality comparisons, efficiently?
>>>
>>> If the mantissa is not normalized then there are many possible
>>> representations for each number, including zero.

>>
>> Usually one does an epsilon test.
>> with epsilon rather small
>>
>> if(((a+epsilon)<b)&&((a-epsilon)>b))
>> {
>>
>> }

>
> That doesn't address the question, which is how the processor performs a
> floating-point equality test, the one specified by C's "==" operator.


In fact it did, if only in passing. The comparison is a bit-wise one, IIRC,
and using '==' for floats and doubles is strongly discouraged where i work.

I think it might be a universal best practice.




--
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8
 
Reply With Quote
 
Kleuske
Guest
Posts: n/a
 
      01-25-2012
On Wed, 25 Jan 2012 15:39:15 +0000, Kleuske saw fit to publish the
following:

> On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish
> the following:
>
>> Johann Klammer <(E-Mail Removed)1.net> writes:

<snip>
>>> if(((a+epsilon)<b)&&((a-epsilon)>b))
>>> {
>>>
>>> }

>>
>> That doesn't address the question, which is how the processor performs
>> a floating-point equality test, the one specified by C's "==" operator.

>
> In fact it did, if only in passing. The comparison is a bit-wise one,
> IIRC, and using '==' for floats and doubles is strongly discouraged
> where i work.


"Strongly discouraged" as in "Do it again, and you're fired".

--
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-25-2012
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:

<snip>
>> I don't know any FP
>> format that does not have multiple representations that must compare
>> equal (+0 and -1 being the most common example).

>
> I think you mean +0 and -0.


<facepalm> Thanks.

--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-25-2012
James Kuyper <(E-Mail Removed)> writes:
<snip>
> When you read Ben's first message about
> "unnormalized numbers" it's quite clear that he was talking about what
> IEEE calls sub-normals, for which the exponent must be 0; and not about
> anything resembling the architecture you describe.


Actually I wasn't. I was referring to representation with no "hidden
bit". It's linked to normalisation because, when the base is > 2 there
can be leading zeros in the mantissa even when the number is
"normalised" (mantissa shifted as far left as possible).

IBM machine use/used such a format. The result is that there are lots
of zeros: a zero mantissa does not mean 0.1xxx... but 0 so the exponent
has no effect on the value.

--
Ben.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-25-2012
Malcolm McLean <(E-Mail Removed)> writes:

> On Jan 25, 2:43*am, James Kuyper <(E-Mail Removed)> wrote:
>>
>> Am I right in assuming that you concede the feasibility of efficiently
>> implemented equality comparisons involving IEEE 754 sub-normals?

>
> I'm answering this:
>
> Ben Bacarisse
>
> In systems where the mantissa is not normalised (i.e. there is no
> implicit leading 1) then zero is specified quite naturally with a zero
> mantissa. A zero sign bit and exponent (even it biased) makes no
> difference. Systems like this are common: IEEE decimal floating point
> and IBM's hexadecimal floating point come to mind.


s/is not normalised/has no hidden bit/

I should not have conflated this with normalisation though my excuse is
that such formats can have leading zero bits in the mantissa so the
"look" un-normalised.

It does not alter the issue that there are then a very large number of
representations of zero.

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-25-2012
On 01/25/2012 12:48 PM, Ben Bacarisse wrote:
> James Kuyper <(E-Mail Removed)> writes:
> <snip>
>> When you read Ben's first message about
>> "unnormalized numbers" it's quite clear that he was talking about what
>> IEEE calls sub-normals, for which the exponent must be 0; and not about
>> anything resembling the architecture you describe.

>
> Actually I wasn't. I was referring to representation with no "hidden
> bit". It's linked to normalisation because, when the base is > 2 there
> can be leading zeros in the mantissa even when the number is
> "normalised" (mantissa shifted as far left as possible).
>
> IBM machine use/used such a format. The result is that there are lots
> of zeros: a zero mantissa does not mean 0.1xxx... but 0 so the exponent
> has no effect on the value.


I read "unnormalized", and didn't pay close enough attention to realize
that you were talking about something more exotic than ordinary IEEE 754
sub-normals. After Malcolm's last message I looked up "decimal floating
point" and learned that it has precisely the feature he was talking
about. I apologize for my confusion, and any confusion I may have caused.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      01-25-2012
Robert Wessel <(E-Mail Removed)> writes:

> FWIW, a slightly closer to common example is the 80-bit real format on
> x87. While still binary, it does not have the implicit (hidden) one
> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
> where the mantissa is zero but the exponent is not. Early versions of
> the x87 treated those mostly as true zeros, but since the 387 (I
> think), pseudo-zeros have been disallowed.


I've never understood why the 80-bit format differs from the 32-
and 64-bit formats in this respect.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}
 
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
zero memory Christopher Pisz C++ 25 04-09-2007 04:11 AM
Can you set a class instance's attributes to zero by setting the instance to zero? Gerard Flanagan Python 3 11-19-2005 06:58 PM
Wireless Zero Configuration Memory Leak?? =?Utf-8?B?Umlja3NjaHVsdHox?= Wireless Networking 3 01-19-2005 11:26 PM
Doubles and zero/negative zero Christopher Benson-Manica C Programming 4 07-01-2004 05:44 PM
memset all bits to zero will let float/double to zero? Zhiqiang Ye C Programming 53 06-28-2004 01:23 PM



Advertisments