The forum is not the place for a "pre-appeal" questions. If you think you have a case, you are welcome to proceed by appealing in the standard way. however, since you have already asked here something, I will emphasize a few things on the question, regardless to the specific details of your submission (after reading this you, and others as well, can decide if they have a case for an appeal):
An iterative solution is, indeed, a better solution to this problem than a recursive one. Recursion here can easily end up in reaching the maximum depth of recursion, since ranges can be big, and functions can be weird.. But, this is also the reason why bounding the function into a predefined number of iterations can be problematic.
If the reason is a need to limit the running time of the function, this limit should be high enough in order that calculations on reasonable inputs will terminate in a normal way. Moreover, as a user, I would expect that this limit will be a function of (at least) the size of the range given to the function.
So, if this limit was incorporated in the code as a mechanism to defend the code from non stopping, and if this was well explained - this might be a good thing to write when appealing. BUT, if you are going to say that after 100 iterations the function surely does not stop due to float precision, I can give a huge range of approximately 2 to the 100, and claim that no floating precision occurred that prevented the function to stop. So, think if you have an answer for that too, when you appeal..
By the way, a better way to stop the function (besides a limit which is a function of the range) would be to stop when the range is small enough (although this also have problems when it comes to "crazy" functions).
As for the second question: getitem should return a matrix if given slices as input. Not a list of lists. If you had done that, the repr function of class Matrix would have already taken care of the <Matrix> thing.