jak ha scritto:
> Tim Rentsch ha scritto:
>> jak <nospam@please.ty> writes:
>>
>>> unsigned long h_bit(unsigned long val)
>>> {
>>>      int i;
>>>      for(i = 0; val > 1; val /= 2, i++);
>>>      return val << i;
>>> }
>>
>> A nice compact solution.  I like the way it
>> naturally deals with the case when val is zero.
>>
>
> This is not true because if Val is 0 also the bit shifted to left is,
> so also its result is 0. This one of the reason why the exit from the
> loop is greater than 1.
>

Sorry about the answer. I have translated your comment badly.

On 2023-10-11, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> E.g. 32 bit code:
>
> uint32_t fill_mask_down(uint32_t x)
> {
> x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
> x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
> x |= x >> 4; // e.g. 11110000... -> 11111111...
> x |= x >> 8;
> x |= x >> 16;
>
> return x;
> }
>
> Thus:
>
> uint32_t isolate_highest_bit(uint32_t x)
> {
> uint32_t m = fill_mask_down(x);
> return m ^ (m >> 1);
> }
>

I guess this went over people's heads?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Sunday, October 15, 2023 at 8:27:00 AM UTC+3, Kaz Kylheku wrote:
> On 2023-10-11, Kaz Kylheku <864-11...@kylheku.com> wrote:
> > E.g. 32 bit code:
> >
> > uint32_t fill_mask_down(uint32_t x)
> > {
> > x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
> > x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
> > x |= x >> 4; // e.g. 11110000... -> 11111111...
> > x |= x >> 8;
> > x |= x >> 16;
> >
> > return x;
> > }
> >
> > Thus:
> >
> > uint32_t isolate_highest_bit(uint32_t x)
> > {
> > uint32_t m = fill_mask_down(x);
> > return m ^ (m >> 1);
> > }
> >
>
> I guess this went over people's heads?
>
> --
> TXR Programming Language: http://nongnu.org/txr
> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
> Mastodon: @Kazi...@mstdn.ca
> NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Not over my head.
My O(log(N)) variant is inspired by your solution.
It is essentially the same like yours, with only difference that I tried to meet
requirement of Tim Rentsch to code it in a manner independent of number
of bits in x.
Sorry for not giving you the credit.

jak <nospam@please.ty> writes:

> jak ha scritto:
>
>> Tim Rentsch ha scritto:
>>
>>> jak <nospam@please.ty> writes:
>>>
>>>> unsigned long h_bit(unsigned long val)
>>>> {
>>>> int i;
>>>> for(i = 0; val > 1; val /= 2, i++);
>>>> return val << i;
>>>> }
>>>
>>> A nice compact solution. I like the way it
>>> naturally deals with the case when val is zero.
>>
>> This is not true because if Val is 0 also the bit shifted to left
>> is, so also its result is 0. This one of the reason why the exit
>> from the loop is greater than 1.
>
> Sorry about the answer. I have translated your comment badly.

No worries. I see how it works, and it's cool.

On Sun, 15 Oct 2023 05:26:44 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:

> On 2023-10-11, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> > E.g. 32 bit code:
> >
> > uint32_t fill_mask_down(uint32_t x)
> > {
> > x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
> > x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
> > x |= x >> 4; // e.g. 11110000... -> 11111111...
> > x |= x >> 8;
> > x |= x >> 16;
> >
> > return x;
> > }
> >
> > Thus:
> >
> > uint32_t isolate_highest_bit(uint32_t x)
> > {
> > uint32_t m = fill_mask_down(x);
> > return m ^ (m >> 1);
> > }
> >
>
> I guess this went over people's heads?
>

Not over my head.
My O(log(N)) variant is inspired by your solution.
It is essentially the same like yours, with only difference that I
tried to meet requirement of Tim Rentsch to code it in a manner
independent of number of bits in x.
Sorry for not giving you the credit.

When coded as below, it become more clear that idea is the same like
yours:

T
highest_bit_set( T u ){
for (int rshift = 1; ((u+1) & u) != 0; rshift += rshift)
u |= (u >> rshift);
return u ^ (u>>1);
}

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-10-11, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>
>> E.g. 32 bit code:
>>
>> uint32_t fill_mask_down(uint32_t x)
>> {
>> x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
>> x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
>> x |= x >> 4; // e.g. 11110000... -> 11111111...
>> x |= x >> 8;
>> x |= x >> 16;
>>
>> return x;
>> }
>>
>> Thus:
>>
>> uint32_t isolate_highest_bit(uint32_t x)
>> {
>> uint32_t m = fill_mask_down(x);
>> return m ^ (m >> 1);
>> }
>
> I guess this went over people's heads?

