DogChallenges | Join And Retrieve Number! - Challenge N°1

[josku_x]

Trond, for me that looks promising

[rsts]

Where's dagcrack? We've been waiting almost a month.

Is Trond's solution a "winner"?

What's your solution to the "almost too easy" problem?

cheers

[netmaestro]

You could represent the two numbers in binary form, placing one bit of the smaller number under every other bit in the larger number. Then, you can decide on a whim whether to store a bitpair or its reciprocal in the target number. If the bitpair is smaller, store that. if the reciprocal is smaller, store that instead. In this way you can "fold" a number into another and you can get it back simply by looking at the bitpairs and seeing if what's there would be the smaller or larger between it and its reciprocal. The pattern of your "whims" becomes the key:

Code: Select all

10 10 11 00 00 10 01 11   Bitpairs from number
01 01 00 11 11 01 10 00   Reciprocals
 0  1  1  0  1  1  0  0   For 0's choose smaller, for 1's choose larger
----------------------------
01 10  11 00 11 10 01 00  You can tell which was chosen and reconstruct the bit pattern of the smaller number

[Dare2]

Hi netmaestro,

I don't quite follow your solution (my bad, not yours).

How would you handle 32767 ($7FFF or 01 11 11 11 11 11 11 11) as the biggie and 127 as the littlie?

PS: I also get a different whim.

Code: Select all

01 10 01 11 00 11 00 11   original word-sized number = 26419
N  Y  Y  Y  N  Y  N  Y    whims (based on 1's or 0's found in storage number) 
N  Y  N  Y  N  Y  N  Y    what I got

So I am obviously missing the point.



Edit:

I don't think the challenge is solvable as defined, but that may just be a phraseology/terminology issue.

If so, an EBCDIC-type could be used. (nibble for byte, basically, for one range of bits for one, another for the other. )

[netmaestro]

The solution to that all depends on what you choose for a key. Different keys, different results.

[Dare2]

Ah, okay. I see.

[netmaestro]

@dagcrack: I read carefully over your rules and I don't see where the solution has to reconstitute the original 5-digit number, only extract the 3-digit one. My solution, in fact, can't do that.

[Trond]

@dagcrack: I read carefully over your rules and I don't see where the solution has to reconstitute the original 5-digit number, only extract the 3-digit one. My solution, in fact, can't do that.

Oh, we don't have to get the 5-digit one back? That's right, I re-read the rules. Here's my solution:

Code: Select all

word.w = Random(32767)
byte.b = Random(255)

PokeB(@Word, Byte)
Byte = 0

Byte = PeekB(@Word)
Debug Byte

[netmaestro]

Well, that would be legal as I read the rules.

[netmaestro]

But trond, it wouldn't hide the number at all. It's right there to look at.

[Dare2]

lol, Trond.

Okay, I have a challenge for everyone here.

Challenge: Giving clear and concise and understandable rules, define an original problem or puzzle. It must be small, elegant, and solved using PureBasic.

[Trond]

Now on process number 2 you should be able to take the small number out of the big one with OUT knowing the small number. thats the point.

I re-read the rules. It is written nowhere in the first post that we can't know the value of the big number. So it's easy:

Code: Select all

Bignum.w = Random(32000)
Smallnum.b = Random(256)

; Display initial numbers
Debug Bignum
Debug Smallnum

; The rules doesn't say I can't do this
Cache.w = Bignum

; Smash smallnum into bignum and erase the original smallnum
Bignum + Smallnum
Smallnum = 0

; Extract the small number from the large one, and restore the large one
Smallnum = Bignum-Cache
Bignum = Bignum - Smallnum
Debug Bignum
Debug Smallnum

You can't use string operations (Passed)
You can't make the 5 char number bigger than 5 chars (Passed, as long as we assume the word is unsigned.)
You can't use floats (as final output) (Passed)
You can't use longs (as final output) (Passed)

Now where's the answer?

[thamarok]

Trond's code doesn't violate any rules, I think this is the too-easy solution for this. So where's dagcrack?