Page 2 of 2
Posted: Sun Jul 27, 2008 9:55 pm
by nullsquared
syd wrote:nullsquared wrote:
Mwahaha, well, mine DOES!
Code: Select all
int main()
{
std::cout << decimal_t<10000001>::value << "\n"; // outputs 257
}
how comes it outputs 257 ?? A byte has 256 possible values right?
Right, but decimal_t::value is an unsigned long. You'll want to manually cast to char().
Posted: Sun Jul 27, 2008 9:59 pm
by syd
it might be an unsigned long, but 10000001 just can't make 257
11111111 would be 255 (as unsigned)
Posted: Sun Jul 27, 2008 10:01 pm
by Kojack
Mwahaha, well, mine DOES!
Actually yours fails with any number starting with 0.
plus it doesn't actually meet your own requirements for the challenge:
write a program that parses the follow binary:
01001101 01100001 01100011 01101000 01101001 01101110 01100101 00100000 01000011 01101111 01100100 01100101 00100001
And writes out the characters that are represented by it.
It can't handle those numbers (the leading zeros have to be removed) and it doesn't print out the characters.
The reason for the 0 thingy is because any integer value in c++ which starts with a zero is octal instead of decimal.
10 is ten
010 is eight
That's why my versions have /8 in them instead of /10, so it can handle the required binary sequence which had a leading 0.
So yes, syd's is the only numeric version which doesn't care if there's a leading zero or not.
On a side note, who the hell uses octal? I'm pretty sure I've never had a use for it. Decimal, binary and hex are useful, but octal? And why not change the c++ representation to be more like hex? I wonder how many bugs in programs are due to a programmer editing a number and leaving a leading zero, thinking it won't make a difference?
Posted: Sun Jul 27, 2008 10:24 pm
by syd
Kojack wrote:Actually yours fails with any number starting with 0.
but any leading 0 shouldn't have any impact, it should't affect the result, does it?
if you write 0101, it's the same as 101... not sure I got your point, though
@nullsquared: 10000001 makes actually 129:
129 = 128 + 1 = 2 ^ 7 + 2 ^ 0
it seems your algorythm do 2 ^ 8 + 2 ^ 0 (= 257)
Posted: Sun Jul 27, 2008 11:15 pm
by syd
The reason for the 0 thingy is because any integer value in c++ which starts with a zero is octal instead of decimal.
man! the answer was right on my nose.
I had no idea about that.
Posted: Mon Jul 28, 2008 12:00 am
by Assaf Raman
My compile-time solution:
http://ogre.pastebin.com/f668dbf47
All you need is to define this at the start:
Code: Select all
#define BinaryString "01001101 01100001 01100011 01101000 01101001 01101110 01100101 00100000 01000011 01101111 01100100 01100101 00100001"
#define BinaryStringLength 13
BinaryString - is the string you want to parse.
BinaryStringLength is the number of "binary chars".
Posted: Mon Jul 28, 2008 12:46 am
by Assaf Raman
I don't know if I made it clear in my last post - my solution compiles in "release compile" to assembly code that has all the string already parsed – meaning – no parsing is done in real-time – the final assembly code is just one cout for each char of the compile time parsing.
If you don’t believe me – have a look at the code in the visual studio disassembly window while you run the program. (You can place a breakpoint on the cout command then open the disassembly window).
My solution also keeps the input string exactly in the same format as defined in the challenge.
Posted: Mon Jul 28, 2008 8:11 am
by Assaf Raman
After talking about it with the guys at work – I guess my solution is not valid – my solution results in assembly code that parses the string to the right chars without any other operation - only when optimization is on – and that this is not valid in this type of challenge..
Posted: Mon Jul 28, 2008 3:34 pm
by nullsquared
Argh I feel really
right now
Edit:
Wait, my logic is right, but I was a complete failure to provide a working example
syd wrote:it might be an unsigned long, but 10000001 just can't make 257
11111111 would be 255 (as unsigned)
Right, I needed an extra 0 in between
plus it doesn't actually meet your own requirements for the challenge:
write a program that parses the follow binary:
01001101 01100001 01100011 01101000 01101001 01101110 01100101 00100000 01000011 01101111 01100100 01100101 00100001
And writes out the characters that are represented by it.
It can't handle those numbers (the leading zeros have to be removed) and it doesn't print out the characters.
Yup, here is my actual run-time usage (probably should've posted it along with the rest of the stuff):
Code: Select all
int main()
{
using boost::lexical_cast;
using std::string;
using std::cout;
string str("01001101011000010110001101101000011010010110111001"
"100101001000000100001101101111011001000110010100100001");
for (N i = 0; i < str.size(); i += 8)
cout << char(decimal_f(lexical_cast<N>(string(str.begin() + i, str.begin() + i + 8))));
}
And now I can see why it didn't mess up with the '0' in front, there a string "0101" doesn't get parsed into the number 0101, but in 101
. Yup, I fail at my own challenge
.