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

Groups > comp.lang.c++ > #71498 > unrolled thread

Re: two's complement idea

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:32 +0100
    Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-22 09:23 +0100
      Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 14:20 +0100
        Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 13:37 +0000
      Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:17 -0800
        Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-27 12:35 +0100
          Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:56 -0800
            Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-16 09:17 +0100
              Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2020-02-21 19:35 -0500
                Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-22 07:01 +0100
              Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 08:22 -0800
      Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-24 03:12 +0000
        Re: two's complement idea cdalten@gmail.com - 2020-02-24 05:53 -0800
        Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 07:56 -0800
          Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-25 22:00 +0000
            Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 16:14 -0800
              Re: two's complement idea cdalten@gmail.com - 2020-02-25 18:18 -0800
              Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-26 02:22 +0000

#71498 — Re: two's complement idea

I recently had the problem that I wanted to have a constant which is
size_t wide and where the highest bit is set. I simply solved it that
way (I assume ptrdiff_t as wide as size_t, but this should be common
today on all platforms):
std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
A guarantee from the standard that signed values are 2's-complement
woud be nice for that.

[toc] | [next] | [standalone]

#71499

On 22.01.2020 08:32, Bonita Montero wrote:
> I recently had the problem that I wanted to have a constant which is
> size_t wide and where the highest bit is set. I simply solved it that
> way (I assume ptrdiff_t as wide as size_t, but this should be common
> today on all platforms):
> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
> A guarantee from the standard that signed values are 2's-complement
> woud be nice for that.

C++20 will give you that guarantee.

But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 
guarantees.

Every time I discover a vastly simpler way of doing something, so that I 
prove myself stupid, I feel more optimistic since evidently my mind is 
still working.


- Alf

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

#71512

> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 
> guarantees.

I think it would be better to write (size_t)(ptrdiff_t)-1 because
the conversion of signed ints to size_t is UB when the int is nega-
tive. I.e. the compiler could first make the value unsigned and then
extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit
-machine. With the above cast to ptrdiff_t you have at least the
guarantee that the value is widened with its sign.

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

#71514

On Wed, 22 Jan 2020 14:20:08 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> > But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 
> > guarantees.
> 
> I think it would be better to write (size_t)(ptrdiff_t)-1 because
> the conversion of signed ints to size_t is UB when the int is nega-
> tive. I.e. the compiler could first make the value unsigned and then
> extend the value that you might get 0x00000000FFFFFFFFu on a 64-bit
> -machine. With the above cast to ptrdiff_t you have at least the
> guarantee that the value is widened with its sign.

size_t(-1) has defined behaviour in C++, if that is your point.  The
representation depends on the size and signedness of the destination,
not the source:

"A prvalue of an integer type can be converted to a prvalue of another
integer type ... . If the destination type is unsigned, the resulting
value is the least unsigned integer congruent to the source integer
(modulo 2 n where n is the number of bits used to represent the
unsigned type). [ Note: In a two’s complement representation, this
conversion is conceptual and there is no change in the bit pattern (if
there is no truncation). — end note ]"

size_t(-1) will always give you all bits set, whatever the signed
representation of -1 (bits will be altered if necessary).

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

#71616

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> On 22.01.2020 08:32, Bonita Montero wrote:
>
>> I recently had the problem that I wanted to have a constant which is
>> size_t wide and where the highest bit is set.  I simply solved it that
>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>> today on all platforms):
>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>> A guarantee from the standard that signed values are 2's-complement
>> woud be nice for that.
>
> C++20 will give you that guarantee.
>
> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
> guarantees.

Or just size_t(-1)/2+1.

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

#71622

On 27.01.2020 10:17, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> 
>> On 22.01.2020 08:32, Bonita Montero wrote:
>>
>>> I recently had the problem that I wanted to have a constant which is
>>> size_t wide and where the highest bit is set.  I simply solved it that
>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>> today on all platforms):
>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>> A guarantee from the standard that signed values are 2's-complement
>>> woud be nice for that.
>>
>> C++20 will give you that guarantee.
>>
>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>> guarantees.
> 
> Or just size_t(-1)/2+1.

