Submit | All submissions | Best solutions | Back to list |
GRIDPNT - Grid points |
There's a Cartesian lattice with 0<=x,y<=n. Given one point (x1, y1>0) in this lattice rotating clockwise as little as possible around the origin find the next point (x2, y2). The given and searched points mustn't have another point between the origin (0, 0) and this point itself.
x1, y1, x2, y2 are non-negative integers.
Score is source length.
Input
In the first line the number T (T<100) of test cases.
Then T lines with the space-separated n (1<=n<=50), x1 and y1.
Output
For each test case the space-separated x2 and y2.
Example
Input: 3
1 1 1
5 3 2
50 48 49 Output: 1 0
5 3
49 50
Added by: | HWK |
Date: | 2011-05-24 |
Time limit: | 9.989s |
Source limit: | 50000B |
Memory limit: | 1536MB |
Cluster: | Cube (Intel G860) |
Languages: | All except: SCM qobi |
hide comments
|
|||||
2011-07-19 17:52:15 Jander
Oh I totally agree in competition :-) It can be frustrating when an improvement to your own code gets used against you (you know what that improvement was - I can see when you used it :-) ). Fortunately your comment re. better algorithm made me look at the problem from a different angle which helped a lot. Now to see if there's any more improvement. |
|||||
2011-07-19 17:41:49 HWK
Yes, Jander, I think it's enough (for the moment). :-) Congratulations! Really great work. It seems that Piotr Kakol is right. He supposed that submitting shorter solutions is more motivating than only mention them. I guess you hadn't shortened your solution to 81 bytes otherwise. Let's see if hallvabo will improve his Python solution too. Hi, hallvabo! ;-) Last edit: 2011-07-19 17:43:20 |
|||||
2011-07-19 12:51:55 Jander
Oi, (challenger_)hwk - stop it ! ;-) |
|||||
2011-06-30 15:44:55 HWK
@hallvabo: Found a better algorithm in a C-solution from main SPOJ -> 133 Python bytes. And I guess you could do it better. ;-) Edit: 129 bytes. Last edit: 2011-07-02 08:06:21 |
|||||
2011-06-26 19:21:33 HWK
@Jander: You have to advance your solution more because XeRon!X could reach 100 bytes with his one. ;-) With another approach even 84 Bash bytes are possible. Last edit: 2011-06-30 12:02:31 |
|||||
2011-06-07 12:20:30 HWK
@hallvabo: Yes, an excellent one. Congratulations. |
|||||
2011-06-06 18:32:44 Hallvard Norheim Bø
@HWK: finally found a good algorithm! Last edit: 2011-06-06 18:57:33 |
|||||
2011-06-03 17:53:54 Jander
@HWK: Valid point about where to discuss challenges. The IRC channel is #spoj on Freenode. The main Spoj page refers to it at the bottom. |
|||||
2011-06-03 17:42:13 HWK
@Jander: Which IRC channel? If we want to talk along about BINCLOCK we should do it in that task. I don't know your solution but do you want a hint at my? Last edit: 2011-06-03 17:44:19 |
|||||
2011-06-03 14:17:31 Jander
It takes me 62 bytes to do that conversion :-( I've still not worked out an efficient method yet. That's from the raw input 'vertical' bits - ie no reordering. Pity you don't frequent the IRC channel :-) Last edit: 2011-06-03 14:48:05 |