Ben Bacarisse ha scritto:
> jak <nospam@please.ty> writes:
>
>> Ben Bacarisse ha scritto:
>>> jak <nospam@please.ty> writes:
>>>
>>>> candycanearter07 ha scritto:
>>>>> Hi,
>>>>> What is the best/most portable way to get the highest bit set?
>>>>> ie. 011010001
>>>>> to  010000000
>>>>
>>>> Hi,
>>>> I don't think it's the best but the most portable could be the
>>>> mathematical approach:
>>>>
>>>> #include <stdio.h>
>>>> #include <math.h>
>>>>
>>>> int main()
>>>> {
>>>> unsigned long val = 3000, ret;
>>> Test case: val = 0xFFFFFFFFFFFFFFFF
>>
>> This is due to the approximation of the floating point:
>
> I know the reason. I was just pointing out that you need to at least
> test the boundary cases!
>
You were really kind to answer. I was also reading about 'feivatround'
and like you I found the 'short blanket'. I think there are less
complicated and, however, easily portable methods. Such as this:

#include <stdio.h>
#include <math.h>

unsigned long h_bit(unsigned long val)
{ int i;
for(i = -1; val; val /= 2, i++);
return (unsigned long)pow(2., (double)i);
}

int main()
{ unsigned long val = ~0UL, ret;

ret = h_bit(val);
printf("\nv: %lX r: %lX", val, ret);

return 0;
}

Finally, the simplest things seem to be the best.
Thanks again.

Michael S ha scritto:
> On Thu, 12 Oct 2023 13:35:01 +0200
> jak <nospam@please.ty> wrote:
>
>> Ben Bacarisse ha scritto:
>>> jak <nospam@please.ty> writes:
>>>
>>>> Ben Bacarisse ha scritto:
>>>>> jak <nospam@please.ty> writes:
>>>>>
>>>>>> candycanearter07 ha scritto:
>>>>>>> Hi,
>>>>>>> What is the best/most portable way to get the highest bit set?
>>>>>>> ie. 011010001
>>>>>>> to  010000000
>>>>>>
>>>>>> Hi,
>>>>>> I don't think it's the best but the most portable could be the
>>>>>> mathematical approach:
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <math.h>
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> unsigned long val = 3000, ret;
>>>>> Test case: val = 0xFFFFFFFFFFFFFFFF
>>>>
>>>> This is due to the approximation of the floating point:
>>>
>>> I know the reason. I was just pointing out that you need to at
>>> least test the boundary cases!
>>>
>>
>> I am sure you knew and I have verified that the problem persists up to
>> "~0UL - 10000" but I don't find an elegant way, type independent, to
>> work around... just adding an 'if' or a ternary operator.
>
>
> I don't know what do you consider elegant, but that code solves
> problem of rounding:
> int save = fegetround();
> fesetround(FE_TOWARDZERO);
> volatile double dval = val;
> fesetround(save);
> Pay attention that without 'volatile' it is not guaranteed to work which
> I personally consider as a bug in the Standard.
>
> Also frexp()/ldexp() would be a little less slow than yours log()/pow().
> int e;
> frexp(dval, &e);
> ldexp(0.5, e);
> But it still would not work at val=0.
>
> I don't know what do you consider elegant, but that code solves
> problem of rounding:
> int save = fegetround();
> fesetround(FE_TOWARDZERO);
> volatile double dval = val;
> fesetround(save);
> Pay attention that without 'volatile' it is not guaranteed to work which
> I personally consider as a bug in the Standard.
>
> Also frexp()/ldexp() would be a little less slow than yours log()/pow().
> int e;
> frexp(dval, &e);
> ldexp(0.5, e);
> But it still would not work at val=0.
>
> I don't know what do you consider elegant, but that code solves
> problem of rounding:
> int save = fegetround();
> fesetround(FE_TOWARDZERO);
> volatile double dval = val;
> fesetround(save);
> Pay attention that without 'volatile' it is not guaranteed to work which
> I personally consider as a bug in the Standard.
>
> Also frexp()/ldexp() would be a little less slow than yours log()/pow().
> int e;
> frexp(dval, &e);
> ldexp(0.5, e);
> But it still would not work at val=0.
>
>
Oops ... I was wrong branch. I hung the answer to the previous branch.
Excuse me. (jak: Thu, 12 Oct 2023 13:09:14 UTC)

Keith Thompson wrote:

> A solution that depends on a header that's introduced in C23, a standard
> that hasn't been published yet, is hardly portable.

Well, it will be in 2024.

> BTW, here's what your signature looks like in my newsreader (Gnus):
>
> Blue-Maned_HawkÃ\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢
\224\202shortens
> to HawkÃ\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢\224\202/
>
blu.mÃ\203\203\203\203\211\233in.dÃ\203\203\203\203\212Ã\203\203\203\202Ã\203\203\202Ã\203\202Ã\202°ak/
> Ã\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢\224\202he/him/his/
himself/Mr.
> bluemanedhawk.github.io Minor vehicular events!
>
> And in Thunderbird:
>
> Blue-Maned_HawkÃÃÃâshortens to HawkÃÃÃâ/
> blu.mÃin.dÃÃÃÃðak/
> ÃÃÃâhe/him/his/himself/Mr.
> bluemanedhawk.github.io Minor vehicular events!

Blame Pan for corrupting it. That was meant to have its fields separated
by the │ character, including a pronunciation explanation field that has
IPA characters in it.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
In eggshells and mayo!

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;
}

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>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;
> }

