THE GAME :
Write a C function to swap the bits of a char so
that its bits would become the mirror image of the
char.MSBs become its LSBs etc. E.g. 11001100
binary would become 00110011 binary.
---------------------------------------
Sep 4 '06
77  3180 
Ben Pfaff wrote:
You could use a 16- or 8-byte table too. Code below not tested:
uint8_t
reverse_uint8 (uint8_t x)
{
static const uint8_t reverse_uint4[16]
= {0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15};
return reverse_uint4[x >4] | (reverse_uint4[x & 15] << 4);
}
It might still be faster than an approach without a table, and
certainly wouldn't be much bigger, if at all.
Yes. And you could write like this, too :
unsigned char reverse5b( unsigned char c)
{
static unsigned char table1[16] =
{
0x00,0x08,0x04,0x0C,0x02,0x0A,0x06,0x0E,0x01,0x09, 0x05,0x0D,0x03,0x0B,0x07,0x0F,
};
static unsigned char table2[16] =
{
0x00,0x80,0x40,0xC0,0x20,0xA0,0x60,0xE0,0x10,0x90, 0x50,0xD0,0x30,0xB0,0x70,0xF0
};
return table2[c&0xF] | table1[c>>4];
}
This is faster :)
Aman JIANG wrote:
William Hughes wrote:
>Maybe, maybe not. The table is only 256 or so bytes. The table look
up
algorithm is very simple, the code for a more complicated algorithm
will
be longer (256 bytes longer? who knows). As well the longer
code may use code cache rather than data cache and code cache is
typically smaller. (Note, as pointed out elsethread, timing a lookup
table
in a tight loop may give misleading results).
Since any algorithm will need some "data" (e.g. the constants
indicating
bit positions) why not let the "data" be considered part of the
algorithm
and asign a limit to the total algorithm size? Except of course this
is completely non-portable. So what you could do is
put a limit on the total number of bytes used to express the
algorithm.
-William Hughes
Yes. If this question is not for the "8-bit byte", it's for 32-bit or
64-bit
unsigned integer, i think that nobody could use a TABLE.
Of course they could still use a table (why must you type "table" in all
caps?). There is nothing that says the table must contain all of the
possible values. You could still use a 256 element table to swap the
bits in a 64-bit integer, there's just a bit more math involved.
--
Clark S. Cox III cl*******@gmail.com
Clark S. Cox III wrote:
Have you profiled that? I suspect that for code that simply reverses the
bits in a byte, there will be no noticeable speed difference.
You still haven't addressed the fact that the assert does not appear to
serve any purpose, and the cast is redundant.
In fact, On my machine(Intel P4), It was faster.
The optimized assembler of release version was more terse.
Richard Tobin wrote:
In article <11**********************@p79g2000cwp.googlegroups .com>,
Aman JIANG <Am*******@gmail.comwrote:
Because, this is a GAME only,
and the rule of this game is "real time".
if you use TABLE, you could gain the TIME, but you lose the SPACE.
Sounds like the TABLE accords with the rule of the GAME, then.
UNALTERED dissemination of this IMPORTANT information is ENCOURAGED.
-- Richard
Thank you.
CBFalconer wrote:
I think most here recognize the language difficulty, and will make
suitable allowances.
Thank you, thank you very much.
Clark S. Cox III wrote:
Aman JIANG wrote:
William Hughes wrote:
Maybe, maybe not. The table is only 256 or so bytes. The table look
up
algorithm is very simple, the code for a more complicated algorithm
will
be longer (256 bytes longer? who knows). As well the longer
code may use code cache rather than data cache and code cache is
typically smaller. (Note, as pointed out elsethread, timing a lookup
table
in a tight loop may give misleading results).
Since any algorithm will need some "data" (e.g. the constants
indicating
bit positions) why not let the "data" be considered part of the
algorithm
and asign a limit to the total algorithm size? Except of course this
is completely non-portable. So what you could do is
put a limit on the total number of bytes used to express the
algorithm.
-William Hughes
Yes. If this question is not for the "8-bit byte", it's for 32-bit or
64-bit
unsigned integer, i think that nobody could use a TABLE.
Of course they could still use a table (why must you type "table" in all
caps?). There is nothing that says the table must contain all of the
possible values. You could still use a 256 element table to swap the
bits in a 64-bit integer, there's just a bit more math involved.
--
Clark S. Cox III
cl*******@gmail.com
hum....understood. thanks.
because, i think if nobody use the table, this game will be more funny.
Aman JIANG wrote:
Clark S. Cox III wrote:
>Have you profiled that? I suspect that for code that simply reverses the
bits in a byte, there will be no noticeable speed difference.
You still haven't addressed the fact that the assert does not appear to
serve any purpose, and the cast is redundant.
In fact, On my machine(Intel P4), It was faster.
The optimized assembler of release version was more terse.
Again, I'd tend call any compiler that produces terser code with the
assert and the cast than without, broken.
The assert has nothing to do with anything that your code actually
needs. Let me put it a different way: how would the assertion's
condition being false actually affect your code?
The cast is redundant as it is just forcing the compiler to do what it
already would without the cast. As far as the compiler is concerned,
except for their names, the following two functions are identical:
unsigned char RevChar1(unsigned char Byte)
{
typedef unsigned long tpname;
tpname byte = (tpname)Byte;
return (unsigned char)
(((byte & 128) >7)
| ((byte & 64) >5)
| ((byte & 32) >3)
| ((byte & 16) >1)
| ((byte & 8) << 1)
| ((byte & 4) << 3)
| ((byte & 2) << 5)
| ((byte & 1) << 7));
}
unsigned char RevChar2(unsigned char Byte)
{
typedef unsigned long tpname;
tpname byte = Byte;
return (unsigned char)
(((byte & 128) >7)
| ((byte & 64) >5)
| ((byte & 32) >3)
| ((byte & 16) >1)
| ((byte & 8) << 1)
| ((byte & 4) << 3)
| ((byte & 2) << 5)
| ((byte & 1) << 7));
}
--
Clark S. Cox III cl*******@gmail.com
Clark S. Cox III wrote:
Aman JIANG wrote:
Clark S. Cox III wrote:
Have you profiled that? I suspect that for code that simply reverses the
bits in a byte, there will be no noticeable speed difference.
You still haven't addressed the fact that the assert does not appear to
serve any purpose, and the cast is redundant.
In fact, On my machine(Intel P4), It was faster.
The optimized assembler of release version was more terse.
Again, I'd tend call any compiler that produces terser code with the
assert and the cast than without, broken.
The assert has nothing to do with anything that your code actually
needs. Let me put it a different way: how would the assertion's
condition being false actually affect your code?
The cast is redundant as it is just forcing the compiler to do what it
already would without the cast. As far as the compiler is concerned,
except for their names, the following two functions are identical:
unsigned char RevChar1(unsigned char Byte)
{
typedef unsigned long tpname;
tpname byte = (tpname)Byte;
return (unsigned char)
(((byte & 128) >7)
| ((byte & 64) >5)
| ((byte & 32) >3)
| ((byte & 16) >1)
| ((byte & 8) << 1)
| ((byte & 4) << 3)
| ((byte & 2) << 5)
| ((byte & 1) << 7));
}
unsigned char RevChar2(unsigned char Byte)
{
typedef unsigned long tpname;
tpname byte = Byte;
return (unsigned char)
(((byte & 128) >7)
| ((byte & 64) >5)
| ((byte & 32) >3)
| ((byte & 16) >1)
| ((byte & 8) << 1)
| ((byte & 4) << 3)
| ((byte & 2) << 5)
| ((byte & 1) << 7));
}
--
Clark S. Cox III
cl*******@gmail.com
Yes. I understand all your meaning.
The assert is useless, it's effect was just remind me to
keep the tpname be the WORD of the machine.
On my 32-bit machine, it must be 32-bit, like the nature
pointers, like the nature registers.
Aman JIANG wrote:
Yes. I understand all your meaning.
The assert is useless, it's effect was just remind me to
keep the tpname be the WORD of the machine.
On my 32-bit machine, it must be 32-bit, like the nature
pointers, like the nature registers.
Was my syntax wrong, please ?
"Aman JIANG" <Am*******@gmail.comwrote:
Richard Bos wrote:
No. He comes across as someone who has learnt English from web forums
and never could be arsed to learn better since, because of his poor
writing skills. He comes across as a student because he posts a homework
problem, even though he calls it a "GAME" (and what is it with those
capitals? Is homework more GAMEy than a normal game?).
"The pen is mightier than the sword."
Verum, sed non ad constitutium.
Sorry, English is *not* my nature language. In fact, my english is bad.
To talk with all you here, i have to use english diffidently.
So, if you can understand me, Don't deride my writting, please.
Not the point, either. Bad grammar and a limited vocabulary I can and
will excuse, for reasons that should be tolerably obvious if you have a
butcher's at my headers. Using schoolboy abbreviations such as "ur" for
"your", however, is plain laziness, not just a lack of practice.
Again, "This Is Not My Homework", and, "I Am Not A Student".
To answer this question is easy for me,
It's easy for everybody, and not very interesting.
*** Thank Paul Hsieh, you are praiseworthy.
For doing a websearch you could've done yourself? Doesn't seem very
helpful to me.
Richard
Richard Bos wrote:
Not the point, either. Bad grammar and a limited vocabulary I can and
will excuse, for reasons that should be tolerably obvious if you have a
butcher's at my headers. Using schoolboy abbreviations such as "ur" for
"your", however, is plain laziness, not just a lack of practice.
Thank you.
I have seen many "ur" for "your" on forums for short, and i leant.
It's easy for everybody, and not very interesting.
Somebody might have interest, and maybe it's hard for somebody.
It's just a inconspicuous game, maybe it's useflu, maybe not.
Richard Bos wrote:
Not the point, either. Bad grammar and a limited vocabulary I can and
will excuse, for reasons that should be tolerably obvious if you have a
butcher's at my headers. Using schoolboy abbreviations such as "ur" for
"your", however, is plain laziness, not just a lack of practice.
"for reasons that should be tolerably obvious if you have a
butcher's at my headers."
butcher ? what you mean please ?
i cannot understand this sentence.
have i hurt you, man ??
"Aman JIANG" <Am*******@gmail.comwrote in message
news:11*********************@d34g2000cwd.googlegro ups.com...
It's just a inconspicuous game, maybe it's useflu, maybe not.
It's not at all inconspicuous. Inconspicuous means low-profile, unlikely to
be noticed, what all spies aim to be. This thread is very big and prominent,
and impossible not to notice.
Perhaps you mean "innocent"?
Philip
Philip Potter wrote:
"Aman JIANG" <Am*******@gmail.comwrote in message
news:11*********************@d34g2000cwd.googlegro ups.com...
It's just a inconspicuous game, maybe it's useflu, maybe not.
It's not at all inconspicuous. Inconspicuous means low-profile, unlikely to
be noticed, what all spies aim to be. This thread is very big and prominent,
and impossible not to notice.
Perhaps you mean "innocent"?
Philip
Thanks for your help, my english is bad.
"innocent", yes.
Aman JIANG wrote:
Ben Pfaff wrote:
You could use a 16- or 8-byte table too. Code below not tested:
uint8_t
reverse_uint8 (uint8_t x)
{
static const uint8_t reverse_uint4[16]
= {0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15};
return reverse_uint4[x >4] | (reverse_uint4[x & 15] << 4);
}
It might still be faster than an approach without a table, and
certainly wouldn't be much bigger, if at all.
Yes. And you could write like this, too :
unsigned char reverse5b( unsigned char c)
{
static unsigned char table1[16] =
{
0x00,0x08,0x04,0x0C,0x02,0x0A,0x06,0x0E,0x01,0x09, 0x05,0x0D,0x03,0x0B,0x07,0x0F,
};
static unsigned char table2[16] =
{
0x00,0x80,0x40,0xC0,0x20,0xA0,0x60,0xE0,0x10,0x90, 0x50,0xD0,0x30,0xB0,0x70,0xF0
};
return table2[c&0xF] | table1[c>>4];
}
This is faster :)
Why do you say this? Any speed result will depend on the processor
used and
probably have a lot more to do with cache behaviour than instruction
count (thus
tight loop timing test are close to meaningless). True, in general
instruction count goes down
as the table size increases, but speed depends on a lot more than
instruction
count.
-William Hughes
Aman JIANG wrote:
Ben Pfaff wrote:
You could use a 16- or 8-byte table too. Code below not tested:
uint8_t
reverse_uint8 (uint8_t x)
{
static const uint8_t reverse_uint4[16]
= {0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15};
return reverse_uint4[x >4] | (reverse_uint4[x & 15] << 4);
}
It might still be faster than an approach without a table, and
certainly wouldn't be much bigger, if at all.
Yes. And you could write like this, too :
unsigned char reverse5b( unsigned char c)
{
static unsigned char table1[16] =
{
0x00,0x08,0x04,0x0C,0x02,0x0A,0x06,0x0E,0x01,0x09, 0x05,0x0D,0x03,0x0B,0x07,0x0F,
};
static unsigned char table2[16] =
{
0x00,0x80,0x40,0xC0,0x20,0xA0,0x60,0xE0,0x10,0x90, 0x50,0xD0,0x30,0xB0,0x70,0xF0
};
return table2[c&0xF] | table1[c>>4];
}
This is faster :)
Why do you say this? Any speed result will depend on the processor
used and
probably have a lot more to do with cache behaviour than instruction
count (thus
tight loop timing test are close to meaningless). True, in general
instruction count goes down
as the table size increases, but speed depends on a lot more than
instruction
count.
-William Hughes
"Aman JIANG" <Am*******@gmail.comwrites:
Clark S. Cox III wrote:
>Aman JIANG wrote:
[...]
Yes. If this question is not for the "8-bit byte", it's for 32-bit or
64-bit
unsigned integer, i think that nobody could use a TABLE.
Of course they could still use a table (why must you type "table" in all
caps?). There is nothing that says the table must contain all of the
possible values. You could still use a 256 element table to swap the
bits in a 64-bit integer, there's just a bit more math involved.
hum....understood. thanks.
because, i think if nobody use the table, this game will be more funny.
Please don't quote signatures (the lines at the end of an article
following the "-- " signature delimiter) unless you're actually
commenting on them.
I don't believe you've actually stated the rules of little "game" of
yours.
If you're trying to invent a new variant of Calvinball, I'm afraid I
still prefer the original. (If you don't know what Calvinball is,
Google it.)
--
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.
William Hughes wrote:
Aman JIANG wrote:
Ben Pfaff wrote:
You could use a 16- or 8-byte table too. Code below not tested:
>
uint8_t
reverse_uint8 (uint8_t x)
{
static const uint8_t reverse_uint4[16]
= {0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15};
>
return reverse_uint4[x >4] | (reverse_uint4[x & 15] << 4);
}
>
It might still be faster than an approach without a table, and
certainly wouldn't be much bigger, if at all.
Yes. And you could write like this, too :
unsigned char reverse5b( unsigned char c)
{
static unsigned char table1[16] =
{
0x00,0x08,0x04,0x0C,0x02,0x0A,0x06,0x0E,0x01,0x09, 0x05,0x0D,0x03,0x0B,0x07,0x0F,
};
static unsigned char table2[16] =
{
0x00,0x80,0x40,0xC0,0x20,0xA0,0x60,0xE0,0x10,0x90, 0x50,0xD0,0x30,0xB0,0x70,0xF0
};
return table2[c&0xF] | table1[c>>4];
}
This is faster :)
Why do you say this? Any speed result will depend on the processor
used and
probably have a lot more to do with cache behaviour than instruction
count (thus
tight loop timing test are close to meaningless). True, in general
instruction count goes down
as the table size increases, but speed depends on a lot more than
instruction
count.
-William Hughes
Maybe you are right.
In fact, I just gaind a result that from performance analyzer,
Shown me the program is faster.
Aman JIANG wrote:
Richard Bos wrote:
>Not the point, either. Bad grammar and a limited vocabulary I can and
will excuse, for reasons that should be tolerably obvious if you have a
butcher's at my headers. Using schoolboy abbreviations such as "ur" for
"your", however, is plain laziness, not just a lack of practice.
"for reasons that should be tolerably obvious if you have a
butcher's at my headers."
butcher ? what you mean please ?
i cannot understand this sentence.
"butchers" = "butcher's hook" = "look"; Cockney rhyming slang,
which has slightly seeped into UK English. I think Richard B
may have been making a subtle point about using unusual English.
--
Chris "or it's just his usual English mode" Dollin
The "good old days" used to be much better.
Chris Dollin wrote:
Aman JIANG wrote:
Richard Bos wrote:
Not the point, either. Bad grammar and a limited vocabulary I can and
will excuse, for reasons that should be tolerably obvious if you have a
butcher's at my headers. Using schoolboy abbreviations such as "ur" for
"your", however, is plain laziness, not just a lack of practice.
"for reasons that should be tolerably obvious if you have a
butcher's at my headers."
butcher ? what you mean please ?
i cannot understand this sentence.
"butchers" = "butcher's hook" = "look"; Cockney rhyming slang,
which has slightly seeped into UK English. I think Richard B
may have been making a subtle point about using unusual English.
--
Chris "or it's just his usual English mode" Dollin
The "good old days" used to be much better.
hum...i understand, now.
thank you very much :)
Aman JIANG wrote:
>
Clark S. Cox III wrote:
Quite possibly. On many platforms, a lookup table can be much faster
(especially a small one that only needs 255 elements).
>
Why not? What if the most optimal solution uses a table?
Because, this is a GAME only,
and the rule of this game is "real time".
if you use TABLE, you could gain the TIME, but you lose the SPACE.
/* BEGIN You_lose.c */
#include <stdio.h>
#include <limits.h>
#define I_win_on_time(B) \
((unsigned char)(B 255 ? I_win_on_space(B): TABLE[(B)]))
static unsigned char TABLE[256];
unsigned char I_win_on_space(unsigned char byte);
unsigned char (I_win_on_time)(unsigned char byte);
void bit_str(char *s1, const void *s2, size_t n);
void TABLE_init(void);
int main(void)
{
unsigned char index;
unsigned char rev;
char string[CHAR_BIT + 1];
char rev_string[CHAR_BIT + 1];
TABLE_init();
for (index = 0; index != UCHAR_MAX; ++index) {
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
}
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
return 0;
}
unsigned char (I_win_on_time)(unsigned char byte)
{
return I_win_on_time(byte);
}
unsigned char I_win_on_space(unsigned char byte)
{
unsigned hi_mask = ((unsigned char)-1 >1) + 1;
unsigned lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask lo_mask);
return byte;
}
void bit_str(char *s1, const void *s2, size_t n)
{
unsigned mask;
const unsigned char *const byte = s2;
while (n-- != 0) {
mask = ((unsigned char)-1 >1) + 1;
do {
*s1++ = (char)(mask & byte[n] ? '1' : '0');
mask >>= 1;
} while (mask != 0);
}
*s1 = '\0';
}
void TABLE_init(void)
{
unsigned char index = 0;
do {
++index;
TABLE[index] = I_win_on_space(index);
} while (index != 255);
}
/* END You_lose.c */
--
pete
pete <pf*****@mindspring.comwrites:
unsigned char I_win_on_space(unsigned char byte)
{
unsigned hi_mask = ((unsigned char)-1 >1) + 1;
unsigned lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask lo_mask);
return byte;
}
/* Works for 0 <= X <= 255. */
uint8_t no_this_is_shorter (uint64_t x)
{
return ((x * 0x202020202) & 0x10884422010) % 1023;
}
--
"Some programming practices beg for errors;
this one is like calling an 800 number
and having errors delivered to your door."
--Steve McConnell
pete wrote:
Aman JIANG wrote:
Clark S. Cox III wrote:
Quite possibly. On many platforms, a lookup table can be much faster
(especially a small one that only needs 255 elements).
Why not? What if the most optimal solution uses a table?
Because, this is a GAME only,
and the rule of this game is "real time".
if you use TABLE, you could gain the TIME, but you lose the SPACE.
/* BEGIN You_lose.c */
#include <stdio.h>
#include <limits.h>
#define I_win_on_time(B) \
((unsigned char)(B 255 ? I_win_on_space(B): TABLE[(B)]))
static unsigned char TABLE[256];
unsigned char I_win_on_space(unsigned char byte);
unsigned char (I_win_on_time)(unsigned char byte);
void bit_str(char *s1, const void *s2, size_t n);
void TABLE_init(void);
int main(void)
{
unsigned char index;
unsigned char rev;
char string[CHAR_BIT + 1];
char rev_string[CHAR_BIT + 1];
TABLE_init();
for (index = 0; index != UCHAR_MAX; ++index) {
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
}
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
return 0;
}
unsigned char (I_win_on_time)(unsigned char byte)
{
return I_win_on_time(byte);
}
unsigned char I_win_on_space(unsigned char byte)
{
unsigned hi_mask = ((unsigned char)-1 >1) + 1;
unsigned lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask lo_mask);
return byte;
}
void bit_str(char *s1, const void *s2, size_t n)
{
unsigned mask;
const unsigned char *const byte = s2;
while (n-- != 0) {
mask = ((unsigned char)-1 >1) + 1;
do {
*s1++ = (char)(mask & byte[n] ? '1' : '0');
mask >>= 1;
} while (mask != 0);
}
*s1 = '\0';
}
void TABLE_init(void)
{
unsigned char index = 0;
do {
++index;
TABLE[index] = I_win_on_space(index);
} while (index != 255);
}
/* END You_lose.c */
--
pete
Are you sure ?
I donnot think that your code can be the winner.
You used a 256-bytes-TABLE but you said that "I_win_on_space".
And, the function "I_win_on_space" was so slow.
Aman JIANG wrote:
>
pete wrote:
Aman JIANG wrote:
>
Clark S. Cox III wrote:
Quite possibly. On many platforms,
a lookup table can be much faster
(especially a small one that only needs 255 elements).
>
Why not? What if the most optimal solution uses a table?
>
Because, this is a GAME only,
and the rule of this game is "real time".
>
if you use TABLE, you could gain the TIME, but you lose the SPACE.
/* BEGIN You_lose.c */
#include <stdio.h>
#include <limits.h>
#define I_win_on_time(B) \
((unsigned char)(B 255 ? I_win_on_space(B): TABLE[(B)]))
static unsigned char TABLE[256];
unsigned char I_win_on_space(unsigned char byte);
unsigned char (I_win_on_time)(unsigned char byte);
void bit_str(char *s1, const void *s2, size_t n);
void TABLE_init(void);
int main(void)
{
unsigned char index;
unsigned char rev;
char string[CHAR_BIT + 1];
char rev_string[CHAR_BIT + 1];
TABLE_init();
for (index = 0; index != UCHAR_MAX; ++index) {
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
}
rev = I_win_on_time(index);
bit_str(string, &index, 1);
bit_str(rev_string, &rev, 1);
printf("%s %s\n", string, rev_string);
return 0;
}
unsigned char (I_win_on_time)(unsigned char byte)
{
return I_win_on_time(byte);
}
unsigned char I_win_on_space(unsigned char byte)
{
unsigned hi_mask = ((unsigned char)-1 >1) + 1;
unsigned lo_mask = 1;
do {
if (!(byte & hi_mask) != !(byte & lo_mask)) {
byte ^= hi_mask | lo_mask;
}
hi_mask >>= 1;
lo_mask <<= 1;
} while (hi_mask lo_mask);
return byte;
}
void bit_str(char *s1, const void *s2, size_t n)
{
unsigned mask;
const unsigned char *const byte = s2;
while (n-- != 0) {
mask = ((unsigned char)-1 >1) + 1;
do {
*s1++ = (char)(mask & byte[n] ? '1' : '0');
mask >>= 1;
} while (mask != 0);
}
*s1 = '\0';
}
void TABLE_init(void)
{
unsigned char index = 0;
do {
++index;
TABLE[index] = I_win_on_space(index);
} while (index != 255);
}
/* END You_lose.c */
--
pete
Are you sure ?
Yes.
I donnot think that your code can be the winner.
You used a 256-bytes-TABLE but you said that "I_win_on_space".
The I_win_on_space function, doesn't use or need the TABLE.
And, the function "I_win_on_space" was so slow.
That's why it's called "I_win_on_space"
instead of "I_win_on_time".
The I_win_on_time function, is the fast one.
That's the one that uses the table.
According to Calvinball rules:
you lose on space to I_win_on_space
and you lose on time to I_win_on_time,
because the code has to be DS9k portable,
and the time test has to be done on an 8 bit char implementation.
--
pete
Aman JIANG said:
pete wrote:
>According to Calvinball rules:
This is not a Calvinball game and I donnot know
what is Calvinball at all.
Not knowing what Calvinball is incurs a penalty. You must now stand on your
head and play "Smoke on the Water" on a kazoo.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote:
Not knowing what Calvinball is incurs a penalty. You must now stand on your
head and play "Smoke on the Water" on a kazoo.
I can't do that.
Superman can't do that.
and Spiderman can't do that, too.
Can you?
Aman JIANG wrote:
Richard Heathfield wrote:
>Not knowing what Calvinball is incurs a penalty. You must now stand on your
head and play "Smoke on the Water" on a kazoo.
I can't do that.
Superman can't do that.
and Spiderman can't do that, too.
If Spiderman knew the tune, he'd be able to do it.
--
Chris "spiderfan" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/
In article <11*********************@h48g2000cwc.googlegroups. com>,
Aman JIANG <Am*******@gmail.comwrote:
>Go without saying, a function with TABLE will be fastest.
Not necessarily. As processors get faster, memory accesses become
more expensive relative to operations on registers - perhaps hundreds
of times more expensive. For a case like this with a small table, a
table will almost certainly be faster *if you do it often enough*,
because the table will fit in the cache.
-- Richard This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Bryan Krone |
last post by:
I have a stream of data comming off a serial port at 19200. I am wondering
what is the most efficient way to grep through the data in realtime? I have
20 or so different strings I need to find. All...
|
by: jacob navia |
last post by:
As everybody knows, C uses a zero delimited unbounded
pointer for its representation of strings.
This is extremely inefficient because at each query of the
length of the string, the computer...
|
by: Russ Brown |
last post by:
Hello all,
Recently a post on this list made me think a bit about the way in which I
write my queries.
I have always written queries with ordinary joins in this manner:
SELECT * FROM a, b...
|
by: Phil Endecott |
last post by:
Dear Experts,
I have a couple of questions about the efficiency of queries involving
views.
Say I have a large table T, and a view V that just adds some extra
columns to T, using for example...
|
by: extrudedaluminiu |
last post by:
Hi,
Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?
Thanks,
-vs
| | |
by: burningsunorama |
last post by:
Hi guys!
This is maybe a too 'academic problem', but I would like to hear your
opinions, something like pros and cons for each approach....
... Recently we've had at work a little talk about the...
|
by: Frederick Gotham |
last post by:
I'm trying to write extremely efficient, fully portable algorithms to
determine if an integer is odd or even. The most basic algorithms would be:
#define IS_ODD(x) ((x) % 2)
#define IS_EVEN(x)...
|
by: vamshi |
last post by:
Hi all,
This is a question about the efficiency of the code.
a :-
int i;
for( i = 0; i < 20; i++ )
printf("%d",i);
b:-
int i = 10;
|
by: OldBirdman |
last post by:
Efficiency
I've never stumbled on any discussion of efficiency of various methods of coding, although I have found posts on various forums where individuals were concerned with efficiency. I'm...
|
by: john |
last post by:
Hi, in TC++PL 3 on pages 674-675 it is mentioned:
"Maybe your first idea for a two-dimensional vector was something like this:
class Matrix {
valarray< valarray<doublev;
public:
// ...
};
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
