extracting front bits from an unsigned long long?

[Digital Puer]

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

[pete]

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

int three_bits = long_long_value & 7;

--
pete

[slebetman]

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

I'm guessing long long is 64 bits? Regardless, the following should
work:

frontbits = (original_value >> (sizeof(long long) - 3)) & 0x03;

The masking at the end is to zero out the msb of the result since on
some systems it doesn't get zeroed.

If number of bits is not fixed, then it would look something like the
following:

frontbits = original_value >> (sizeof(long long) - num_bits);

but the masking will get complicated.

[pete]

sl*******@yahoo.com wrote:

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits,
I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I'm guessing long long is 64 bits? Regardless, the following should
work: frontbits = (original_value >> (sizeof(long long) - 3)) & 0x03;

You're getting 2 bits from the middle of the value.
Anything & 3, ain't going to get you more than 2 bits.
You shift the original value to the right
and the low order bits disappear.

--
pete

[Barry Schwarz]

On 10 Nov 2005 16:59:21 -0800, "Digital Puer"
<di**********@hotmail.com> wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

Shift the value in the variable to the right
(sizeof(unsigned long long)*CHAR_BIT - n)
bits. The result is the integer you requested.
<<Remove the del for email>>

[pete]

pete wrote:

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits,
I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

int three_bits = long_long_value & 7;

n bits, ... hmm ...

long_long_value & ((1ULL << n) - 1)

--
pete

[Keith Thompson]

"Digital Puer" <di**********@hotmail.com> writes:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

What do you mean by "front" bits?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[slebetman]

pete wrote:

sl*******@yahoo.com wrote:

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits,
I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I'm guessing long long is 64 bits? Regardless, the following should
work:

frontbits = (original_value >> (sizeof(long long) - 3)) & 0x03;

You're getting 2 bits from the middle of the value.
Anything & 3, ain't going to get you more than 2 bits.
You shift the original value to the right
and the low order bits disappear.

--
pete

Ah, sorry, it should be:

frontbits = (original_value >> (sizeof(long long) - 3)) & 0x07;

[pete]

sl*******@yahoo.com wrote:

pete wrote:

sl*******@yahoo.com wrote:

Digital Puer wrote:
> Hi, suppose I have an unsigned long long.
> I would like to extract
> the front 'n' bits of this value and convert them
> into an integer.
> For example, if I extract the first 3 bits,
> I would get an int between
> 0 and 7 (=2^3-1). Could someone please help out?

I'm guessing long long is 64 bits?
Regardless, the following should
work:

frontbits =
(original_value >> (sizeof(long long) - 3)) & 0x03;

You're getting 2 bits from the middle of the value.
Anything & 3, ain't going to get you more than 2 bits.
You shift the original value to the right
and the low order bits disappear.

Ah, sorry, it should be:

frontbits = (original_value >> (sizeof(long long) - 3)) & 0x07;

Barry Schwarz also seems to think that shifting the original
value to the right, is the right thing to do.
I don't get it.

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, so you shift your unsigned long long
two bits to the right, which is equivalent to dividing by 4,
and then you take the 3 lower order bits.
What is that?

--
pete

[pete]

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value & ((1ULL << num_bits) - 1))
}

--
pete

[slebetman]

pete wrote:

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, so you shift your unsigned long long
two bits to the right, which is equivalent to dividing by 4,
and then you take the 3 lower order bits.
What is that?

Sorry again, Barry got it right, multiply with CHAR_BIT. I forgot that
part.

Barry Schwarz also seems to think that shifting the original
value to the right, is the right thing to do.
I don't get it.

I think he's also a hardware guy, the first few bits to us are the msb.
We feel last (as in last few bits) and least (as in lsb) are
equivalent. So it follows that first and most are equivalent.

BTW, does C make any guarantees that the code works both endianness? I
have worked with compilers where shifting didn't do what I expected
because the machine was little endian. The OP would not have this
problem since he's running AIX on what I assume is either Power or
PowerPC.

Hardware guys tend to think in big-endian while software guys tend to
be little-endian. We like things big :-)

[Suman]

pete wrote:

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, ...
[ ...]
What is that?

Exactly! Beats me.

[Peter Nilsson]

Barry Schwarz wrote:

"Digital Puer" <di**********@hotmail.com> wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);
Shift the value in the variable to the right

The OP hasn't said what 'front' bits are, but...
(sizeof(unsigned long long)*CHAR_BIT - n)
bits. The result is the integer you requested.