Given a reasonable compiler (gcc or clang), I'd use

/**
* Return the 1-relative bit number of the
* highest set bit. If no bits are set,
* return zero.
*/
size_t
highest_bit_set(unsigned long long u)
{ return u ? 64ul - __builtin_clzll(u) : 0ul;
}

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.
That is:

T
highest_bit_set1( T u ){
T r = 0;
while (u > r) r = r*2+1;
return r ^ (r>>1);
}

T
highest_bit_set1( T u ){
T r = 0;
while( u > r) r = r*2+1;
return r ^ (r>>1);
}

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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;
>> }
>
> Given a reasonable compiler (gcc or clang), I'd use
>
> /**
> * Return the 1-relative bit number of the
> * highest set bit. If no bits are set,
> * return zero.
> */
> size_t
> highest_bit_set(unsigned long long u)
> {
> return u ? 64ul - __builtin_clzll(u) : 0ul;
> }

That gives a solution to a different problem.

When you have code that solves the problem being
discussed, I'm interested to see it.

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?

Tim Rentsch:

> The code should work for the type T being __uint128_t,
> which is larger than uintmax_t.

I was in my C89 mode:

#include <stdio.h>
#include <stddef.h>
#include <limits.h>

char is_le()
{ const int v = 1;
const char* p = (unsigned char*)&v;
return *p == 0;
}

unsigned char highest_bit_1( unsigned char byte )
{ int i ;
unsigned char mask = 1 << (CHAR_BIT-1);
for( i = 0; i <= CHAR_BIT; i += 1 )
{ if( byte & mask )
{ break; }
mask >>= 1;
}
return mask;
}

/* sz must be the size of the value /and/ of the buffer: */
void highest_bit_2( void* val, void* buffer, size_t sz )
{ int i,inc;
unsigned char *pval = val;
unsigned char *pbuf = buffer;
unsigned char c ;
char le = is_le();
char set;

if( le )
{ inc = 1; } else
{ inc = -1; pval += sz-1; pbuf += sz-1; }

set = 0;
for( i = 0; i < sz; i += 1 )
{ c = *pval ;
if( !set && c != 0 )
{ *pbuf = highest_bit_1( c );
set = 1;
}
else *pbuf = 0;
pval += inc; pbuf += inc;
}
}

void test( long int val )
{ char buf[sizeof(long int)];

highest_bit_2(&val, &buf, sizeof( long int ));
printf("Value: %9x, High-bit mask: %9x\n", val, *(long unsigned int *)&buf);
}

int main(void)
{ test(0x0); test(0x1); test(0x2); test(0x3); test(0x4); test(0x5);

test((1<<17)-1); test((1<<17)); test((1<<17)+1);
}

