Programming Challenges

[nullsquared]

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().

[syd]

it might be an unsigned long, but 10000001 just can't make 257

11111111 would be 255 (as unsigned)

[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?

[syd]

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)

[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.

[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".

[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.

[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..

[nullsquared]

Argh I feel really right now

Edit:
Wait, my logic is right, but I was a complete failure to provide a working example

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 .