That assumes that unsigned long long isn't padded. The following
doesn't...

value / ((-1ull >> num_bits) + 1)

....although it does assume that num_bits is non-zero and less than the
width of unsigned
long long.

--
Peter

[Jack Klein]

On 10 Nov 2005 20:38:54 -0800, "sl*******@yahoo.com"
<sl*******@gmail.com> wrote in comp.lang.c:

pete wrote:

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, so you shift your unsigned long long
two bits to the right, which is equivalent to dividing by 4,
and then you take the 3 lower order bits.
What is that?

Sorry again, Barry got it right, multiply with CHAR_BIT. I forgot that
part.

Barry Schwarz also seems to think that shifting the original
value to the right, is the right thing to do.
I don't get it.

I think he's also a hardware guy, the first few bits to us are the msb.
We feel last (as in last few bits) and least (as in lsb) are
equivalent. So it follows that first and most are equivalent.

BTW, does C make any guarantees that the code works both endianness? I
have worked with compilers where shifting didn't do what I expected
because the machine was little endian. The OP would not have this
problem since he's running AIX on what I assume is either Power or
PowerPC.

I don't know what you expected, or what you did, but shifts of
unsigned types in C are defined by value, and are completely
independent of endianness. This assumes the shift amount is not less
than 0 and is less than the width of the unsigned type in bits.

Given unsigned long l = 0x12345678, then:

l & 0xff is 0x78
(l >> 8) & 0xff is 0x56
(l >> 16) & 0xff is 0x34
(l >> 24) & 0xff is 0x12

Shifting unsigned types in C is always exactly defined, and has
nothing at all to do with endianness. Your problem was caused by
something else.
Hardware guys tend to think in big-endian while software guys tend to
be little-endian. We like things big :-)

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[slebetman]

Jack Klein wrote:

I don't know what you expected, or what you did, but shifts of
unsigned types in C are defined by value, and are completely
independent of endianness. This assumes the shift amount is not less
than 0 and is less than the width of the unsigned type in bits.

Given unsigned long l = 0x12345678, then:

l & 0xff is 0x78
(l >> 8) & 0xff is 0x56
(l >> 16) & 0xff is 0x34
(l >> 24) & 0xff is 0x12

Shifting unsigned types in C is always exactly defined, and has
nothing at all to do with endianness. Your problem was caused by
something else.

OK, that's what I'd expect. But, does

0x12345678 == 305419896

or

0x12345678 == 2018915346

If the number is in hex and output in hex then of course it always
works. But I was expecting something like:

(305419896 >> 16) & 0xff == 52
Maybe its just the compiler I was using since it works fine in gcc. I
expect fully conforming compilers treats hex numbers as real
"big-endian" representation of a number.

[Michael Mair]

sl*******@yahoo.com wrote:

Jack Klein wrote:

I don't know what you expected, or what you did, but shifts of
unsigned types in C are defined by value, and are completely
independent of endianness. This assumes the shift amount is not less
than 0 and is less than the width of the unsigned type in bits.

Given unsigned long l = 0x12345678, then:

l & 0xff is 0x78
(l >> 8) & 0xff is 0x56
(l >> 16) & 0xff is 0x34
(l >> 24) & 0xff is 0x12

Shifting unsigned types in C is always exactly defined, and has
nothing at all to do with endianness. Your problem was caused by
something else.
OK, that's what I'd expect. But, does

0x12345678 == 305419896

or

0x12345678 == 2018915346

If the number is in hex and output in hex then of course it always
works.

No! It _always_ works.
In base B, the number represented by the digits
n_k n_{k-1} ... n_0
always means n_0 * B^0 + n_1 * B^1 + ... + n_k * B^k,
so 0x12345678 clearly is 8 + 7*16 + ... = 305419896
As 0x... means unsigned, we have a guarantee how the internal
representation will look, i.e. the above _always_ works
But I was expecting something like:

(305419896 >> 16) & 0xff == 52
So what? 0x34 == 52U
Maybe its just the compiler I was using since it works fine in gcc. I
expect fully conforming compilers treats hex numbers as real
"big-endian" representation of a number.

Whatever this is supposed to mean for machines with CHAR_BIT == 18
and hexadecimal numbers.

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[CoL]

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

Try this I think this solves your problem.