....printf("%x"), anybody?

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

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);
}

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> Keith Thompson wrote:
[...]
>> BTW, here's what your signature looks like in my newsreader (Gnus):
>>
>> Blue-Maned_HawkÃ\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢ \224\202shortens
[SNIP]
>
> Blame Pan for corrupting it. That was meant to have its fields separated
> by the │ character, including a pronunciation explanation field that has
> IPA characters in it.

OK, I'll take your word for it that Pan is at fault. But I also blame
you for continuing to use a signature that's corrupted before it leaves
your computer. Consider either changing it or figuring out how to get
Pan to handle it correctly (you can use alt.test to test solutions).

I would have contacted you by email if I could. If you want to discuss
this further, email me. I won't continue this discussion here.

--
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 */

unsigned long h_bit(unsigned long val)
{ int i;
for(i = 0; val > 1; val /= 2, i++);
return val << i;
}

Keith Thompson to Blue-Maned_Hawk:

> OK, I'll take your word for it that Pan is at fault. But
> I also blame you for continuing to use a signature that's
> corrupted before it leaves your computer.

I am with Keith.

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

Tim Rentsch:

> Can you find a different solution that works in
> logarithmic time rather than linear time?

Direct linear search comes to mind. Instead of long long
int below, use the widest integer type that your C
environment supports:

#define LLBM CHAR_BIT * sizeof( long long ) - 1

unsigned long long int
high_bit_mask( unsigned long long n )
{ unsigned long long m = ULLONG_MAX;
int l = 0, r = LLBM+1;
while( 1 )
{ const int ofs = (l + r) / 2;
const unsigned long long mn = n & (m << LLBM - ofs);

if( mn > 0 ) r = ofs;
else if( mn == 0 ) l = ofs + 1;
if( l == r ) break;
}
/* How can I avoid this condition? */
return l == LLBM + 1 ? 0 : 1 << LLBM-l;
}

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

On 10/12/2023 2:50 PM, Anton Shepelev wrote:
> Keith Thompson to Blue-Maned_Hawk:
>
>> OK, I'll take your word for it that Pan is at fault. But
>> I also blame you for continuing to use a signature that's
>> corrupted before it leaves your computer.
>
> I am with Keith.
>

I second that.

On Wed, 11 Oct 2023 14:54:32 +0000, Lew Pitcher wrote:

> On Wed, 11 Oct 2023 01:56:49 -0500, candycanearter07 wrote:
>
>> Hi,
>>
>> What is the best/most portable way to get the highest bit set?
>>
>> ie. 011010001 to 010000000
>
> What have you tried?
>
> I can think of one way, but it may not be the "best" or "most portable"
> way of setting the highest bit of a value, and it /does/ have some
> limitations. Show your work, and I might show mine.

#include <limits.h>
unsigned long long int msb_mask(unsigned long long int valu)
{ unsigned long long int mask;

for (mask = ((ULLONG_MAX) ^ (ULLONG_MAX >> 1));
mask && !(mask&valu);
mask >>= 1) continue;
return mask&valu;
}

--
Lew Pitcher
"In Skills We Trust"

On Thu, 12 Oct 2023 23:35:08 +0000, Lew Pitcher wrote:

> On Wed, 11 Oct 2023 14:54:32 +0000, Lew Pitcher wrote:
>
>> On Wed, 11 Oct 2023 01:56:49 -0500, candycanearter07 wrote:
>>
>>> Hi,
>>>
>>> What is the best/most portable way to get the highest bit set?
>>>
>>> ie. 011010001 to 010000000
>>
>> What have you tried?
>>
>> I can think of one way, but it may not be the "best" or "most portable"
>> way of setting the highest bit of a value, and it /does/ have some
>> limitations. Show your work, and I might show mine.
>
> #include <limits.h>
> unsigned long long int msb_mask(unsigned long long int valu)
> {
> unsigned long long int mask;
>
> for (mask = ((ULLONG_MAX) ^ (ULLONG_MAX >> 1));
> mask && !(mask&valu);
> mask >>= 1) continue;
> return mask&valu;
> }

Well, I'll be go to COBOL. A minor tweak just occurred to me.

