Added OOP approach to matrices

[jasper256]

This is far from done but just a little project I was working on for fun that I thought would be nice to add to this repo eventually. I still need to add determinants, cofactors, etc. but I thought it might be good to post this and see if I got any advice / criticisms of things to think or if you guys thought it looked good to keep going the way it is. I just noticed that you guys are now recommending running Python Black, which I haven't done yet but will get to soon. Anyway, let me know what you think!

[jasper256]

I have now added all methods I intended to, but can add more if people have suggestions. I also formatted with python/black as recommended. One mild bug that persists is the issue of printing out Matrix objects. For some reason, after a couple (I believe it's two, but it might vary) are printed, the next one to be printed is formatted incorrectly. This causes the doctest to fail in one case. I don't believe this is an error with the str method because when playing around in IDLE I found that I can get any Matrix to print correctly, but when I print a few in a row the bug occurs. Please let me know if anyone knows how to fix this, as well as any general feedback.

[McDic]

1. pow method is linear complexity, you can reduce it to logarithm complexity with simple optimizations.

2. Why did you applied property decorator to determinant, minors, etc while their time complexity is non-polynomial? Wouldn't be better to consider these methods as non-properties so developers will think calculations are expensive?

3. It would be better if str method generates numpy/scipy style.

[cclauss]

https://travis-ci.org/TheAlgorithms/Python/builds/580019829#L735

[jasper256]

Thanks for the feedback.

1. `pow` method is linear complexity, you can reduce it to logarithm complexity with simple optimizations.

I am not especially knowledgeable in this subject area so I will look into that and fix it as soon as possible.

2. Why did you applied `property` decorator to `determinant`, `minors`, etc while their time complexity is non-polynomial? Wouldn't be better to consider these methods as non-properties so developers will think calculations are expensive?

I am a pretty inexperienced programmer so I don't really have a good reason as to 'why'. I didn't realize that this indicated polynomial time complexity (I barely understand time complexity but am looking to learn more about it). Anyway, I will certainly change this. I think I will leave num_rows, num_columns, order, and is_square as properties because they are much less complex unless you think they should be changed too. Let me know.

3. It would be better if `str` method generates numpy/scipy style.

I had never used numpy before so I didn't even realize this standard existed. Thanks for bringing it to my attention, I made this change.

[McDic]

Try this at the end of the code. Your program will never terminate if given input is larger than 4.

if__name__=="__main__":
pass# import doctest# test = doctest.testmod()importrandomsize=int(input("Input size: "))
mat= [[random.random() *100forjinrange(1, size+1)] foriinrange(size)]
mat=Matrix(mat)
print(mat.determinant())

I think you need more optimizations.

[McDic]

And I meant clean string style for __str__ is making same length for each row.

Your initial commit shows strings like

[1, 2, 3]
[11, 22, 33]
[17, 6, -2]

and I intended

[ 1, 2, 3]
[11, 22, 33]
[17, 6, -2]

But I don't think fixing __str__ is not important, as there is some critical performance issue on determinant, inversing, etc.

[jasper256]

@McDic I just wanted to say that I've seen your comments and appreciate the feedback. Sorry if it is taking me a while to make changes but school just started for me and I have been very busy. So this might take me a while to complete, but don't think I have forgotten about it.

[cclauss]

This is in a useful state and passes the tests so let’s land and the improvements requested above can come as pull requests.