Wrote

Wrote

The only thing that remotely comes to mind is that M, being defined within the program structure as M:=Mo, is not having to read for the variable from the outside.
Have you, or anyone else, tried this on other programs?

What's wrong or incorrect in there is length it shouldn't exist in Smath

Hi Jean. Of course that it exists: length(M):=rows(M)*cols(M).

The matrix is square 75x75. In your image you only execute the function for the first 75 values of M and not the 75x75 = 5625 values.

The program also makes use of SMath's ability to access the elements of a two dimensional array by means of a single index because it is more compact, since it requires only one loop.

For small matrices it seems that there are not difference between "the M=M" version and the other. It's just for big ones, whatever big means.

Best regards.
Alvaro.

Nearly every function I use with a matrix M as argument starts with |M#:=M

A long time ago I stopped wondering why that's such a immense advantage in speed and just accepted it like it is.

Wrote

Hi Jean. Of course that it exists: length(M):=rows(M)*cols(M).

Thanks Alvaro for correcting my gross mistake.
The slow module can be improved "Unwrap", maybe valid otherwise.
Take care ... Jean

Maths eval(,) TEST.sm (18 KiB) downloaded 51 time(s).

Wrote

Originally Posted by: ndtma [url=/forum/yaf_postsm67582_Advantage-of-vectorize-function.aspx#post67582][/url]Revised program to handle date strings.

Thanks Collab for that most useful work.
Saved ... for future use.
Cheers ... Jean

Thank you Jean for the kind and encouraging comments.
Take care.

Good morning,
Why the practice of using the program line when defining single variables like f(M):=|norme(M)? If you redefine it without the "program line" f(M):=norme(M), it speeds it up a little. I ask because I've seen other users do this without understanding the rationale. EvalTestRS1.sm (19 KiB) downloaded 48 time(s)..

In addition, I can't recall how to add a program line in the middle of a program. At the moment, I'm stretching the grip down and physically moving items which is not optimal.

Wrote

In addition, I can't recall how to add a program line in the middle of a program. At the moment, I'm stretching the grip down and physically moving items which is not optimal.

Elsid, you better have an example to crunch !
We can do what we want and much more.
Local definition often works well, for Legendre: a must
Snow up there but mild ... Jean.

Wrote

Good morning,
Why the practice of using the program line when defining single variables like f(M):=|norme(M)? If you redefine it without the "program line" f(M):=norme(M), it speeds it up a little. I ask because I've seen other users do this without understanding the rationale. EvalTestRS1.sm (19 KiB) downloaded 48 time(s)..

In addition, I can't recall how to add a program line in the middle of a program. At the moment, I'm stretching the grip down and physically moving items which is not optimal.

use ","

Wrote

Why the practice of using the program ... line

The single place holder program line you are talking about is the
Smath local definition ... to get it: ] delete 2nd place holder.
De Boor is the most demonstrative example.
Cheers ... Jean

Spline De Boor [Colibri].sm (34 KiB) downloaded 56 time(s).

Wrote

The single place holder program line you are talking about is the Smath local definition ...

Why use it? In the sample file I attached, based on Alvaro's file, it actually slowed down the calculation a little. I've tried this on other files too.
Why do you use it?

Wrote

Good morning,
Why the practice of using the program line when defining single variables like f(M):=|norme(M)? If you redefine it without the "program line" f(M):=norme(M), it speeds it up a little. I ask because I've seen other users do this without understanding the rationale. EvalTestRS1.sm (19 KiB) downloaded 48 time(s)..

Hi ElSid. I see your yellow lines in the file, and it's true, it's faster without line(norme(M))

(If you don't know, you can copy an equation in smath and paste it in a text area or text editor to see it's structure, like line(), mat(), etc.)

Well, in my personal case, I use line() because ... well, I forgot why, but I use that since this 8 years old post (I'm adiaz there): https://en.smath.com/forum/yaf_postsm7966_Function-as-a-program.aspx#post7966

Making memory if I go to define some "utility" I try to use line always. Maybe because you can use 1*line() for convert that into a non-line function but that's a poor argument. Another reason could be that if you have something very simple, let's say norme(v):=sqrt(dot(v*transpose(v))) and later you need to modify that for some more complex, in such case usually you can avoid the use of line(), and as you can see the SMath behavior could be a little different in that case. Using always line() you can prevent surprises later. I reserve f(x):=formula just for "working" functions, expected to be always simple expressions.

As you can see in that post there are an issue in SMath about "local" and "global" variables. Functions with / without line() could have different behavior respect to those kind of variables in a procedure. Some users use x# as arguments and local variables in procedures, I try also to use unicode characters, but my opinion about that is that the better solution is a local() command for ensure true local variables.

Wrote

In addition, I can't recall how to add a program line in the middle of a program. At the moment, I'm stretching the grip down and physically moving items which is not optimal.

Recently Viacheslav post about some user's tutorial videos in youtube about smath. Maybe that can help better than written instructions.

Best regards.
Alvaro.

Wrote

I ask because I've seen other users do this without understanding the rationale.

The rationale of Smath is that it is essentially a plugin system.
Then not like Mathcad a semi-compiled system.
There is no rule for eval(,), just best timing, or simply working or not.
The local definition is a much different story, dictated from error message.
Some use f(#), I don't ... more intuitive f(■)
That is not a fixed rule, it depends upon the algo involved.
Cheers ... Jean

Algo Styles.sm (20 KiB) downloaded 54 time(s).

Vectorize function on Nested Array revisited.

Cheers!