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

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

zero up memory

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

Contents

  zero up memory "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-01-23 10:51 -0500
    Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 16:30 +0000
    Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-23 17:57 +0100
      Re: zero up memory Kenneth Brody <kenbrody@spamcop.net> - 2012-01-23 12:07 -0500
      Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 09:08 -0800
        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 09:22 -0800
          Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 10:13 -0800
            Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 12:00 -0800
          Re: zero up memory Kaz Kylheku <kaz@kylheku.com> - 2012-01-23 20:14 +0000
            Re: zero up memory "Joel C. Salomon" <joelcsalomon@gmail.com> - 2012-01-23 16:46 -0500
            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 14:05 -0800
              Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 23:21 +0000
                Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 09:35 -0800
                  Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-24 20:56 +0000
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:07 -0800
                      Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:38 +0000
                  Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-24 23:15 +0100
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:31 -0800
                      Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:39 +0000
                        Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:49 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:09 -0800
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-25 13:05 -0800
                          Re: zero up memory Sjouke Burry <s@b> - 2012-01-25 23:25 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:11 -0800
                            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-26 11:48 -0800
                            Re: zero up memory gordonb.p79fg@burditt.org (Gordon Burditt) - 2012-03-12 17:55 -0500
                              Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 22:10 -0400
                                Re: zero up memory Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-03-12 23:24 -0400
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 23:53 -0400
                                Re: zero up memory gordonb.pu5nu@burditt.org (Gordon Burditt) - 2012-03-13 00:58 -0500
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-14 11:17 -0400
                          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-26 11:19 -0800
                            Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-27 08:13 +0000
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:42 +0000
                        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-25 12:33 -0800
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:12 +0000
                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 17:43 -0500
                    Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 16:29 -0800
                      Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 21:43 -0500
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 23:58 -0800
                          Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:52 +0000
                        Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:48 +0000
                          Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 12:15 -0600
                            Re: zero up memory blp@cs.stanford.edu (Ben Pfaff) - 2012-01-25 10:35 -0800
                              Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:15 -0600
                                Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:23 -0600
                                Re: zero up memory "BartC" <bc@freeuk.com> - 2012-01-25 23:51 +0000
                                  Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-26 18:35 -0600
                          Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-25 13:17 -0500
            Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 22:55 +0000
        Re: zero up memory jgk@panix.com (Joe keane) - 2012-01-24 20:45 +0000
          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:13 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16211

On Jan 25, 3:49 pm, Kleuske <kleu...@nowhere.net> wrote:
> 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 <klamm...@NOSPAM.a1.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".

it sometimes makes sense. For instance floating point variables can be
used to hold integers. As long as you're careful with / and % you can
safely do == tests. If I initialise a variable to 0.0 and do no
operations on it it will test equal to 0.0. Hence I can test if it's
only been initialised.

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

#16206

On Jan 25, 3:39 pm, Kleuske <kleu...@nowhere.net> wrote:
>
> 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.
>
If you're comparing reals for equality, usually it means that there's
something logically wrong in what you're doing, and bunging in a +/-
epsilon is only masking the problem.

But there are exceptions of course. An example would be if you want to
check that two data items are actually copies of each other.

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

#16209

Malcolm McLean <malcolm.mclean5@btinternet.com> wrote in
news:895944d1-8cd9-4f0f-9d82-fef14fd81888@l1g2000vbc.googlegroups.com: 

> On Jan 25, 3:39 pm, Kleuske <kleu...@nowhere.net> wrote:
>>
>> In fact it did, if only in passing. The comparison is a bit-wise one,
>> IIR 
> C,
>> and using '==' for floats and doubles is strongly discouraged where i
>  work.
>>
>> I think it might be a universal best practice.
>>
> If you're comparing reals for equality, usually it means that there's
> something logically wrong in what you're doing, and bunging in a +/-
> epsilon is only masking the problem.
> 
> But there are exceptions of course. An example would be if you want to
> check that two data items are actually copies of each other.
> 
> 
> 

Also I have used == for inserting a flag value in data.
They compare OK, because flag and testvalue are not
the result of a calculation, and far out of range of the data.

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

