2015-12-27 2:49 GMT+01:00 Ben Coman <[email protected]>: > On Sun, Dec 27, 2015 at 6:13 AM, Nicolas Cellier > <[email protected]> wrote: > > > > > > 2015-12-25 2:03 GMT+01:00 Eliot Miranda <[email protected]>: > >> > >> Ben, > >> > >> _,,,^..^,,,_ (phone) > >> > >> > On Dec 4, 2015, at 12:49 AM, Ben Coman <[email protected]> wrote: > >> > > >> >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <[email protected]> > >> >> wrote: > >> >> > >> >> > >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <[email protected]>: > >> >>> > >> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe < > [email protected]> > >> >>> wrote: > >> >>>> > >> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <[email protected]> > >> >>>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <[email protected]>: > >> >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba < > [email protected]> > >> >>>>> wrote: > >> >>>>>> Hi, > >> >>>>>> > >> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <[email protected]> > wrote: > >> >>>>>>> > >> >>>>>>> @Doru > >> >>>>>>> You’re missing the point: #anyOne *fails* for empty collections. > >> >>>>>> > >> >>>>>> I am not missing the point at all. I am saying that if you want > >> >>>>>> sum: > >> >>>>>> to be generic, it cannot assume a specific Zero object. > >> >>>>>> > >> >>>>>> And sum: should be generic because of its name. > >> >>>>> > >> >>>>> I am missing understanding the other use cases. Can you describe > >> >>>>> further the generic nature of #sum & #sum: ? I would have thought > >> >>>>> by > >> >>>>> default they only applied to numbers. > >> >>>>> > >> >>>>> sum can be applied to anything that supports #+, not only numbers > >> >>>>> sum: can be applied to any collection with a block that return > some > >> >>>>> object that supports #+ > >> >>> > >> >>> To me this is a mis-application of polymorphism, that just because > >> >>> something responds to #+ it should be summable. We have overloaded > the > >> >>> semantics of #+ to mean both numeric addition and > >> >>> concatenation/membership, but technically "summation" relates only > to > >> >>> numeric addition. > >> >> > >> >> > >> >> I didn't wanted to argue for or against any change. I just wanted to > >> >> clarify > >> >> that there are situations in which a generic sum/sum: that throws an > >> >> error > >> >> on empty collections and don't assume a null value makes sense. > >> >> > >> >> > >> >>> > >> >>> > >> >>> https://www.google.com.au/search?q=define+sum&oq=define+sum > >> >>> > >> >>> > >> >>> > https://www.google.com.au/search?q=define+concatenate&oq=define+concatenate > >> >>> > >> >>> For example... > >> >>> > >> >>> * KMModifier implements #+ so what is the expected semantic of > " { > >> >>> KMModifier shift . KMModifier meta} sum " ? > >> >>> To me this is more of a concatenation/join/union facility rather > than > >> >>> numeric addition. (btw, that expression actually fails since > >> >>> KMModifier does not understand minus #- ) . > >> >>> > >> >>> * String implements #+ and " { '1' . '2' } sum " --> '3', so > >> >>> actually its doing numeric addition. However " { 'a' . 'b' } sum " > >> >>> produces an error. > >> >>> > >> >>> So actually there seem some existing problems with summing > >> >>> non-numerics. What examples work? > >> >>> > >> >>> * Trait classes implement both #+ and #- , but the semantic seems > >> >>> more to do with membership than numeric addition. I don't how how > to > >> >>> produce an example of using #sum against traits. > >> >>> > >> >>> * Points are summable " { 2@2 . 3@3 } " --> 5@5. But then " 2@2 > + > >> >>> 1 " --> 3@3 , so " {} sum " returning 0 would seem to not > >> >>> cause any error in this case. > >> >>> > >> >>> > >> >>> cheers -ben > >> >>> > >> >>> > >> >>>>> > >> >>>>> therefore you can not assume 0 (<- a number) is a proper initial > >> >>>>> value > >> >>>>> therefore you *need* to work with #anyOne > >> >>>>> and as you can not assume a proper initial value, you can not > assume > >> >>>>> a > >> >>>>> default value for empty collections > >> >>>>> -> it should throw an error. If you (the caller of the function) > >> >>>>> knows > >> >>>>> what to do with an empty collection you have > >> >>>>> to check, or call inject:into: directly, with a proper initial > >> >>>>> value. > >> >>>> > >> >>>> I am sorry but I am getting really tired of this, you should read > >> >>>> what > >> >>>> is being said. > >> >> > >> >> > >> >> do that change, I am not against it. Ben just asked for an example > and > >> >> I > >> >> thought it would be helpful. > >> > > >> > It was helpful :) It evolved my thinking. Now thinking further, I > >> > wonder how returning 0 will work with applications using units like > >> > Aconcagua, and if it would over-complicate things to do something > >> > like... > >> > > >> > Collection>>sum > >> > | sum sample | > >> > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > >> > sample := self anyOne. > >> > sum := self inject: sample into: [ :accum :each | accum + each > ]. > >> > ^ sum - sample > >> > > >> > ArithmeticZero class >> + anObject > >> > ^anObject > >> > >> surely you mean > >> > >> Collection>>sum > >> ^self inject: ArithmeticZero into: [ :accum :each | accum + each ] > >> > >> ArithmeticZero class >> + anObject > >> ^anObject > >> > >> and I'd optimise as > >> Collection>>sum > >> | sum | > >> sum := ArithmeticZero. > >> self do: [ :each | sum := sum + each ]. > >> ^sum > >> > >> But in with those that want an error and would use either > >> Collection>>sum > >> ^self inject: self anyOne species zero > >> into: [ :accum :each | accum + each ] > >> > >> or > >> > >> Collection>>sum > >> | sum | > >> sum := self anyOne species zero. > >> self do: [ :each | sum := sum + each ]. > >> ^sum > >> > > > > Not bad, but the class cannot allways determine the correct zero. > > For example Matrix is too generic and can't guess about dimensions which > are > > instance specific. > > So zero should be instance specific. > > So if "species zero" isn't good to implement summing, could we use it > to delegate raising an error. > For example, cases like Matrix where summing an empty collection > should produce an error, this could be done by ArithmeticZero > delegating to the second operand to raise the error there? > > ArithmeticZero >> + operand > operand species zero + operand > > Matrix class >> zero > ErrorZeroDoesn'tMakeSense new signal. > > ? > cheers -ben > > No, becauseItMakesSenseAtInstanceSide, I'd rather say it like this: if we want to adopt injecting zero into the sum, then let's make it an instance side message rather than class side. It's a rather elegant solution, but remember only for a minor problem: - That's only necessary for unordered Collection (since Sequenceable can just inject self first and start looping at index 2). - And that does not solve the case of empty collections which cannot use anyOne
Nicolas