Or ~(size_t(-1)/2).

There.

:-)

Thanks,

- Alf

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

#71855

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> On 27.01.2020 10:17, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>
>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>
>>>> I recently had the problem that I wanted to have a constant which is
>>>> size_t wide and where the highest bit is set.  I simply solved it that
>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>> today on all platforms):
>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>>> A guarantee from the standard that signed values are 2's-complement
>>>> woud be nice for that.
>>>
>>> C++20 will give you that guarantee.
>>>
>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>> guarantees.
>>
>> Or just size_t(-1)/2+1.
>
> Or ~(size_t(-1)/2).

In practice that is highly likely to work, but strictly speaking
it is not guaranteed (at least not in C;  I believe that holds
also in C++ but I am less well-versed in the C++ standard than
the C standard).  The reason is size_t is not required to be at
least as wide as int, so the ~ could produce a negative value.

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

#71868

On 15.02.2020 14:56, Tim Rentsch wrote:
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
> 
>> On 27.01.2020 10:17, Tim Rentsch wrote:
>>
>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>
>>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>>
>>>>> I recently had the problem that I wanted to have a constant which is
>>>>> size_t wide and where the highest bit is set.  I simply solved it that
>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>>> today on all platforms):
>>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>>>> A guarantee from the standard that signed values are 2's-complement
>>>>> woud be nice for that.
>>>>
>>>> C++20 will give you that guarantee.
>>>>
>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>>> guarantees.
>>>
>>> Or just size_t(-1)/2+1.
>>
>> Or ~(size_t(-1)/2).
> 
> In practice that is highly likely to work, but strictly speaking
> it is not guaranteed (at least not in C;  I believe that holds
> also in C++ but I am less well-versed in the C++ standard than
> the C standard).  The reason is size_t is not required to be at
> least as wide as int, so the ~ could produce a negative value.

Interesting point.

Does any C or C++ implemention with sizeof(size_t) < sizeof(int) exist, 
or has any such implementation existed?

Fix: `~(size_t(-1)/2u)`. But the question is, since code is about 
communicating to humans, does this communicate the right thing?

- Alf

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

#71938

On 2/16/20 3:17 AM, Alf P. Steinbach wrote:
> On 15.02.2020 14:56, Tim Rentsch wrote:
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>
>>> On 27.01.2020 10:17, Tim Rentsch wrote:
>>>
>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>
>>>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>>>
>>>>>> I recently had the problem that I wanted to have a constant which is
>>>>>> size_t wide and where the highest bit is set.  I simply solved it 
>>>>>> that
>>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>>>> today on all platforms):
>>>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>>>>> A guarantee from the standard that signed values are 2's-complement
>>>>>> woud be nice for that.
>>>>>
>>>>> C++20 will give you that guarantee.
>>>>>
>>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>>>> guarantees.
>>>>
>>>> Or just size_t(-1)/2+1.
>>>
>>> Or ~(size_t(-1)/2).
>>
>> In practice that is highly likely to work, but strictly speaking
>> it is not guaranteed (at least not in C;  I believe that holds
>> also in C++ but I am less well-versed in the C++ standard than
>> the C standard).  The reason is size_t is not required to be at
>> least as wide as int, so the ~ could produce a negative value.
> 
> Interesting point.
> 
> Does any C or C++ implemention with sizeof(size_t) < sizeof(int) exist, 
> or has any such implementation existed?
> 
> Fix: `~(size_t(-1)/2u)`. But the question is, since code is about 
> communicating to humans, does this communicate the right thing?
> 
> - Alf

You still have the issue that if size_t is smaller than int (and 
unsigned) the ~ operator will set more bits then the upper bit of size_t

maybe

size_t(~(size_t(-1)/2u)))
but the +1 version I think is cleaner.

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

#71939