#16212

On Jan 25, 9:05 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Jan 25, 3:39 pm, Kleuske <kleu...@nowhere.net> wrote:
>
> > 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.
>
> If you're comparing reals for equality, usually it means that there's
> something logically wrong in what you're doing, and bunging in a +/-
> epsilon is only masking the problem.

why? If I want to test if something is near zero what is wrong with
epsilon tests?

> But there are exceptions of course. An example would be if you want to
> check that two data items are actually copies of each other.

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

#16267

On Jan 26, 11:11 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
>
> why? If I want to test if something is near zero what is wrong with
> epsilon tests?
>
There are two questions you might be asking:

1) is the answer actually zero but my floating point unit not good
enough to give a value of zero?

2) is the value so close to zero that I can regard it as zero?

Both questions are likely to involve you in difficulties and
subtleties. If you can answer those difficulties and subtleties, then
a test involving epsilon might be appropriate. Just reflexively
bunging in fabs(x - Y) < epsilon where the logic says x == y is
unlikely to be a good idea.

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

#18613

> why? If I want to test if something is near zero what is wrong with
> epsilon tests?

Please describe how to calculate epsilon, given a situation where you'd
use it, with a good reason why it shouldn't be larger or smaller by
even a little bit.  No one seems willing to address this point.

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

#18623

On 03/12/2012 06:55 PM, Gordon Burditt wrote:
>> why? If I want to test if something is near zero what is wrong with
>> epsilon tests?
> 
> Please describe how to calculate epsilon, given a situation where you'd
> use it,

For many purposes I want to cope with the possibility that ratio =
numerator/denominator might overflow, by checking whether |denominator|
<= epsilon, where epsilon = DBL_MAX/|numerator|.

> with a good reason why it shouldn't be larger or smaller by
> even a little bit. ...

The concept that any floating point number (including epsilon) must have
some particular exact value is inconsistent with the ubiquity of
floating point round-off errors.
-- 
James Kuyper

Permission to quote this message, or any part thereof, without proper
attribution is denied.

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

#18626

On 3/12/2012 10:10 PM, James Kuyper wrote:
> On 03/12/2012 06:55 PM, Gordon Burditt wrote:
>>> why? If I want to test if something is near zero what is wrong with
>>> epsilon tests?
>>
>> Please describe how to calculate epsilon, given a situation where you'd
>> use it,
>
> For many purposes I want to cope with the possibility that ratio =
> numerator/denominator might overflow, by checking whether |denominator|
> <= epsilon, where epsilon = DBL_MAX/|numerator|.
>
>> with a good reason why it shouldn't be larger or smaller by
>> even a little bit. ...
>
> The concept that any floating point number (including epsilon) must have
> some particular exact value is inconsistent with the ubiquity of
> floating point round-off errors.

     Every floating-point number, except for infinities and NaN's on
systems that provide them, has an exact value.

     It mightn't be the value you hoped for, but it's exact.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#18627

On 03/12/2012 11:24 PM, Eric Sosman wrote:
> On 3/12/2012 10:10 PM, James Kuyper wrote:
>> On 03/12/2012 06:55 PM, Gordon Burditt wrote:
...
>>> with a good reason why it shouldn't be larger or smaller by
>>> even a little bit. ...
>>
>> The concept that any floating point number (including epsilon) must have
>> some particular exact value is inconsistent with the ubiquity of
>> floating point round-off errors.
> 
>      Every floating-point number, except for infinities and NaN's on
> systems that provide them, has an exact value.
> 
>      It mightn't be the value you hoped for, but it's exact.

The value that you were hoping it to have which is not necessarily
exactly the same as the value it actually has, at least not it if it's
the result of several intermediate calculations. and that's what I was
talking about.




-- 
James Kuyper

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

#18638

> For many purposes I want to cope with the possibility that ratio =
> numerator/denominator might overflow, by checking whether |denominator|
> <= epsilon, where epsilon = DBL_MAX/|numerator|.

And you check that this value of epsilon doesn't overflow first, right?