Not at all. It's a well-known technique. But it doesn't
address the central ask for an approach that works no
matter how wide the value type is.

Turned out that people that read this group through Eternal September
had never seen my answer from ~3 days ago. Right now ES spam filter is
rather unpredictable and appear to suffer both from insufficient
strictness and from false positives. i2pm2 spam filter is considerably
better
Anyway, I'd post my reply again below.

On Thu, 12 Oct 2023 08:05:40 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
>
> > On Thu, 12 Oct 2023 07:01:47 -0700
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
> >>
> >>> Tim Rentsch:
> >>>
> >>>> But the approach you are using requires knowing the size
> >>>> of the type involved. The challenge is to write code that
> >>>> works without having to know the size in advance.
> >>>
> >>> Well, I could use macros, or the largest integer type, or:
> >>
> >> Neither necessary nor sufficient. The code should work for
> >> the type T being __uint128_t, which is larger than uintmax_t.
> >>
> >>> #include <stddef.h>
> >>> #include <limits.h>
> >>>
> >>> [..examine value character-by-character, including
> >>> determining if little-endian encoding is used..]
> >>
> >> You're making things more complicated than they need to be.
> >> Looking at character values rather than just values of the type
> >> involved is almost guaranteed to have potential representation
> >> issues. For example, little endian and big endian are not the
> >> only choices possible for endianness.
> >>
> >> Below is a proposed solution that mostly works. What problems
> >> does it have, and how can they be fixed? And can we find
> >> something better?
> >>
> >> /* The type T has been supplied somewhere upstream. It */
> >> /* is an unsigned type, and possibly outside the realm */
> >> /* of 'integer types' as defined by the C standard, as */
> >> /* for example __uint128_t. */
> >>
> >> T
> >> highest_bit_set( T u ){
> >> T r = 1;
> >> while( u>>1 > r ) r <<= 1;
> >> return r;
> >> }
> >
> > That code does not look like working.
>
> Yes, deliberately so. I didn't want to give working
> code yet, so other people could work on the problem.
>
> > That is:
> >
> > T
> > highest_bit_set1( T u ){
> > T r = 0;
> > while (u > r) r = r*2+1;
> > return r ^ (r>>1);
> > }
>
> As expected, this works. I like the way it naturally
> accommodates a zero input.
>
> Can you find a different solution that works in
> logarithmic time rather than linear time?

Naturally, I can. But the code is not as easy to comprehend as I would
like. And I am not sure that for typical distributions with prevalence
of small numbers it is faster than above variant.

T
highest_bit_set2( T u ){
T v;
for (int rshift = 0; (v = (u >> rshift) >> 1) != 0;
rshift = rshift*2+1)
u |= v;
return u ^ (u>>1);
}

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 15 Oct 2023 05:26:44 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>
>> On 2023-10-11, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>
>>> E.g. 32 bit code:
>>>
>>> uint32_t fill_mask_down(uint32_t x)
>>> {
>>> x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
>>> x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
>>> x |= x >> 4; // e.g. 11110000... -> 11111111...
>>> x |= x >> 8;
>>> x |= x >> 16;
>>>
>>> return x;
>>> }
>>>
>>> Thus:
>>>
>>> uint32_t isolate_highest_bit(uint32_t x)
>>> {
>>> uint32_t m = fill_mask_down(x);
>>> return m ^ (m >> 1);
>>> }
>>
>> I guess this went over people's heads?
>
> Not over my head.
> My O(log(N)) variant is inspired by your solution.
> It is essentially the same like yours, with only difference that I
> tried to meet requirement of Tim Rentsch to code it in a manner
> independent of number of bits in x.
> Sorry for not giving you the credit.

Two short comments on the above. One, the requirement to make
the algorithm size independent came from the OP, not me; I just
expressed that in a way that is apparent in the C code. Two, I
had assumed that most people would already be familiar with the
expanding-shift-and-oring technique; it was one of several I
had already coded before the humorous post with my "favorite"
version.

> When coded as below, it become more clear that idea is the same
> like yours:
>
> T
> highest_bit_set( T u ){
> for (int rshift = 1; ((u+1) & u) != 0; rshift += rshift)
> u |= (u >> rshift);
> return u ^ (u>>1);
> }

I expect to have comments on this and your earlier posted
version soon.

On Sun, 15 Oct 2023 12:46:03 +0300
Michael S <already5chosen@yahoo.com> wrote:

> Turned out that people that read this group through Eternal September
> had never seen my answer from ~3 days ago. Right now ES spam filter is
> rather unpredictable and appear to suffer both from insufficient
> strictness and from false positives. i2pm2 spam filter is considerably
> better