unsigned long long int msb_mask(unsigned long long int valu)
{ unsigned long long int mask;

for (mask = ((ULLONG_MAX) ^ (ULLONG_MAX >> 1));
mask && !(mask&valu);
mask >>= 1) continue;
return mask; /* don't need to AND with valu now */
}

--
Lew Pitcher
"In Skills We Trust"

On 10/12/23 09:42, Blue-Maned_Hawk wrote:
> Keith Thompson wrote:
>
>> A solution that depends on a header that's introduced in C23, a standard
>> that hasn't been published yet, is hardly portable.
>
> Well, it will be in 2024.

You expect the new standard to be widely adopted so much quicker than
any previous version? Why?

On Thu, 12 Oct 2023 13:42:03 -0000 (UTC), Blue-Maned_Hawk
<bluemanedhawk@invalid.invalid> wrote in
<pan$325f3$70a576a8$3150c04a$26db7b31@invalid.invalid>:

> Keith Thompson wrote:
>
>> A solution that depends on a header that's introduced in C23, a
>> standard that hasn't been published yet, is hardly portable.
>
> Well, it will be in 2024.
>
>> BTW, here's what your signature looks like in my newsreader (Gnus):
>>
>> Blue-Maned_HawkÃ\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢
> \224\202shortens
>> to HawkÃ\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢\224\202/
>>
>
blu.mÃ\203\203\203\203\211\233in.dÃ\203\203\203\203\212Ã\203\203\203\202Ã\203\203\202Ã\203\202Ã\202°ak/
>> Ã\203\203\203\203Ã\203\203\202Ã\203\202Ã\202¢\224\202he/him/his/
> himself/Mr.
>> bluemanedhawk.github.io Minor vehicular events!
>>
>> And in Thunderbird:
>>
>> Blue-Maned_HawkÃÃÃâshortens to HawkÃÃÃâ/ blu.mÃin.dÃÃÃÃðak/
>> ÃÃÃâhe/him/his/himself/Mr.
>> bluemanedhawk.github.io Minor vehicular events!
>
> Blame Pan for corrupting it. That was meant to have its fields
> separated by the │ character, including a pronunciation explanation
> field that has IPA characters in it.

(followup-to: news.software.readers)

I doubt Pan is to blame, but if it is,
let's get a patch in to the maintainers.

Some folks have offered to help with your sig.
I'm willing to help as time allows, but you have
to be willing to put in the time to stop posting
mojibakes. :/

If you're shy about email, please come
visit news.software.readers, where you
will find the thread "Usenet characters".

The article where I post the relevant
RFC quotes, cites, and maybe a little shade on
non-compliant newsreaders; can be
found in article:

<zDOJM.1001200$TPw2.839294@fx17.iad>

I've set the fu2 in this article
to news.software.readers.

--
-Scott
p.s. I use pan and track their git repo

James Kuyper wrote:

> On 10/12/23 09:42, Blue-Maned_Hawk wrote:
>> Keith Thompson wrote:
>>
>>> A solution that depends on a header that's introduced in C23, a
>>> standard that hasn't been published yet, is hardly portable.
>>
>> Well, it will be in 2024.
>
> You expect the new standard to be widely adopted so much quicker than
> any previous version? Why?

What?

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
bluemanedhawk.github.io
A typical acre of Florida land produces a revenue of three cents per year
in falling cocaine bales.

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Tim Rentsch:
>
>> The code should work for the type T being __uint128_t,
>> which is larger than uintmax_t.
>
> I was in my C89 mode:
>
> #include <stdio.h>
> #include <stddef.h>
> #include <limits.h>
>
> char is_le()
> { const int v = 1;
> const char* p = (unsigned char*)&v;
> return *p == 0;
> }
>
> unsigned char highest_bit_1( unsigned char byte )
> { int i ;
> unsigned char mask = 1 << (CHAR_BIT-1);
> for( i = 0; i <= CHAR_BIT; i += 1 )
> { if( byte & mask )
> { break; }
> mask >>= 1;
> }
> return mask;
> }
>
> /* sz must be the size of the value /and/ of the buffer: */
> void highest_bit_2( void* val, void* buffer, size_t sz )
> { int i,inc;
> unsigned char *pval = val;
> unsigned char *pbuf = buffer;
> unsigned char c ;
> char le = is_le();
> char set;
>
> if( le )
> { inc = 1; } else
> { inc = -1; pval += sz-1; pbuf += sz-1; }
>
> set = 0;
> for( i = 0; i < sz; i += 1 )
> { c = *pval ;
> if( !set && c != 0 )
> { *pbuf = highest_bit_1( c );
> set = 1;
> }
> else *pbuf = 0;
> pval += inc; pbuf += inc;
> }
> }
>
> void test( long int val )
> { char buf[sizeof(long int)];
>
> highest_bit_2(&val, &buf, sizeof( long int ));
> printf("Value: %9x, High-bit mask: %9x\n",
> val, *(long unsigned int *)&buf);
> }
>
>
> int main(void)
> { test(0x0); test(0x1); test(0x2); test(0x3); test(0x4); test(0x5);
>
> test((1<<17)-1); test((1<<17)); test((1<<17)+1);
> }

