Yes, #(0 0 0) is the additive identity in *that* case.
But in #((1 2) (3 4) (5 6)) sum it is #(0 0).
And in #(((1 2 3) (4 5 6)) ((9 8 7) (6 5 4))) sum
==> #(#(10 10 10) #(10 10 10)) it is #((0 0 0) (0 0 0)).
I suppose you could have
SequenceableCollection>>zero
^self collect: [:each | each zero]
#(0 0 0) is the additive identity in that case
> On 25 Mar 2020, at 12:38, Richard O'Keefe wrote:
>
> There are situations where #+ and #sum make sense but there is no additive
> identity. Here is an example:
> #((1 2 3) (4 5 6) (7 8 9)) sum
>
> On Tue, 24 Mar 2020 at 02:46, James Foster wrot
There are situations where #+ and #sum make sense but there is no additive
identity. Here is an example:
#((1 2 3) (4 5 6) (7 8 9)) sum
On Tue, 24 Mar 2020 at 02:46, James Foster wrote:
>
>
> > On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe wrote:
> >
> > What you found out now is that the
What's wrong with this definition?
sum
"(1) This used to use #runsDo:, which can lead to big savings
on bags and runarrays, but we almost never use this method
on them, so it didn't pay off.
(2) The obvious initialisation to 0 doesn't work with a
co
Thanks for the git issue - and sadly this goes back a long way :(
I’ve added my example to the sad history… is there anyone that can rule on this?
> On 23 Mar 2020, at 21:23, Sven Van Caekenberghe wrote:
>
> https://github.com/pharo-project/pharo/issues/2225
>
>> On 23 Mar 2020, at 17:14, Tim
https://github.com/pharo-project/pharo/issues/2225
> On 23 Mar 2020, at 17:14, Tim Mackinnon wrote:
>
> I’m always impressed with the quality of answers that come out of these
> discussions - inevitably I’m reminded that dispatching off the right parties
> is ultimately where the power lies (w
I’m always impressed with the quality of answers that come out of these
discussions - inevitably I’m reminded that dispatching off the right parties is
ultimately where the power lies (when you cheat - it always seems to end up
with a gotcha).
Thanks guys.
Tim
> On 23 Mar 2020, at 15:15, Jame
> On Mar 23, 2020, at 8:14 AM, Sven Van Caekenberghe wrote:
>
> Both are excellent suggestions.
>
> We have to think a bit about the consequences.
>
> Still, both would not solve the problem of what to return when the collection
> is empty.
Zero?
>
>> On 23 Mar 2020, at 15:47, Konrad Hins
Both are excellent suggestions.
We have to think a bit about the consequences.
Still, both would not solve the problem of what to return when the collection
is empty.
> On 23 Mar 2020, at 15:47, Konrad Hinsen wrote:
>
> Am 23.03.20 um 14:45 schrieb James Foster:
>
>>> On Mar 23, 2020, at 6:0
Am 23.03.20 um 14:45 schrieb James Foster:
On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe wrote:
What you found out now is that the clever trick used to avoid picking an
additive identity (picking an element, counting it twice and then subtracting
it) leads to a loss of precision when fl
> On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe wrote:
>
> What you found out now is that the clever trick used to avoid picking an
> additive identity (picking an element, counting it twice and then subtracting
> it) leads to a loss of precision when floating point numbers are involved.
Like I said, we have had big discussions about this, I am not sure we want to
revisit them.
It is not just the problem that summing assumes the elements to be numbers
(whatever that it, let's say objects that can be added), it is also the
question what the additive identity should be (0 most wo
I’m interested in exploring this - partly because it hit me and wasted my time
chasing down why we have a difference in #sum from other languages. It seems
that the implementation is trying to be very clever - I guess from the generic
usage of collections which don’t have to contain only numbers
13 matches
Mail list logo