[O.T.]
As suggested in other thread here, ES users that either can not or do
not want to access comp.lang.c via news.i2pn2.org have an option to see
read-only variant of i2pn2-filtered group at
https://www.novabbs.com/devel/thread.php?group=comp.lang.c

* Michael S wrote:
> Turned out that people that read this group through Eternal September
> had never seen my answer from ~3 days ago. Right now ES spam filter is
> rather unpredictable and appear to suffer both from insufficient
> strictness and from false positives. i2pm2 spam filter is considerably
> better
> Anyway, I'd post my reply again below.

PMFJI, just a remark regarding the above comment:

I assume you are referring to the article with Message ID

<20231012191641.00007493@yahoo.com>

This article is actually available on E-S. Since you
posted it via E-S, it wouldn't have been scanned by
the spam filter, anyway, as this filter only scans
articles originating from GG and some Highwinds Media
resellers based on the Injection-Info: header.

If you would like to follow up on this issue,
please reply either on eternal-september.support or
to my email address.

--
Пу́тін — хуйло́
http://www.eternal-september.org

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> I guess this went over people's heads?

Nope.
I've used that before, just not in C yet.

--
Fake signature.

Tim Rentsch ha scritto:
> jak <nospam@please.ty> writes:
>
>> jak ha scritto:
>>
>>> Tim Rentsch ha scritto:
>>>
>>>> jak <nospam@please.ty> writes:
>>>>
>>>>> unsigned long h_bit(unsigned long val)
>>>>> {
>>>>> int i;
>>>>> for(i = 0; val > 1; val /= 2, i++);
>>>>> return val << i;
>>>>> }
>>>>
>>>> A nice compact solution. I like the way it
>>>> naturally deals with the case when val is zero.
>>>
>>> This is not true because if Val is 0 also the bit shifted to left
>>> is, so also its result is 0. This one of the reason why the exit
>>> from the loop is greater than 1.
>>
>> Sorry about the answer. I have translated your comment badly.
>
> No worries. I see how it works, and it's cool.
>

In addition, GCC translates this code into a really simple way:

h_bit:
mov rax, rcx
cmp rcx, 1
jbe .L1
xor ecx, ecx
..L3:
shr rax
add ecx, 1
cmp rax, 1
jne .L3
sal rax, cl
..L1:
ret

James Kuyper wrote:

> If the users of those toolchains aren't interested in using newer
> versions, how is that a problem?

They are intentionally choosing to use obsolete versions.

--

On 2023-10-15, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-10-11, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>
>>> E.g. 32 bit code:
>>>
>>> uint32_t fill_mask_down(uint32_t x)
>>> {
>>> x |= x >> 1; // e.g. 1000...0000 -> 1100...0000
>>> x |= x >> 2; // e.g. 1100...0000 -> 1111...0000
>>> x |= x >> 4; // e.g. 11110000... -> 11111111...
>>> x |= x >> 8;
>>> x |= x >> 16;
>>>
>>> return x;
>>> }
>>>
>>> Thus:
>>>
>>> uint32_t isolate_highest_bit(uint32_t x)
>>> {
>>> uint32_t m = fill_mask_down(x);
>>> return m ^ (m >> 1);
>>> }
>>
>> I guess this went over people's heads?
>
> Not at all. It's a well-known technique. But it doesn't
> address the central ask for an approach that works no
> matter how wide the value type is.

Oh, if I had to make it work with the unsigned long type, like the other
solutions, I'd probably just do this:

unsigned long fill_mask_down(unsigned long x)
{
x |= x >> 1;
x |= x >> 2;
x |= x >> 4;
x |= x >> 8;

#if UINT_MAX == UINT32_MAX
x |= x >> 16;
#elif UINT_MAX == UINT64_MAX
x |= x >> 16;
x |= x >> 32;
#elif UINT_MAX != UINT16_MAX
#error port me!
#endif

return x;
}

unsigned long isolate_highest_bit(unsigned long x)
{
unsigned long m = fill_mask_down(x);
return m ^ (m >> 1);
}

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Tim Rentsch wrote:

> The word obsolete means no longer used or no longer useful. If someone
> is still using it then by definition it is not obsolete.

That is not my definition. I consider something obsolete when it has been
replaced.

--

Michael S:

> Turned out that people that read this group through
> Eternal September had never seen my answer from ~3 days
> ago. Right now ES spam filter is rather unpredictable and
> appear to suffer both from insufficient strictness and
> from false positives. i2pm2 spam filter is considerably
> better Anyway, I'd post my reply again below.

I had read it vie E.-S. the first time around, which was
several days ago.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> Tim Rentsch wrote:
>
>> The word obsolete means no longer used or no longer useful. If someone
>> is still using it then by definition it is not obsolete.
>
> That is not my definition. [...]