unsigned long int original_value=0xffffffff; //could be what ever
int frontbits=0;
int n=3; //suppose we want to extract front 3 bits
frontbits = (original_value >> (sizeof(long int )*8 - n)) & -1;

This works fine on all machines(e.g intel series, sparc, powerpc) which
use 2's complement represent negative numbers.

Regards,
Apoorv

[slebetman]

Michael Mair wrote:

No! It _always_ works.

If the compiler follows C standards. As I said before, I HAVE used a
compiler where this is not the case. But that is outside the scope of
c.l.c of course.

But I was expecting something like:

(305419896 >> 16) & 0xff == 52

So what? 0x34 == 52U

Yes. That's what I expected. What's with your "so what" ?

[pete]

sl*******@yahoo.com wrote:

pete wrote:

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, so you shift your unsigned long long
two bits to the right, which is equivalent to dividing by 4,
and then you take the 3 lower order bits.
What is that?

Sorry again, Barry got it right, multiply with CHAR_BIT. I forgot that
part.

Barry Schwarz also seems to think that shifting the original
value to the right, is the right thing to do.
I don't get it.

I think he's also a hardware guy,
the first few bits to us are the msb.
We feel last (as in last few bits) and least (as in lsb) are
equivalent. So it follows that first and most are equivalent.

If Value is the identifier of an object
declared as usigned long long and you wanted to see if
Value was odd, it would be (Unsigned_Value & 1).
Where bits and bytes of the object are stored
has got nothing to do with it.

--
pete

[pete]

Suman wrote:

pete wrote:

I'll assume you think that CHAR_BIT is 8.
That makes your 64 bit bit long long, 8 bytes in size.
8 - 3 is two, ...

[ ...]

What is that?

Exactly! Beats me.

I should have used a calculator.

--
pete

[pete]

sl*******@yahoo.com wrote:

BTW, does C make any guarantees that the code works both endianness? I
have worked with compilers where shifting didn't do what I expected
because the machine was little endian.

If you have a two byte int and you shift it to the right,
the low order bit of the high order byte goes into the low order byte.
That happens regardless of which byte is high order.
That's what's supposed to happen.
The byte with the higher address isn't inherently
high order or low order, as far as C is concerned.

You can write portable code to
print the values of all the bytes in an int object,
from lowest to highest address and/or from highest to lowest.
This code will use the address of the int object.

You can write portable C code to print the values
of all of the bytes of an int value which have value bits,
in order from least significant to most significant
or the other way around.
This code will not use the address of the object
and will be able to operate on constant expressions.

--
pete

[Michael Mair]

sl*******@yahoo.com wrote:

Michael Mair wrote:

No! It _always_ works.

If the compiler follows C standards. As I said before, I HAVE used a
compiler where this is not the case. But that is outside the scope of
c.l.c of course.

Definitely.

But I was expecting something like:

(305419896 >> 16) & 0xff == 52

So what? 0x34 == 52U

Yes. That's what I expected. What's with your "so what" ?