I'm at a loss for words.

Tim Rentsch about my code:

> I'm at a loss for words.

What, no one did worse?

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

Anton Shepelev <anton.txt@gmail.moc> writes:

> Tim Rentsch:
>
>> Can you find a different solution that works in
>> logarithmic time rather than linear time?
>
> Direct linear search comes to mind. Instead of long long
> int below, use the widest integer type that your C
> environment supports:
>
> #define LLBM CHAR_BIT * sizeof( long long ) - 1
>
> unsigned long long int
> high_bit_mask( unsigned long long n )
> { unsigned long long m = ULLONG_MAX;
> int l = 0, r = LLBM+1;
> while( 1 )
> { const int ofs = (l + r) / 2;
> const unsigned long long mn = n & (m << LLBM - ofs);
>
> if( mn > 0 ) r = ofs;
> else if( mn == 0 ) l = ofs + 1;
> if( l == r ) break;
> }
> /* How can I avoid this condition? */
> return l == LLBM + 1 ? 0 : 1 << LLBM-l;
> }

Before giving any comment on the algorithm, I'd like to ask a
question about layout style. Your code follows the unusual
practice of starting controlled blocks with an open brace at the
start (possibly indented) of a line, and the first code line of
the block on the same line as the open brace. Is this practice
something you started by yourself, or did you see it and adopt
it from somewhere else? What kinds of reasons persuaded you
to follow it?

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
> James Kuyper wrote:
>> On 10/12/23 09:42, Blue-Maned_Hawk wrote:
>>> Keith Thompson wrote:
>>>> A solution that depends on a header that's introduced in C23, a
>>>> standard that hasn't been published yet, is hardly portable.
>>>
>>> Well, it will be in 2024.
>>
>> You expect the new standard to be widely adopted so much quicker than
>> any previous version? Why?
>
> What?

I don't know what was unclear. You seem to expect universal adoption of
the C23 standard by 2024. Given the adoption speed of previous editions
of the C standard, that's completely unrealistic.

--
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 */

Tim Rentsch:

> Before giving any comment on the algorithm, I'd like to
> ask a question about layout style. Your code follows the
> unusual practice of starting controlled blocks with an
> open brace at the start (possibly indented) of a line, and
> the first code line of the block on the same line as the
> open brace. Is this practice something you started by
> yourself, or did you see it and adopt it from somewhere
> else? What kinds of reasons persuaded you to follow it?

I was bothered by the unaligned braces in K&R and by the
too-sparse look of the opening brace on a line of its own.
When a friend of mine was working on a coding style
guide[1], he researched exising indentaion styles and told
me about them, including Horstmann:

<https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style>

whence I took the main idea of placing braces. My has
decided upon a different indetation, but I forget which and
I have not his guide at hand, but his Pascal indentation can
be seen in his showcase of programming fonts:

<http://inversed.ru/Articles/Fonts_Comparison.png>

____________________
1. of which lack of bias and prejudice is an imoprtant
advantage, because before that my friend use no style
all, that is writing everything flat!

P.S.: reflecting on my solution later I decided that a
direct comparison of the analysed value with a power
of two might be better, especially because it is
already in the form required for the return value.

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