operations between jagged arrays and scalars

[dvd101x]

Hi, this is the proof of concept discussed at #3537

It's more inline with what Jos and Glen suggested as my initial idea was flawed. This PR only shows two main changes.

• refactors matAlgo14xDs to use it's DenseMatrix map method and includes a hack to make the matrix creation faster.
• makes a new matAlgo15xAs to map arrays that can be jagged or non homogeneous and there is no need to convert to matrix and then back to array.

My expectation is that all operations between Matrix|Array and scalar should be faster.

The new functionality is that it's possible to do stuff like

math.add([1,[2,3]], 1)

math.config({matrix:"Array"})
math.evaluate("[1,[2,3]] + 1")

[josdejong]

Nice! This actually simplifies the code since you can "just" use the map function.

What are the next steps? Add some unit tests for jagged inputs, update docs, and see what the performance impact is?

[dvd101x]

Yes exactly, I will proceed with the next steps in the following weeks.

Maybe later I will come back to broadcasting jagged arrays.

[gwhitney]

Excellent, this is shaping up. A few more things to consider.

[dvd101x]

After including benchmarks, there is a big benefit of not converting arrays to matrices and small benefit of using the DenseMatrix.map method.

[dvd101x]

Hi, all comments are addressed either in code or as a reply. This is ready for review again.

[gwhitney]

Should this say "Deeply iterates over the given Array" or something like that to make it clear that it is not just calling f(a, b) for each (direct) entry a of A? Just a thought, either change or let me know you think it's OK as is.

[gwhitney]

Now we come to the difficulty that at this point, PRs are supposed to have per-function HISTORY for the functions they touch. I had hoped to get one of my PRs that touches a lot of functions to the point of going in to alleviate this big task before anyone else, but with the rate that Jos can review things and by other coincidences it seems as though you are getting there first. How would you like to handle this? Might we split up the chore of inserting such histories for the functions touched in this PR? Let me know your thoughts.

[dvd101x]

Most of the functions touched in this PR were due to the removal of concat.

I've been reviewing the history and this is mostly my fault as I did include them at #2895 because it was needed but then it should have been removed at #3220.

Please help me with an example of the history and I can gladly replicate it in the functions where concat was removed as a dependancy.

We could split the rest.

[gwhitney]

Please help me with an example of the history and I can gladly replicate it in the functions where concat was removed as a dependency.

A good current example is src/expressions/parse.js. Note that I do try to make the histories be from inception. The command git log --follow -- filename is super helpful for that as it tracks the files across renames as well -- some of the function implementations previously lived in different subdirectories, for example.

We could split the rest.

Yes, that would be absolutely fine. Please just let me know which functions are "assigned" to me and when is a good time for me to work on them that I can push a commit to this PR without interfering with your work. Thanks!