>> with a good reason why it shouldn't be larger or smaller by
>> even a little bit. ...
> 
> The concept that any floating point number (including epsilon) must have
> some particular exact value is inconsistent with the ubiquity of
> floating point round-off errors.

Well, I was originally thinking about justifying why it shouldn't
be larger or smaller by 20%, but most of the handwaving involving
a value of epsilon doesn't justify why it shouldn't be a a factor
of 1000 larger or smaller.

If your problem is so unstable that roundoff error causes a few
orders of magnitude difference in epsilon, I don't think your tests
using it are going to be worth much.

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

#18767

On 03/13/2012 01:58 AM, Gordon Burditt wrote:

I explicitly told you that "Permission to quote this message, or any
part thereof, without proper attribution is denied." I realize that you
have fears about the supposed dangers of properly attributing your
quotations - but I insist that, at least where my messages are involved,
you deal with those fears by either temporarily ignoring them, or by not
quoting me.

>> For many purposes I want to cope with the possibility that ratio =
>> numerator/denominator might overflow, by checking whether |denominator|
>> <= epsilon, where epsilon = DBL_MAX/|numerator|.
> 
> And you check that this value of epsilon doesn't overflow first, right?

Ugh! Better yet, when I'm adequately awake, I check to make sure the
expression was correct:

	epsilon = |numerator|/DBL_MAX

That calculation cannot overflow.

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

#16217

Kleuske <kleuske@nowhere.net> writes:
[...]
> In one of my hobby projects, however, the user perform math in a toy
> language, and, rather than stunning the user with the absence of a
> equality operator for reals, decided to implement one using the above
> method and an epsilon the user can specify.

The loss of transitivity can be a problem, though.  With such a
definition of equality, x == y && y == z doesn't imply x == z.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16281

On Thu, 26 Jan 2012 11:19:59 -0800, Keith Thompson saw fit to publish the
following:

> Kleuske <kleuske@nowhere.net> writes: [...]
>> In one of my hobby projects, however, the user perform math in a toy
>> language, and, rather than stunning the user with the absence of a
>> equality operator for reals, decided to implement one using the above
>> method and an epsilon the user can specify.
> 
> The loss of transitivity can be a problem, though.  With such a
> definition of equality, x == y && y == z doesn't imply x == z.

Correct. That's one of the problems. It's not one that keeps me awake
at night, though. At least in the context I used it in.

-- 

Humans do claim a great deal for that particular emotion (love).
		-- Spock, "The Lights of Zetar", stardate 5725.6

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

#16258

On Wed, 25 Jan 2012 13:05:53 -0800, Malcolm McLean saw fit to publish the
following:

> On Jan 25, 3:39 pm, Kleuske <kleu...@nowhere.net> wrote:
>>
>> 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.
>>
> If you're comparing reals for equality, usually it means that there's
> something logically wrong in what you're doing, and bunging in a +/-
> epsilon is only masking the problem.

I usually don't use reals at all, only when absolutely required, but that's
another matter.

In fields where they are required, i suppose the logic dictates you first put
your equations in a form that preserves as much precision as possible. But
that's maths. Since you probably have many different calculations, an
appropriate epsilon cannot sensibly be a single constant, since it not only
depends on math applied, but also on the physical tolerances of the input and
any "equality-checking" degrades to checking whether or not something falls in
some specified range, which is a different kettle of fish.

In that way, you are (probably) right.

> But there are exceptions of course. An example would be if you want to
> check that two data items are actually copies of each other.

In one of my hobby projects, however, the user perform math in a toy language,
and, rather than stunning the user with the absence of a equality operator for
reals, decided to implement one using the above method and an epsilon the
user can specify.

-- 
No one wants war.
		-- Kirk, "Errand of Mercy", stardate 3201.7

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

#16225

Kleuske <kleuske@nowhere.net> writes:
> On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish the
> following:
>
>> Johann Klammer <klammerj@NOSPAM.a1.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.

But that has nothing to do with the original question, which was about
how "==" is implemented, *not* whether it's a good idea to use it.