On 22.02.2020 01:35, Richard Damon wrote:
> On 2/16/20 3:17 AM, Alf P. Steinbach wrote:
>> On 15.02.2020 14:56, Tim Rentsch wrote:
>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>
>>>> On 27.01.2020 10:17, Tim Rentsch wrote:
>>>>
>>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>>
>>>>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>>>>
>>>>>>> I recently had the problem that I wanted to have a constant which is
>>>>>>> size_t wide and where the highest bit is set.  I simply solved it 
>>>>>>> that
>>>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>>>>> today on all platforms):
>>>>>>> std::size_t const SIZE_T_MSB = 
>>>>>>> std::numeric_limits<ptrdiff_t>::min();
>>>>>>> A guarantee from the standard that signed values are 2's-complement
>>>>>>> woud be nice for that.
>>>>>>
>>>>>> C++20 will give you that guarantee.
>>>>>>
>>>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>>>>> guarantees.
>>>>>
>>>>> Or just size_t(-1)/2+1.
>>>>
>>>> Or ~(size_t(-1)/2).
>>>
>>> In practice that is highly likely to work, but strictly speaking
>>> it is not guaranteed (at least not in C;  I believe that holds
>>> also in C++ but I am less well-versed in the C++ standard than
>>> the C standard).  The reason is size_t is not required to be at
>>> least as wide as int, so the ~ could produce a negative value.
>>
>> Interesting point.
>>
>> Does any C or C++ implemention with sizeof(size_t) < sizeof(int) 
>> exist, or has any such implementation existed?
>>
>> Fix: `~(size_t(-1)/2u)`. But the question is, since code is about 
>> communicating to humans, does this communicate the right thing?
>>
>> - Alf
> 
> You still have the issue that if size_t is smaller than int (and 
> unsigned) the ~ operator will set more bits then the upper bit of size_t

Not in the given context, as initializer for a `size_t` constant.


> maybe
> 
> size_t(~(size_t(-1)/2u)))
> but the +1 version I think is cleaner.

Not needed. :)


- Alf

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

#72005

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:

> On 15.02.2020 14:56, Tim Rentsch wrote:
>
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>
>>> On 27.01.2020 10:17, Tim Rentsch wrote:
>>>
>>>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
>>>>
>>>>> On 22.01.2020 08:32, Bonita Montero wrote:
>>>>>
>>>>>> I recently had the problem that I wanted to have a constant which is
>>>>>> size_t wide and where the highest bit is set.  I simply solved it that
>>>>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>>>>> today on all platforms):
>>>>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>>>>> A guarantee from the standard that signed values are 2's-complement
>>>>>> woud be nice for that.
>>>>>
>>>>> C++20 will give you that guarantee.
>>>>>
>>>>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>>>>> guarantees.
>>>>
>>>> Or just size_t(-1)/2+1.
>>>
>>> Or ~(size_t(-1)/2).
>>
>> In practice that is highly likely to work, but strictly speaking
>> it is not guaranteed (at least not in C;  I believe that holds
>> also in C++ but I am less well-versed in the C++ standard than
>> the C standard).  The reason is size_t is not required to be at
>> least as wide as int, so the ~ could produce a negative value.
>
> Interesting point.
>
> Does any C or C++ implemention with sizeof(size_t) < sizeof(int)
> exist, or has any such implementation existed?

I doubt it.  Certainly I don't know of any.

> Fix:  `~(size_t(-1)/2u)`. But the question is, since code is about
> communicating to humans, does this communicate the right thing?

I prefer the form I gave, because it's easer to see that the
value it produces is correct, and because it is less brittle, in
the sense that it doesn't depend on surrounding context to
produce the correct value.  Come to think of it though I would
change it slightly, to get a form that works in both C and C++:

    (size_t)-1 /2 +1

Normally in cases like this I would look for an alternative that
does not use a cast.  Here though I think a cast is necessary:
other possible ways of robustly getting the right value all are
worse in one way or another AFAICS.  Of course, if <stdint.h>
has been #include'd, we could use

    SIZE_MAX/2 + 1

which uses neither a cast nor the converting of -1.  So that's
probably better, in most circumstances, than the other forms
mentioned.

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

#71988

