To discuss appeared issue I copying our e-mail log with ing.sosa.

Wrote

Im using Smath in my Numeric Analysis course, and found an issue with the Summatory arguments... when programming some algorithms we usually need to define summatorys using variable index, and we're getting errors when having, in example, summatorys from 1 to 0... of course we dont spect the summatory to do nothing, but it would be useful if this kind of definition of the arguments doesnt cause an error, because in the next iterations the same summatory will be from 1 to 1, then from 1 to 2, ... and then from 1 to n

Wrote

Issue you're talking about is fixed now (see attached image). Next version of SMath Studio (0.90) will correctly work with summatory arguments from your case.

Wrote

This solution is very useful for most cases, i guess, but my problem was not tryng to sum backward, only not to get an error but not iteration to happen. I'm attaching an example.

Anyway, this issue can be solved introducing some programming lines in our files... not big deal... but thinking in a good improvement to your soft, maybe would be a great solution introducing the notation proposed at the end of the .sm file i'm sending.

File attached: sum_example.sm

---

I've investigated the issue more carefully and here is what I've got:

where a = 7 (bottom limit) and x is ranged variable.

For now it seems that Maple solution is the best, but I can't find any information about the 100% right one. Can anyone help with this? What is the right decision to implement functionality when bottom limit of the sum(..) function is larger then the top one?

Best regards, Andrey Ivashov.

Hello,

I do not know what is right but do not mind if the next SMath release will implement the summation and product operation to work as Andrey described - lower limit might be greter than the upper - the same as in Mathcad and Mathematica.
On the other hand we can supress some elements in the sumation and products this by using "if" function. As explained, at the moment this will do the job about lower limit higher then the upper.
[MATH=eng]s1(x,a)←if(x>a,0,sum(k,k,x,a))[/MATH]
[MATH=eng]s1(3,5)=12[/MATH]
[MATH=eng]s1(5,3)=0[/MATH]

I think this would be Ok and, to be honest, do not understand what is behind Maple solution.

Regards,
Radovan

P.S. I was thinking about having another sum and product operators with the additional step argument. At the moment it is
[MATH=eng]product(el(c,i),i,a,b)[/MATH]
At the moment "a" must be lower than "b" and the step equals to unity (1). If the position of "a" and "b" would not be important (as Andrey said that might be introduced in 0.9) again from "a" to "b" or from "b" to "a" step will be 1 or -1. What about to have an additional argument after "a", say lower limit to be (i=a,a+2) and the value of "i" will take valuse {a,a+2,a+4..) etc. This is closer to the Math notation. Mathcad's ancient sum and product operators (this is still present) uses the sum and product operator with only one limit - a range variable.
Moreover, the step might be unity by default. If the upper limit is smaller than the lower limit - error will be reported. Then, If you still want to sum backward you have to put (i=a,a-1). This way some errors will be easyer to track.

Of course, all of this can be done with "for" loop.
Just my thoughts.

I think in a similar way that Radovan... in my file i was talking about backward and forward sum functions, but maybe an optional "step" variable will give full compatibility with older sm files, cause by default the step is +1.

The only important thing -in my opinion- is no getting errors when trying to sum forward from 5 to 4 (ie) or sum backward from 4 to 5... in this cases, no iteration must occur, so the result of the sum needs to be 0. When doing productory, the logic can be the same, not error but 0 result...

Thanks,