Floating-point "==" is *not* simply bitwise comparison.  If the values
stored in x and y are positive and negative zero, then "x == y" must
yield 1.  If x and y are both NaNs with the same representation (for
implementations that support NaNs), then "x == y" must yield 0.

BTW, there are cases where floating-point "==" is well defined.  For
example, if this:

    if (1.0 + 1.0 == 2.0) puts("ok");

doesn't print "ok", then there's something wrong with your
implementation (certainly if __STDC_IEC_559__ is defined; I'm
less certain of that if it isn't).  A policy that forbids using
floating-point "==" in all cases is overkill.

(Not that overkill is necessarily inappropriate in all cases.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#16257

On Wed, 25 Jan 2012 12:33:08 -0800, Keith Thompson saw fit to publish the
following:

> Kleuske <kleuske@nowhere.net> writes:
>> On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish
>> the following:
>>
>>> Johann Klammer <klammerj@NOSPAM.a1.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.
> 
> But that has nothing to do with the original question, which was about
> how "==" is implemented, *not* whether it's a good idea to use it.

That's the good thing about USENET threads. You are usually allowed to
digress a little.

> Floating-point "==" is *not* simply bitwise comparison.  If the values
> stored in x and y are positive and negative zero, then "x == y" must
> yield 1.  If x and y are both NaNs with the same representation (for
> implementations that support NaNs), then "x == y" must yield 0.

Ok. Bitwise comparison with a few caveats. Point was, using '==' on
reals is generally a bad idea. There are exceptions to the rule, as
there always are, but still.

> BTW, there are cases where floating-point "==" is well defined.  For
> example, if this:
> 
>     if (1.0 + 1.0 == 2.0) puts("ok");
> 
> doesn't print "ok", then there's something wrong with your
> implementation (certainly if __STDC_IEC_559__ is defined; I'm less
> certain of that if it isn't).  A policy that forbids using
> floating-point "==" in all cases is overkill.

AFAIK, defining '__STDC_IEC_559__' isn't a requirement and unless the
above is hardcoded, you can never guarantee the values behave nicely.

> (Not that overkill is necessarily inappropriate in all cases.)

hmmm...

-- 
She won' go Warp 7, Cap'n!  The batteries are dead!

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

#16137

On 01/24/2012 12:35 PM, Malcolm McLean wrote:
> On Jan 23, 11:21 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> 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.
>>
> 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.

The case that I'm most familiar with, IEEE 754 double precision,
sub-normal numbers have an exponent of 0, a sign bit, and 52 bits of
mantissa, and represent the values (-1)^sign * mantissa* 2^(-1022-52).
The smallest positive value that can be represented is 2^(-1074), the
largest is 2^(-1022) - 2^(-1074).

For normal numbers, 0<exponent && exponent < 0x7FF. The value
represented is (-1)^sign*(1.mantissa)*2^(exponent - 1023). The smallest
positive value represented by this mechanism occurs when mantissa is 0
and exponent is 1, which represents 2^(-1022). That is exactly 2^-1074
bigger than the biggest subnormal value.

The exponent value 0x7FF is reserved for infinities and NaNs.

There doesn't seem to be any overlap in the ranges of normal and
subnormal values, and within each category, all of the non-zero values
that can be represented have a unique representation. A value of exactly
0 must have it's mantissa and exponent both zero, but can have it's sign
bit either set or cleared. As a result, equality comparisons can be
replaced by memcmp(), except for the special handling required by IEEE
754 for +0, -0, infinities and NaNs.
Within this scheme, could you provide an example of the "many possible
representations for each number" that you're referring to?

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

#16148

On Jan 24, 10:43 pm, James Kuyper <jameskuy...@verizon.net> 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

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

#16169

On 01/24/2012 07:29 PM, Malcolm McLean wrote:
> On Jan 24, 10:43�pm, James Kuyper <jameskuy...@verizon.net> 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

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

#16180

On Jan 25, 2:43 am, James Kuyper <jameskuy...@verizon.net> 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.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web