
August 21st, 2004, 09:17 AM
#1
just4fun
For those who enjoy spending time solving algorithmical problems, here's one:
Originally Posted by dontrememberauthor
Given a square having side a positive integer (n > 0, n belongs to N*), find the smallest number of squares having also positive integer side, in which can be devided.
Examples:
 n = 2, 4 squares of side 1;
 n = 3, 6 squares (1 of side 2 + 5 of side 1);
 n = 5, 8 squares (1 of side 3 + 3 of side 2 + 4 of side 1)...
I'm curious who's the first to find the solution for n = 13!
If you care to write the implementation of your algorithm, try as input n = 9973.
Have fun!

August 28th, 2004, 02:25 PM
#2
Re: just4fun
Do you have a proved solution (don't give one, just I wonder if there is).
Even if n=7 (8 squares) I can't figure out some (especially O(n^2) as I see n=9973!) heuristics...
"Programs must be written for people to read, and only incidentally for machines to execute."

August 29th, 2004, 05:19 AM
#3
Re: just4fun
Proved solution? I think so. Even that I didn't publish any complete mathematical study and proof of my implementation, doesn't mean that my solution is incorrect.
I can assure you of one thing: my post is not trying to waste your time, and strongly believe that there is a flawless solution to this problem.
So, find it if you can and enjoy doing this kind of activities.
Thanks for showing interest. Hope we'll soon discuss about possible solutions.
Have fun,

August 29th, 2004, 10:53 AM
#4
Re: just4fun
It could be solved by backtracking or knapsack style and I see many optimizations available. The runtime is the bother.
Also 13! can't be represented by a 32bit integer I believe so this would be a hassle.

August 30th, 2004, 12:50 AM
#5
Re: just4fun
Hi Joe!
Considering the complexity of this problem, backtracking is more a theoretical solution, as it can be for most ever invented problems. As for knapsack style, there are no similarities with the coins problem, since coins doesn't have to be arranged in any way to fit the sum, so there, you can apply greedy. But in our square problem, there's no way to tell what relationship must exists in a set of squares, assuring us that they form a bigger square.
You see, we know that our solution set of squares must satisfy some mathematical conditions, for example the area formula:
sum(x[i]^2) = n^2, where n is the side of the input square and x[i] is the side of the ith square in our solution; of course, sum() is a pseudofunction computing the sum.
But only this formula is not enough to ensure a valid solution, because not all such sets can form the square of side n. Take for example the pitagoric numbers 3^2+4^2 =5^2; they are respecting the above formula, but a square of side 5 cannot be made out of a square having side 3 and a square with side 4. The arrangement is not possible.
How else can you optimize a backtraking based algorithm? Maybe "Branch & Bound" by stoping the search at the last best solution, or "Divide & Conquer" by finding a way to reduce the problem to a smaller square?
As RoboTact already mentioned, did you try to figure out "some heuristics" that might work for this problem?
Originally Posted by Joe Nellis
Also 13! can't be represented by a 32bit integer I believe so this would be a hassle.
Why would you wanna represent the factorial of 13 to solve this problem? This ain't a permutation problem, and even if it would've been, why to store the number of permutations? For a square with side n, there's no reason to store or work with numbers bigger than n^2 (as you use for area testing).
Guys, yet nobody can give me the solution for n=13? It's a tiny little square that you can draw on a paper or a board... and divide it a few times, counting the number of squares required for a complete division.

August 30th, 2004, 06:42 AM
#6
Re: just4fun
It would be not an algotithmic solution it I just draw a square and try to figure out a solution... More of that: I even don't know a way to prove that some solution for n=13 is optimal. So, I think the only thing worth doing is to solve the general algorithmic problem. However, I just enjoing holidays before new term (writing my project ), from second of september I'll try to force the problem...
"Programs must be written for people to read, and only incidentally for machines to execute."

August 30th, 2004, 10:57 AM
#7
Re: just4fun
Originally Posted by Bornish
I'm curious who's the first to find the solution for n = 13!
Originally Posted by Bornish
Why would you wanna represent the factorial of 13 to solve this problem?
I'm sorry I participated in this thread now.

September 1st, 2004, 06:52 AM
#8
Re: just4fun
Last edited by DeepButi; September 1st, 2004 at 07:01 AM.
Did it help? rate it.
The best conversation I had was over forty million years ago ... and that was with a coffee machine.

September 1st, 2004, 07:32 AM
#9
Re: just4fun
I've written very short bruteforce program. It's printed the following results:
Bruteforce method. Starting with N=5 and Opt=10
Pass 1: Searching for optimal value...
Found better solution: old=10, new=8
Pass 2: Optimal value already found(8), restoring optimal map...
AAABB
AAABB
AAACC
DD.CC
DD...
Bruteforce method. Starting with N=7 and Opt=14
Pass 1: Searching for optimal value...
Found better solution: old=14, new=10
Found better solution: old=10, new=9
Pass 2: Optimal value already found(9), restoring optimal map...
AAAABBB
AAAABBB
AAAABBB
AAAADD.
CCC.DD.
CCCEEFF
CCCEEFF
Bruteforce method. Starting with N=11 and Opt=22
Pass 1: Searching for optimal value...
Found better solution: old=22, new=14
Found better solution: old=14, new=12
Found better solution: old=12, new=11
Pass 2: Optimal value already found(11), restoring optimal map...
AAAAAAABBBB
AAAAAAABBBB
AAAAAAABBBB
AAAAAAABBBB
AAAAAAACCCC
AAAAAAACCCC
AAAAAAACCCC
DDDDFF.CCCC
DDDDFFEEEGG
DDDDHHEEEGG
DDDDHHEEE..
Bruteforce method. Starting with N=13 and Opt=26
Pass 1: Searching for optimal value...
Found better solution: old=26, new=16
Found better solution: old=16, new=14
Found better solution: old=14, new=13
Found better solution: old=13, new=12
Found better solution: old=12, new=11
Pass 2: Optimal value already found(11), restoring optimal map...
AAAAAAABBBBBB
AAAAAAABBBBBB
AAAAAAABBBBBB
AAAAAAABBBBBB
AAAAAAABBBBBB
AAAAAAABBBBBB
AAAAAAAGGDDDD
CCCCCC.GGDDDD
CCCCCCEEEDDDD
CCCCCCEEEDDDD
CCCCCCEEE.FFF
CCCCCCHHIIFFF
CCCCCCHHIIFFF
Bruteforce method. Starting with N=15 and Opt=30
Pass 1: Searching for optimal value...
Found better solution: old=30, new=18
Found better solution: old=18, new=10
Found better solution: old=10, new=6
Pass 2: Optimal value already found(6), restoring optimal map...
AAAAAAAAAABBBBB
AAAAAAAAAABBBBB
AAAAAAAAAABBBBB
AAAAAAAAAABBBBB
AAAAAAAAAABBBBB
AAAAAAAAAACCCCC
AAAAAAAAAACCCCC
AAAAAAAAAACCCCC
AAAAAAAAAACCCCC
AAAAAAAAAACCCCC
DDDDDEEEEEFFFFF
DDDDDEEEEEFFFFF
DDDDDEEEEEFFFFF
DDDDDEEEEEFFFFF
DDDDDEEEEEFFFFF

September 1st, 2004, 07:46 AM
#10
Re: just4fun
Congratulations Vasya!
You are the first to reply with the solution for n=13.
Indeed, this square can be devided in minimum 11 squares, as you've already proved in your post.
Have you tried your implementation with 9973 as input square?
If your implementation is finding a solution (don't display the map), please let me know in how much time was found and please send me your implementation, or at least post the algorithm as pseudocode.
Thanks,

September 1st, 2004, 10:26 AM
#11
Re: just4fun
12 for n=17 ... but pure brute force was not what I expected
22222222111111111
22222222111111111
22222222111111111
22222222111111111
22222222111111111
22222222111111111
22222222111111111
22222222111111111
5555777B111111111
55557778833333333
55557778833333333
5555C666633333333
44444666633333333
44444666633333333
44444666633333333
4444499AA33333333
4444499AA33333333
(mine would take ages for n=9973 )
Did it help? rate it.
The best conversation I had was over forty million years ago ... and that was with a coffee machine.
Posting Permissions
 You may not post new threads
 You may not post replies
 You may not post attachments
 You may not edit your posts

Forum Rules

Click Here to Expand Forum to Full Width
This is a Codeguru.com survey!
