Even though we havenât been able to completely agree on the resolution, I feel we can agree that we need to change something. Iâve opened an issue and copied the messages from this thread into it for documentation. https://pharo.fogbugz.com/f/cases/17174/Unify-sum-sum-sumNumbers-and-detectS... Cheers, Max
On 01 Dec 2015, at 18:41, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 01 Dec 2015, at 17:43, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Dec 1, 2015, at 3:24 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Doru,
On 01 Dec 2015, at 15:11, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Dec 1, 2015, at 12:52 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 01 Dec 2015, at 12:45, Stephan Eggermont <stephan@stack.nl> wrote:
On 01-12-15 11:46, Sven Van Caekenberghe wrote:
The basic question for me is, what should
#() sum
return. Right now, it is an error, I would very much like that for this common case the result would be 0. There is a lot of power (easy of use) in a unary selector, we should not destroy that with semantics that force a test before using it.
I like the error, it aligns with most of our collection protocol.
I hate the error, a lot ;-)
It shows the need for #sum:ifEmpty: though
Yes, as long as #() sum == 0
That wonât work :).
Why ? Please explain.
I want the simplest case to be simple, having a non-0 default is a special case IMHO
That is why you have sumNumbers:. We could also add Collection>>sumNumbers.
We had this discussion at length before Pharo 4, and this is when we agreed to add sumNumbers: and let sum: be generic (like the name says it should be) and not assume that it should work with Numbers.
It is not about numbers or not, you are still using #+ in your generic case, that is numeric in my book. It is about the zero element and how to deal with an empty collection.
The current solution, which was indeed recently added, leaves the problem of what to do with an empty collection. There is no general solution, you have to specify a zero element.
Exactly.
But for most people in most cases that will be effectively 0, so lets make the unary #sum respect that. (And unary #sum will also work for non-empty non-zero based objects). The less common case can then use the longer message.
You said it correctly: âmostâ :). That is why, a generic meaning should be left generic and provide a solution that will work with âallâ cases :).
Itâs a matter of choice, but sum: has a too generic meaning to have it confined to numbers.
I think we all mean the same thing and understand each other's point.
But the first meaning of 'sum' in Wikipedia leads to https://en.wikipedia.org/wiki/Summation which talks about numbers. I studied partly Mathematics, so I know there are different numeric systems and abstractions. My point is: the common case is adding (simple) numbers, the special case is the more general one, hence the best selector, #sum, should work for the common case, including for the empty one.
Consider also Ben's link:
https://en.wikipedia.org/wiki/Empty_sum
Hence my suggestion to change #sum to
| sum sample | self isEmpty ifTrue: [ ^ 0 ]. sample := self anyOne. sum := self inject: sample into: [ :accum :each | accum + each ]. ^ sum - sample
And the same for #sum:
Note that the above *will* work for all like today, just not if they are empty. Now, of course we will need the ifEmpty: variants for what I consider the less common cases.
Can I also remark that both #inject:into: and #fold: are perfectly fine for more involved cases. We have a lot of API ;-)
Cheers, Doru
Cheers, Doru
Stephan
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
-- www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."