In article <r090qk$dv2$1@dont-email.me>,
Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>On 22.01.2020 08:32, Bonita Montero wrote:
>> I recently had the problem that I wanted to have a constant which is
>> size_t wide and where the highest bit is set. I simply solved it that
>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>> today on all platforms):
>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>> A guarantee from the standard that signed values are 2's-complement
>> woud be nice for that.
>
>C++20 will give you that guarantee.
>
>But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 
>guarantees.

Hmm, can't one simply compute:

	~(size_t)0 ^ (~(size_t)0 >> 1)

?

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

#72002

On Sunday, February 23, 2020 at 7:12:31 PM UTC-8, Dan Cross wrote:
> In article <r090qk$dv2$1@dont-email.me>,
> Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
> >On 22.01.2020 08:32, Bonita Montero wrote:
> >> I recently had the problem that I wanted to have a constant which is
> >> size_t wide and where the highest bit is set. I simply solved it that
> >> way (I assume ptrdiff_t as wide as size_t, but this should be common
> >> today on all platforms):
> >> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
> >> A guarantee from the standard that signed values are 2's-complement
> >> woud be nice for that.
> >
> >C++20 will give you that guarantee.
> >
> >But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98 
> >guarantees.
> 
> Hmm, can't one simply compute:
> 
> 	~(size_t)0 ^ (~(size_t)0 >> 1)
> 
> ?

Bad Dan. No cookie.

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

#72021

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <r090qk$dv2$1@dont-email.me>,
> Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
>
>> On 22.01.2020 08:32, Bonita Montero wrote:
>>
>>> I recently had the problem that I wanted to have a constant which is
>>> size_t wide and where the highest bit is set.  I simply solved it that
>>> way (I assume ptrdiff_t as wide as size_t, but this should be common
>>> today on all platforms):
>>> std::size_t const SIZE_T_MSB = std::numeric_limits<ptrdiff_t>::min();
>>> A guarantee from the standard that signed values are 2's-complement
>>> woud be nice for that.
>>
>> C++20 will give you that guarantee.
>>
>> But e.g. `size_t(-1) - size_t(-1)/2` does the job with just C++98
>> guarantees.
>
> Hmm, can't one simply compute:
>
>     ~(size_t)0 ^ (~(size_t)0 >> 1)
>
> ?

Why not just this?  (size_t)-1 /2 +1

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

#72022

In article <86y2sqace9.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>Why not just this?  (size_t)-1 /2 +1

Because I didn't think of it before you posted
it, Tim. :-)

	- Dan C.

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

#72023

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <86y2sqace9.fsf@linuxsc.com>,
> Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>
>> Why not just this?  (size_t)-1 /2 +1
>
> Because I didn't think of it before you posted
> it, Tim. :-)

Thank you for that Dan.  It's good to see you back
in the newsgroups again.

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

#72024

Since Dan Cross has me blocked because I called him out for the wife beater that he is, let me try to fill you in on my Cross has been MIA.

Background. Dan is a Math guy who used to serve in the USMC. At the time he was dating some Russian woman. They broke up because he got tired of her being the "man" in the relationship. Now let's fast forward. He found some chick from the Gaza Strip that was desperate enough to date him. They've stuck together because she let's him be the man in the relationship. They even have a kid! He also likes the fact that he can beat his gf. Whereas with the Russian woman, well, everytime that he got pissed off, she basically beat his ass. This despite that fact that he was in the USMC!

These days he spends a lot of time on arbornet.org and grex.org. He goes under the name of cross on both of these sites. He prefers to hang out there because both systems are dominated by fat, middle aged, balding white men. He talks to the menz on these sites all the time just in case his current girlfriend finds a real man. Why? So he could date one of these guys!!! 

Dan Cross isn't getting any younger. It's now getting to the point where he will settle down with anything on two legs. This could be male, female, or shemale.

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

#72025

In article <86tv3e9pc4.fsf@linuxsc.com>,
Tim Rentsch  <tr.17687@z991.linuxsc.com> wrote:
>> Because I didn't think of it before you posted
>> it, Tim. :-)
>
>Thank you for that Dan.  It's good to see you back
>in the newsgroups again.

Thanks, Tim!  It's nice to be reading.

	- Dan C.

[toc] | [prev] | [standalone]

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

csiph-web