Matrix Ruby Wrappers

[rajithv]

[rajithv]

@abinashmeher999 @isuruf

Please check the following:

irb(main):003:0> A = SymEngine::DenseMatrix.new(arr)
=> #<SymEngine::DenseMatrix([1, 2]
[3, 4]
[5, 6]
)>
irb(main):004:0> A.to_s
=> "[1, 2]\n[3, 4]\n[5, 6]\n"

Also, does it need row count and column count?

The to_s output is not nice.. right? What are our options?

[zverok]

There are two main things to consider:

1. inspect: it should be as informative, as possible, but with reasonable limitation; for example, what we did in daru:

v = Daru::DataFrame.new(a: [1,2,3], b: [4,5,6])
# => #<Daru::DataFrame(3x2)>
#       a   b
#   0   1   4
#   1   2   5
#   2   3   6 

v = Daru::DataFrame.new(a: (1..100), b: (201..300))
# => #<Daru::DataFrame(100x2)>
#       a   b
#   0   1 201
#   1   2 202
#   2   3 203
#   3   4 204
#   4   5 205
#   5   6 206
#   6   7 207
#   7   8 208
#   8   9 209
#   9  10 210
#  10  11 211
#  11  12 212
#  12  13 213
#  13  14 214
#  14  15 215
# ... ... ... 

# ^ above is full output of #inspect of large DataFrame, including those "..."

2. to_s: for "non-stringy" types it should be as short as possible (while saving some informativeness), consider it used in contexts like raise ArgumentError, "Expected blah, yet received #{wtf}" ← this uses #to_s to render some error message... And somebody would output it.

[rajithv]

@zverok Thanks. I'll come up with a scheme considering the points you mentioned. I have a better idea now.

@isuruf mentioned that to_s is going to change in C++ layer soon, so I'll wait for that to happen. Until then, I'll show the number of rows and number of columns in inspect.

[rajithv]

@isuruf @abinashmeher999 @zverok ready for review.

@zverok I'm not too sure about the specs. Please advice if I'm not doing it right :)

[zverok]

Looking at it!

[zverok]

I've left some comments. Also, I am a bit concerned about the fact that only "happy path" is tested. What if I'll try to multiply DenseMatrix by string or nil? Would there be an informative exception? Would there be at least some exception (and not some nasty crash in the middle of C code). Testing behavior on failures and corner cases (for ex., behavior of empty matrices) could be tiresome, but without it we can't be sure code is actually working.