A bit of prerequisite history:

1. "Assign variables/functions put into the vector/matrix" feature announced.

2. "Extracting submatrices using ranges as indices" feature requested.

3. Its implementation announced.

4. Question about putting a matrix into a submatrix posted.

Currently it's impossible to use assignments like this:



The proposal is to enable such syntax.

I understand the code you are proposing, but wonder if useful.
It would be local anyway, which Smath has it already.

1. What I propose can be seen as "syntactic sugar". As such, it is not strictly *required*, but desirable.
2. Also, this proposal enables syntax that seem "natural" based on previous enhancements (cited in the first post). It improves consistency and discoverability (intuitivity) of features.
3. It enables syntax known from MathCad. This is again not a requirement, but lowers learning curve for newcomers.

All talk about "unneeded features" on the basis that the feature *may be* implemented using programming is bullshit. Yes, you can, and actually you even don't need SMath for this, only abacus being Turing-complete. So what? Let's call SMath not needed, and spend time on reinventing wheels, or searching for wheels someone had implemented before, and then spend time on debugging because when you took someone else' code, you didn't see that that code used "foreign" concept of MathCad zero-based indices? Or difficult-to-find bugs in edge cases?

You may only call a proposal not needed, if it makes software *worse* in some sense. E.g., has a different paradigm and thus makes interface inconsistent.

Developers may decide not to implement useful features, because they may percept it to be too difficult to implement compared to possible benefit (so their time would be better spent for other tasks), or it may be impossible in used architecture, or something. Then't OK. But that's another story.

There also exists the following, for some, more substantial need:
4. Speed. In-built functions involving mass operations like vectorize() or this one may be optimized much better, and even use multi-processing (vectorizing) e.g. in GPU, thus parallelizing work manifold WRT functional approach. User functions in SMath, being greatest feature, are inherently slower than in-built/plugin.

You can improve your "syntactic sugar" even more practical, Mathcad style.
i:=1..n
j:=1..n
M[i,j :=Mandelbrot

Wrote

You can improve your "syntactic sugar" even more practical, Mathcad style.
i:=1..n
j:=1..n
M[i,j :=Mandelbrot

Started implementation of this feature in order to improve compatibility with other software:


Best regards, Andrey Ivashov.

Wrote

Started implementation of this feature in order to improve compatibility with other software:

Best regards, Andrey Ivashov.

Besides compatiblity to "other software" this will improve the readibility in comparison to the vectorize operator, which is not really clear to third party users.

Wrote

Started implementation of this feature in order to improve compatibility with other software:

Nice feature, Andrey ... keep up !
Vectorize operator works well.

Jean



Pattern Mandelbrot RGB.sm (57 KiB) downloaded 54 time(s).

Pattern Mandelbrot.sm (108 KiB) downloaded 60 time(s).