You used "But"; this seems to raise a contradictory point. From
the context
,----
| If the number is in hex and output in hex then of course it always
| works. But I was expecting something like:
|
| (305419896 >> 16) & 0xff == 52
`----
I can only infer that the expected result does in your opinion
not match the "always work"ing one in hex.
"So what" documented the fact that I do not see this contradiction.

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Digital Puer]

pete wrote:

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits, I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value & ((1ULL << num_bits) - 1))
}

This doesn't seem to work right. I'm getting the following output:

print binary of 7387272179287021119:
01100110 10000100 11011100 11101000 01011001 10000111 01010110
00111111
extractFrontBits (for 3 bits) returned 7

The 3 most signficant bits of that number are 011, which should be 3.

Here is how I called it:

main()
{
unsigned long long test = 7387272179287021119ULL;
print_binary_ull(test);
int value = extractFrontBits(test, 3);
printf("extractFrontBits (for 3 bits) returned %d\n", value);
}

void print_binary_ull(unsigned long long value)
{
unsigned long long value2;
int i;
printf("print binary of %llu:\n", value);
for (i = 63; i >= 0; i--)
{
value2 = value & ((unsigned long long)1 << i);
printf("%d", value2 ? 1 : 0);
if (i == 32) printf(" ");
else if ((i %8) == 0) printf(" ");
}
printf("\n");
}

[pete]

Digital Puer wrote:

pete wrote:

Digital Puer wrote:

Hi, suppose I have an unsigned long long. I would like to extract
the front 'n' bits of this value and convert them into an integer.
For example, if I extract the first 3 bits,
I would get an int between
0 and 7 (=2^3-1). Could someone please help out?

I can assume the largest returned value fits in an int. Also,
I'm on a big-endian PPC (AIX), in case that matters.

Ideally, I'd like to implement a prototype like:
int extractFrontBits(unsigned long long value, int num_bits);

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value & ((1ULL << num_bits) - 1))
}

This doesn't seem to work right. I'm getting the following output:

print binary of 7387272179287021119:
01100110 10000100 11011100 11101000 01011001 10000111 01010110
00111111
extractFrontBits (for 3 bits) returned 7

The 3 most signficant bits of that number are 011, which should be 3.

Oh, you want the Most significant bits! (Good call, Keith Thompson!)

The just do what everybody else has been saying,
shift your value to right
by the difference between
the number of bits in the type, and n.

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.
There might also be problems if the result of the shift
excedes INT_MAX.

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

int extractFrontBits(unsigned long long value, int num_bits)
{
return (int)(value >> (CHAR_BIT * sizeof value - n));
}

void print_binary_ull(unsigned long long value);

int main(void)

{
unsigned long long test = 7387272179287021119ULL;
print_binary_ull(test);
int value = extractFrontBits(test, 3);
printf("extractFrontBits (for 3 bits) returned %d\n", value);

return 0;

}

void print_binary_ull(unsigned long long value)
{
unsigned long long value2;
int i;
printf("print binary of %llu:\n", value);
for (i = 63; i >= 0; i--)
{
value2 = value & ((unsigned long long)1 << i);
printf("%d", value2 ? 1 : 0);
if (i == 32) printf(" ");
else if ((i %8) == 0) printf(" ");
}
printf("\n");
}

--
pete

[Digital Puer]

pete wrote:

Oh, you want the Most significant bits! (Good call, Keith Thompson!)

Great! thank you very much, pete and everyone else!

Just for my edification, how else would one interpret "front bits"?
I'm assuming you're talking about the byte order in memory
(endianness), right? I just thought it would be pretty clear that
the "front bits" of a number would be the most signficant bits.
E.g. the front digit of 543 is 5.

[Keith Thompson]

"Digital Puer" <di**********@hotmail.com> writes:

pete wrote:

Oh, you want the Most significant bits! (Good call, Keith Thompson!)

Great! thank you very much, pete and everyone else!

Just for my edification, how else would one interpret "front bits"?
I'm assuming you're talking about the byte order in memory
(endianness), right? I just thought it would be pretty clear that
the "front bits" of a number would be the most signficant bits.
E.g. the front digit of 543 is 5.

I thought it most likely meant the most significant bits, but I
wouldn't use the term "front" in the first place.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Netocrat]

On Fri, 11 Nov 2005 19:51:31 +0000, pete wrote:
[...]

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.

Peter Nilson provided equally simple code that did care and was portable.
Why ignore it?

--
http://members.dodo.com.au/~netocrat

[pete]

Netocrat wrote:

On Fri, 11 Nov 2005 19:51:31 +0000, pete wrote:
[...]

Padding bits can screw this up,
but I've never actually seen a padding bit,
so if you don't care, I don't care.

Peter Nilson provided equally
simple code that did care and was portable.
Why ignore it?

I didn't understand the problem at the time that he posted it.

--
pete

[Mark McIntyre]

On 11 Nov 2005 12:08:47 -0800, in comp.lang.c , "Digital Puer"
<di**********@hotmail.com> wrote:

Just for my edification, how else would one interpret "front bits"?
I wouldn't - it doesn't mean anything to me. Arrays of bits don't have
backs, fronts or sides...
E.g. the front digit of 543 is 5.

First perhaps. Leftmost perhaps. Front no.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[slebetman]

Mark McIntyre wrote:

On 11 Nov 2005 12:08:47 -0800, in comp.lang.c , "Digital Puer"
<di**********@hotmail.com> wrote:

Just for my edification, how else would one interpret "front bits"?

I wouldn't - it doesn't mean anything to me. Arrays of bits don't have
backs, fronts or sides...

E.g. the front digit of 543 is 5.

First perhaps. Leftmost perhaps. Front no.

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

[Richard Tobin]

In article <11**********************@g14g2000cwa.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

They are often synonyms in English. In particular, when objects are
moving along a path, the front one will be the first one. But when
(as is the case here) the idea is of looking at a static sequence of
objects, the situation is less clear. "3" is the first digit of 315
when you read or write it, but if you imagine the sequence itself
pointing in left-to-right order (i.e. English reading order) then you
would call "5" the front digit.

In such circumstances it is better to be explicit and say "leftmost",
or if you don't even want to commit to a particular writing direction,
"most significant".

-- Richard

[Mark McIntyre]

On 12 Nov 2005 14:41:20 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Haven't had much experience with non-native english speakers have you?
No, I only worked for a French bank for 10 years. Plus let me tell
you, working in London is like working in the tower of babel..
In a lot of eastern languages front and first are synonyms.

So what?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[pete]

sl*******@yahoo.com wrote:

Mark McIntyre wrote:

On 11 Nov 2005 12:08:47 -0800, in comp.lang.c , "Digital Puer"
<di**********@hotmail.com> wrote:

Just for my edification,
how else would one interpret "front bits"?
I wouldn't
I didn't.
- it doesn't mean anything to me.
Me neither.
Arrays of bits don't have backs, fronts or sides...

E.g. the front digit of 543 is 5.

First perhaps. Leftmost perhaps. Front no.

I would call that, the most significant digit.
Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

It seemed to me, that given a choice between bit0 and bit1,
that bit0, the low order bit, would be the first one.

But I often have trouble understanding plain English,
and yes, it is my only language.

I like to code but I don't enjoy extracting specifications.
I really would have to be paid, in order to do that.

When somebody posts a question and I don't understand it right,
then I answer it wrong.

When somebody posts a question and I do understand it right,
then my chances are better.

--
pete

[Flash Gordon]

sl*******@yahoo.com wrote:

Mark McIntyre wrote:

On 11 Nov 2005 12:08:47 -0800, in comp.lang.c , "Digital Puer"
<di**********@hotmail.com> wrote:

Just for my edification, how else would one interpret "front bits"?

I wouldn't - it doesn't mean anything to me. Arrays of bits don't have
backs, fronts or sides...

E.g. the front digit of 543 is 5.

First perhaps. Leftmost perhaps. Front no.

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

That's as maybe, but this is not one of those eastern languages.

I would not use front or first. I would possibly use left, but generally
highest or most significant.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[slebetman]

Mark McIntyre wrote:

On 12 Nov 2005 14:41:20 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

In a lot of eastern languages front and first are synonyms.

So what?

So, to a lot of people like me, who often 'think' in our native
language and then translate into english we often say front instead of
first. In Malay for instance, first relates to chronological sequence
and front relates to spatial sequence. A sequence of bits in a register
or in memory is spatial. I'm not saying you're wrong. As in english it
IS better to use 'first'. Actually it is better to use 'most
significant'. My point is simply that not everyone thinks that way.

OK, so there was a misunderstanding. It has been resolved. The OP is
happy. Move along now...

[Dik T. Winter]

In article <dl***********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <11**********************@g14g2000cwa.googlegroups .com>,
sl*******@yahoo.com <sl*******@gmail.com> wrote:

Haven't had much experience with non-native english speakers have you?
In a lot of eastern languages front and first are synonyms.

.... In such circumstances it is better to be explicit and say "leftmost",
or if you don't even want to commit to a particular writing direction,
"most significant".

And both do not really convey the meaning of the OP. Which was (as I
understand it now) the sequence of 'k' bits starting at the first 1 bit
in the binary representation of the number. Or (in other terms) the
first 'k' bits if leading 0's are ignored.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Mark McIntyre]

On 12 Nov 2005 16:41:19 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

Mark McIntyre wrote:

On 12 Nov 2005 14:41:20 -0800, in comp.lang.c , "sl*******@yahoo.com"
<sl*******@gmail.com> wrote:

>In a lot of eastern languages front and first are synonyms.
So what?

So, to a lot of people like me, who often 'think' in our native
language and then translate into english we often say front instead of
first.

If you cast your mind back, you'll recall that the question I was
answering was "how would you interpret front bits". Not unnaturally I
expressed my opinion of how I'd intrepret it, and what I'd call the
leftmost bit of eg 543.

It was NOT "how would you expect someone with limited grasp of English
to translate their own word for 'first' into English". So I didn't
answer this question.

So you see, I consider your comment utterly bloody irrelevant!
OK, so there was a misunderstanding. It has been resolved.

I do hope so
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----