the following conversation takes places:
peter: i don't know the solution
simon: i already knew that
peter: know i know the solution
simon: know i know it, too
daniel: wtf? i can only suspect one of the numbers but can't be sure
peter: the number you are suspecting is wrong
daniel: k, now i now the numbers, too
i'll post my solution as soon as i get one, including the scala code
thar produces it. have fun.
It seems you can determine the numbers without knowing the sum,
product and difference.
At least, that is my interpretation of the riddle.
Regards,
Rüdiger
2011/5/28 Russ Paielli <russ.p...@gmail.com>:
Am 28.05.2011 09:50, schrieb Ruediger Keller:
> I don't think that's the right interpretation on the riddle. The three
> participants aren't actually telling each other the results.
>
> It seems you can determine the numbers without knowing the sum,
> product and difference.
>
> At least, that is my interpretation of the riddle.
>
> Regards,
> R�diger
there are 3 people. let's name them peter, simon and daniel. the three
are supposed to figure out a pair of numbes. the possible pairs are all
combinations of numbers from 0 to 1000, meaning:
(0,0), (1,0), (2,0)....(1000,0),(1,1),(1,2) up to (1000,1000)
peter knows the product of the pair, simon knows the sum, and daniel
knows the difference.
the following conversation takes places:
peter: i don't know the solution
simon: i already knew that
peter: now i know the solution
simon: now i know it, too
daniel: wtf? i can only suspect one of the numbers but can't be sure
peter: the number you are suspecting is wrong
daniel: k, now i know the numbers, too
i solved it completely: http://pastebin.com/n0HKSFmr
however, the code is quite.... unreadable. when solving math problems, i always run into the problem that the code tends to become very, very abstract and i myself don't understand what exactly is going on if i don't add some images explaining the logic.
any idea how this code can be simplified a bit?
adding type annotations is obviously not going to help - what does map[int, iterable[(int,int)]] going to tell you? not much.
Am 28.05.2011 17:36, schrieb Rex Kerr:If you think I exploted the difference between flatMap and map+flatten intentionally, you're giving me too much credit.
When I'm quickly thinking and writing through a problem as I did here, I tend to use the most basic methods that accomplish what I'm looking for (e.g. map + flatten instead of flatMap). The reason is that I don't know what I'm doing yet, and if I want to insert a logical step between the map and flatten, it's easier to do if I write it as map + flatten than as flatMap. Note the map + filter + flattens, for example. (flatCollect, anyone?)
--Rex
On Sat, May 28, 2011 at 11:20 AM, Alec Zorab <alec...@googlemail.com> wrote:
Rex's solution is interesting because it's the first time I've seen
x.map(f).flatten do a different thing to x.flatMap(f). Having played
follow the types a little bit it becomes clear what's going on, but
it's an unusual example nonetheless
2011/5/30 HamsterofDeath <h-s...@gmx.de>
i solved it completely: http://pastebin.com/n0HKSFmr
however, the code is quite.... unreadable. when solving math problems, i always run into the problem that the code tends to become very, very abstract and i myself don't understand what exactly is going on if i don't add some images explaining the logic.
any idea how this code can be simplified a bit?
adding type annotations is obviously not going to help - what does map[int, iterable[(int,int)]] going to tell you? not much.
Hum, first off, why the hell would you do this ?
val someVal = {
val firstElem = ...
val secondElem = firstElem.someMethod(...)
}
I really find it weird both to read and write. Just doesn't feel right enough. I can understand that you try grouping the computations in semantically relevant groups, but for a problem as "simple" (architecturally) as that riddle, why do you need this ? I would just write it like this :
Because as demonstrated by Rex, the problem would just fit into 7 Scala affectations
val firstElem = ...
val someVal = firstElem.someMethod(...)
, and boom goes the dynamite. I would start thinking about your style when designing a very deep problem solution, or a computing-oriented library, but not for this task. A scriptic style would feel clearer, faster, and more natural to me. I would also rethink the blank lines and comments. Maybe there's a logic behind them, but from one step backward, it just seems messy...