BUG[?]: ΣLIST, ΠLIST with verrrry short lists

[chromos]

• ΣLIST doesn't work for lists with SIZE < 1. Does it work as intended? (ΣLIST of empty list should be 0);
• ΠLIST doesn't work for lists with SIZE < 2. Does it work as intended? (ΠLIST of empty list should be 1 and ΠLIST of list with one value should be that value).
  

[Claudio L.]

(12-23-2015 11:37 PM)chromos Wrote:  

• ΣLIST doesn't work for lists with SIZE < 1. Does it work as intended? (ΣLIST of empty list should be 0);
• ΠLIST doesn't work for lists with SIZE < 2. Does it work as intended? (ΠLIST of empty list should be 1 and ΠLIST of list with one value should be that value).
  

The first case is not a bug. Sum of an empty list is not defined, as the list could contain things other than numbers. Think of a list of strings, where the sum would concatenate them. In that case, an empty list should mean an empty string "", not the number zero.

In the second case, I agree the product of a 1-value list should be that value. An empty list is again a gray area. I think undefined answer is better than an arbitrary number 1.

[StephenG1CMZ]

To me, that the summation of a list of strings should concatenate them is not clear - speaking mathematically, I have always thought of summation returning a number rather than a string. Though of course in languages like PPL that concatenate using "+" I can see some logic in the parser considering that option. Not all languages use + to concatenate: Should those languages still concatenate when summing lists of strings (implying summation must behave differently to + for those languages).
If one does restrict summation to summing numbers, when given a string perhaps a language should sum the string lengths, although then it would consistent to use some other concatenation syntax, rather than "+".

Speaking practically, what does a summation of an empty list mean???
If I have a simple program listing how many presents I got from Santa from each friend, it would be convenient to have that program treat an empty list as a 0 (which will hopefully change soon), without having to add a check that the list is nonempty.

Code:

EXPORT SANTA()
BEGIN
  LOCAL PRESENTS:={};
  IF ΣLIST(PRESENTS)=="SANTA ERROR: INVALID DIMENSION" THEN
   MSGBOX("SANTA IS STUCK IN THE CHIMNEY")
  END;
END;