You are free of course to use any definition you want. If however you
want to be understood then I generally recommend using a dictionary
definition, which is what the one I gave is.

Michael S <already5chosen@yahoo.com> writes:

> Turned out that people that read this group through Eternal September
> had never seen my answer from ~3 days ago.

I read from ES and I saw it.

> Right now ES spam filter is
> rather unpredictable and appear to suffer both from insufficient
> strictness and from false positives.

I don't think the filter would have touched it.

--
Ben.

Tim Rentsch wrote:

> You are free of course to use any definition you want. If however you
> want to be understood then I generally recommend using a dictionary
> definition, which is what the one I gave is.

The dictionary is not an arbiter of truth.

--

Blue-Maned_Hawk:

> The dictionary is not an arbiter of truth.

Man, it is the arbiter of word meanings, necessary for us to
understand each other. If for some reason you need to use a
common word with your personal definition, give that definition
up front, lest there be a disagreeent of terms.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Tim Rentsch wrote:
>
>> You are free of course to use any definition you want. If however you
>> want to be understood then I generally recommend using a dictionary
>> definition, which is what the one I gave is.
>
> The dictionary is not an arbiter of truth.

Nor are you.

The truth is, many people have perfectly valid reasons *not* to
upgrade immediately to the latest version of the standard (or of
anything else).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> Tim Rentsch wrote:
>
>> You are free of course to use any definition you want. If however you
>> want to be understood then I generally recommend using a dictionary
>> definition, which is what the one I gave is.
>
> The dictionary is not an arbiter of truth.

I didn't say it is. It's just a better choice in most cases
if you want other people to understand you. If you don't
care about that, by all means keep doing what you have been
doing.

On 10/15/23 12:57, Blue-Maned_Hawk wrote:
> James Kuyper wrote:
>
>> If the users of those toolchains aren't interested in using newer
>> versions, how is that a problem?
>
> They are intentionally choosing to use obsolete versions.

I repeat - how is that a problem? That's their choice. What version of
any program to use is for each user to decide for themselves - it's
often better to use an older version that you're more familiar than to
always rush ahead to adopt the latest version. What business is it of
yours to decide that they are wrong?
However, whether or not that's a good decision is irrelevant. The fact
that it's a common and popular decision is relevant. Because it has
historically been commonplace for it to take many years for a new
version of C to be adopted, we can reasonably assume that that will
continue to be the case. As a result, code which depends upon features
introduced in the latest version of C will always remain less portable
than code which does, for many years after that version gets approved.

I say this as a early adopter - I started writing C90 code as soon as I
got access to a compiler which supported it (which was many years after
it was approved), and was rather annoyed that it took so long. I would
have done the same with C99, but I was working for a company whose
contract with our client mandated use of C90 (or versions of COBOL or
FORTRAN of comparable vintage - I no longer remember which versions they
were). For code I wrote at home for personal use, I started using C99 as
soon as, and to the extant that, gcc supported it.

On 10/15/23 13:18, Blue-Maned_Hawk wrote:
> Tim Rentsch wrote:
>
>> The word obsolete means no longer used or no longer useful. If someone
>> is still using it then by definition it is not obsolete.
>
> That is not my definition. I consider something obsolete when it has been
> replaced.

That's still not the case. C90 has not yet been fully replaced, not even
by C99, much less by later versions - there's still people out there
demanding implementations to support that version of the standard, and
most do. C90 hasn't been the official C version as far as ISO is
concerned for 24 years now, but as far as actual use of the language is
concerned, C90 continues to be used in parallel with all of the other
later versions.

On 16/10/2023 05:52, James Kuyper wrote:
> On 10/15/23 13:18, Blue-Maned_Hawk wrote:
>> Tim Rentsch wrote:
>>
>>> The word obsolete means no longer used or no longer useful. If someone
>>> is still using it then by definition it is not obsolete.
>>
>> That is not my definition. I consider something obsolete when it has been
>> replaced.
>
> That's still not the case. C90 has not yet been fully replaced, not even
> by C99, much less by later versions - there's still people out there
> demanding implementations to support that version of the standard, and
> most do. C90 hasn't been the official C version as far as ISO is
> concerned for 24 years now, but as far as actual use of the language is
> concerned, C90 continues to be used in parallel with all of the other
> later versions.
>

Agreed.

There is also, for each version of the C standards, code whose meaning
changes when viewed by newer standards. While the C committee take
great pains to minimise incompatibilities, some still exist. So if you
have code that is perfectly good C90 code, but either different syntax
or semantics in C99 (perhaps you use "restrict" as a variable name),
then C90 is not "obsolete" for that code by any useful definition of the
word.