But if I have a program collecting data from a data stream counting meteors, an empty list rather than a count of 0 should return a NaN... We don't know the number because the equipment failed - either because of a flat battery, or because it got destroyed by a bigger meteor than it can count.
(Update: Actually, it depends on the data you are expecting: If you expect a 1 in the data stream for each detection, an empty list represents 0 meteors. If you expect the data stream to ccontainthe number of meteors each minute, an empty list represents either an equipment fault or you haven't yet run it for a minute)
So in practical terms, its not clear what summation of an empty list should return. But it should return a sensible value like 0 or NaN or NULL LIST or NULL STRING, not " Invalid dimension" , which sounds like a program or spacetime failure, not a simple data collection delay in a working program.

[chromos]

(12-24-2015 03:08 AM)Claudio L. Wrote:  ... The first case is not a bug. Sum of an empty list is not defined, as the list could contain things other than numbers. Think of a list of strings, where the sum would concatenate them. In that case, an empty list should mean an empty string ""...

In the second case, I agree the product of a 1-value list should be that value. An empty list is again a gray area. I think undefined answer is better than an arbitrary number 1.

You are right. I was thinkink about numbers only which was my mistake.

[DrD]

(12-24-2015 08:10 AM)StephenG1CMZ Wrote:  Speaking practically, what does a summation of an empty list mean???

So in practical terms, its not clear what summation of an empty list should return. But it should return a sensible value like 0 or NaN or NULL LIST or NULL STRING, not " Invalid dimension" , which sounds like a program or spacetime failure, not a simple data collection delay in a working program.

The help description for both ΣLIST, and ΠLIST involve "all elements in a list." Restricting a list to the point where its dimension is less than enough to perform the operation, makes the dimension of that list invalid. "Invalid dimension" seems appropriate, to me.

Merry Christmas everyone, and happy calculating in the new year!

-Dale-

[Hlib]

With all these bugs it is possible to work on condition of grant of information from a developer. Or to remain on the favourite tested calculator without many bugs.

[StephenG1CMZ]

One can use invalid dimension, but the way I was thinking, anyone calling Summation expects a number - or if that cannot be produced, whether because of an index issue or an overflow, a NaN.

(I have never summed rather than concatenated strings, so I am presuming a numeric result...so that might be inappropriate for non-numeric summations).

Of course, unless one can detect the error and continue, it makes little practical difference - and makes simply returning 0 seem preferable.

One question: if one do do a summation of strings, can one also do a product of strings?!
Merry Xmas all.

[StephenG1CMZ]

On the Prime emulator I get a concatenation for the summation of two strings and a Bad argument error for a product of two strings, or a Delta of two strings.

[Claudio L.]

(12-24-2015 07:57 PM)StephenG1CMZ Wrote:  One can use invalid dimension, but the way I was thinking, anyone calling Summation expects a number - or if that cannot be produced, whether because of an index issue or an overflow, a NaN.

(I have never summed rather than concatenated strings, so I am presuming a numeric result...so that might be inappropriate for non-numeric summations).

Of course, unless one can detect the error and continue, it makes little practical difference - and makes simply returning 0 seem preferable.

One question: if one do do a summation of strings, can one also do a product of strings?!
Merry Xmas all.

I used strings because it was very clear as an example. If you like numbers, then think about a list of 3x3 matrices. If your code is expecting a 3x3 matrix as a result of the sum, then shouldn't the sum of an empty list return a 3x3 matrix filled with zeros? Returning a scalar 0 would make your code fail, so you'd have to consider the empty list as a special case.
Same thing for the product, it should return a 3x3 identity matrix.
In general, you'd have to return the zero vector of whatever vector space you are defining the addition on. But from an empty list given as an argument, the command has not enough information to provide that resulting zero vector.
It's more consistent to have the user trap the error and return whatever zero vector he needs, than trying to provide an answer that's only good for one particular case.
By the way, there's a very simple trick to avoid all this: simply append one extra element to the list, being the zero vector (or unity for the product).
Then an empty list will no longer be empty, and it will return the appropriate type and size of zero. For obvious reasons, the extra element won't alter the result of the summation or product when the list is not empty.

[roadrunner]

In home, ΣLIST({"abc"," ","def"}) returns: "abc def".
In cas it returns: "0abc def".

In cas ΣLIST({""}) returns: "0".
In home it returns: "".

Is all this intentional?

-road

[DrD]

In the spirit of Christmas, the universal set of life is "intentional," at some level. This would include its subset, containing the hp Prime and it's list operators.

-Dale-

[roadrunner]

Right again DrD. What I should have asked is, "Is this what the designers of the prime intended?"

Merry Christmas everyone.

-road

[StephenG1CMZ]

Thank you Claudio for your explanation. I found thinking about summing matrices rather than strings helpful and made the issues much clearer. And I like that trick.

[Claudio L.]

(12-25-2015 12:43 PM)roadrunner Wrote:  In home, ΣLIST({"abc"," ","def"}) returns: "abc def".
In cas it returns: "0abc def".

In cas ΣLIST({""}) returns: "0".
In home it returns: "".

Is all this intentional?

-road

Well, that looks more like a proof of Darwin's evolution theory, as opposed to the "Intelligent design" theory.
It's probably the product of some random (genetic) code mutation, just wait a couple more generations and your Prime will return the correct result.

[ttw]

I've been complaining about such behavior since the HP48 came out. I formerly used lists for fast computation. However, in many cases, I found that my programs would check for 0 or 1 length lists and take some action to keep the calculator's check for the same thing from stopping. Usually I did something like {0 0} + before summation or {1 1} + before multiplication. If the lists were longish (10+), this was still faster than looping.

[cyrille de brébisson]

Hello,

The home result of the sigma list with strings is definitely intentional.

I assume that the CAS result is not :-)

However, it is nice to see such issue bringing up the algo underneath!

Cyrille

[parisse]

Inside giac, sigma list is implemented by initializing a variable of type giac::gen to 0, then the elements of the list are added to the variable. 0 + a string converts 0 to the string "0" then concatenate the string, so in some sense the CAS behavior was predictable. I don't see any real interest in modifying this, sigma list is not intended for strings.