December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Sun, Dec 27, 2015 at 6:13 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2015-12-25 2:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Ben, >> >> _,,,^..^,,,_ (phone) >> >> > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: >> > >> >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> >> wrote: >> >> >> >> >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> >>> wrote: >> >>>> >> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> >> >>>>> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >> >>>>> wrote: >> >>>>>> Hi, >> >>>>>> >> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> 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

Dec. 27, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Nicolas Cellier

2015-12-25 2:03 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Ben, > > _,,,^..^,,,_ (phone) > > > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> > >> > >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >>> > >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > >>> wrote: > >>>> > >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> > >>>>> wrote: > >>>>>> Hi, > >>>>>> > >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> 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. Nicolas

Dec. 26, 2015

Re: [Pharo-dev] VM error in Arch Linux

by SaÅ¡a JaniÅ¡ka

On Uto, 2015-12-22 at 11:56 +0100, Ferlicot D. Cyril wrote: > Since last week a new VM is use for Pharo 5 beta. Beginning Pharo user here...I had the same problem on my Debian box: "This interpreter (vers. 6505) cannot read image file (vers. 6521)." > You need to download the new VM on http://files.pharo.org/vm/pharo-spu > r32/. Then I downloaded the new VM image and tried to use it with latest Pharo Launcher ('Bleeding Edge'), but now I get: "This interpreter (vers. 6521) cannot read image file (vers. 6505)."Â which is kind of catch-22 situation... > Then you need to update Pharo Launcher. ...and it looks that I do not have updated Pharo Launcher. > For now the easiest way I think is to enable the development mode in > PharoLauncher, go in Monticello, and load the last version of Pharo > Launcher core. Tried that as well, but didn't work. > Later I think that a new release of Pharo Launcher will make thing > easier. Let me say that the potential of Pharo Launcher is really great - it allows (if I got it right) to have many development machines available via different VMs, while still keeping developer's machine in sane state which cannot be said when one does regular development with other (mostly compiled) languages, which is "simply wonderful!". Now I wonder if you can provide any further hint how to resolve the above? Is there a plan that in the future Pharo Launcher will become regular part of 'normal' Pharo image? I know that probably there would be more luch with V4.0, but I simply would like to try latest code eagerly anticipating the day to try 64bit VM. Still, kudos to all Pharo devs for providing human development environment in the days when things are going insane all around us. Sincerely, Gour -- As a lamp in a windless place does not waver, so the transcendentalist, whose mind is controlled, remains always steady in his meditation on the transcendent self.

Dec. 26, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Max Leske

> On 25 Dec 2015, at 23:27, stepharo <stepharo(a)free.fr> wrote: > > Thanks sven. > PS: the flight did not take off... we are still in Togo. > Merry christmas! > Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >>> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi sven >>> >>> I missed the scenario. >> I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. >> >> In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. >> >>> Stef >>> >>> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>>> Hi, >>>> >>>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>>> >>>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>>> >>>> === >>>> Name: STON-Core-SvenVanCaekenberghe.64 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:50:14.195912 pm >>>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>>> >>>> Added the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> Name: STON-Tests-SvenVanCaekenberghe.59 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:51:06.830762 pm >>>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>>> >>>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> >>>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>>> >>>> Sven >>>> >>>> >>>> >>> >> >> > >

Dec. 26, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Sven Van Caekenberghe

> On 25 Dec 2015, at 23:27, stepharo <stepharo(a)free.fr> wrote: > > Thanks sven. > PS: the flight did not take off... we are still in Togo. X-mas in the airport then ? It is amazing what you are doing for Pharo ! > Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >>> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi sven >>> >>> I missed the scenario. >> I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. >> >> In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. >> >>> Stef >>> >>> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>>> Hi, >>>> >>>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>>> >>>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>>> >>>> === >>>> Name: STON-Core-SvenVanCaekenberghe.64 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:50:14.195912 pm >>>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>>> >>>> Added the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> Name: STON-Tests-SvenVanCaekenberghe.59 >>>> Author: SvenVanCaekenberghe >>>> Time: 23 December 2015, 10:51:06.830762 pm >>>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>>> >>>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>>> === >>>> >>>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>>> >>>> Sven >>>> >>>> >>>> >>> >> >> > >

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by stepharo

Thanks sven. PS: the flight did not take off... we are still in Togo. Le 25/12/15 20:44, Sven Van Caekenberghe a Ã©crit : >> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: >> >> Hi sven >> >> I missed the scenario. > I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. > > In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. > >> Stef >> >> Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >>> Hi, >>> >>> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >>> >>> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >>> >>> === >>> Name: STON-Core-SvenVanCaekenberghe.64 >>> Author: SvenVanCaekenberghe >>> Time: 23 December 2015, 10:50:14.195912 pm >>> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >>> Ancestors: STON-Core-SvenVanCaekenberghe.63 >>> >>> Added the ability to write and read Class and Metaclass instances using their global name >>> === >>> Name: STON-Tests-SvenVanCaekenberghe.59 >>> Author: SvenVanCaekenberghe >>> Time: 23 December 2015, 10:51:06.830762 pm >>> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >>> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >>> >>> Added unit test for the ability to write and read Class and Metaclass instances using their global name >>> === >>> >>> Thanks to Norbert Hartl for requesting the feature and for test driving it. >>> >>> Sven >>> >>> >>> >> > >

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by Sven Van Caekenberghe

> On 25 Dec 2015, at 13:35, stepharo <stepharo(a)free.fr> wrote: > > Hi sven > > I missed the scenario. I guess some people sometimes store a class in some instance variable of a model class, maybe for configuration. In that case STON would not work before, now it does. In theory, STON can serialise any class without further configuration, but not classes that contain deeply nested/linked/os system objects. > Stef > > Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : >> Hi, >> >> In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. >> >> So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. >> >> === >> Name: STON-Core-SvenVanCaekenberghe.64 >> Author: SvenVanCaekenberghe >> Time: 23 December 2015, 10:50:14.195912 pm >> UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb >> Ancestors: STON-Core-SvenVanCaekenberghe.63 >> >> Added the ability to write and read Class and Metaclass instances using their global name >> === >> Name: STON-Tests-SvenVanCaekenberghe.59 >> Author: SvenVanCaekenberghe >> Time: 23 December 2015, 10:51:06.830762 pm >> UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca >> Ancestors: STON-Tests-SvenVanCaekenberghe.58 >> >> Added unit test for the ability to write and read Class and Metaclass instances using their global name >> === >> >> Thanks to Norbert Hartl for requesting the feature and for test driving it. >> >> Sven >> >> >> > >

Dec. 25, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Henrik Nergaard

Like this? http://smalltalkhub.com/#!/~Latsabben/NumIt Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: Thursday, December 24, 2015 9:58 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: Just a remark. I think that we discarded the proposition of having aCol arithmetic sum but I found it nice because there if was clear that you want to get back 0 for #(). Stef

Dec. 25, 2015

Re: [Pharo-dev] Dealing with Class and Metaclass instances when using STON

by stepharo

Hi sven I missed the scenario. Stef Le 23/12/15 23:04, Sven Van Caekenberghe a Ã©crit : > Hi, > > In STON #bleedingEdge I added the ability to write and read Class and Metaclass instances by using their global name. > > So, Point will be written as Class[#Point] while Point class will be written as Metaclass[#Point]. This is of course a short-circuit solution for the complex structure that a class actually is, but a reasonable compromise. It is in any case better than not handling these types of instances, which was the case before. > > === > Name: STON-Core-SvenVanCaekenberghe.64 > Author: SvenVanCaekenberghe > Time: 23 December 2015, 10:50:14.195912 pm > UUID: b7ced20a-a7a4-4b0f-8f27-db73231eeecb > Ancestors: STON-Core-SvenVanCaekenberghe.63 > > Added the ability to write and read Class and Metaclass instances using their global name > === > Name: STON-Tests-SvenVanCaekenberghe.59 > Author: SvenVanCaekenberghe > Time: 23 December 2015, 10:51:06.830762 pm > UUID: 9f684bc1-45e1-4bfa-885b-c56ea178bfca > Ancestors: STON-Tests-SvenVanCaekenberghe.58 > > Added unit test for the ability to write and read Class and Metaclass instances using their global name > === > > Thanks to Norbert Hartl for requesting the feature and for test driving it. > > Sven > > >

Dec. 25, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Eliot Miranda

Ben, _,,,^..^,,,_ (phone) > On Dec 4, 2015, at 12:49 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Fri, Dec 4, 2015 at 4:23 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> 2015-12-03 14:48 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>> >>> On Wed, Dec 2, 2015 at 10:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>>> >>>>> On 02 Dec 2015, at 15:21, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> 2015-12-02 15:03 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >>>>> On Wed, Dec 2, 2015 at 12:38 AM, Tudor Girba <tudor(a)tudorgirba.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>>> On Dec 1, 2015, at 5:13 PM, Max Leske <maxleske(a)gmail.com> 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 > > cheers -ben > >> >> >>> >>>> >>>> I am not suggesting to stop using #anyOne because I like why it is there >>>> and what it can do. >>>> >>>> The change I want is what happens with an empty collection when using >>>> the simplest selector, #sum. >>>> >>>> I do not want to say to some collection of numbers #sumIfEmpty: [0], >>>> because summing numbers starting from zero is the most common case and >>>> everybody expects that, hence the unary selector fits. >>>> >>>> I want the less common cases to use the more complicated API, as in some >>>> collection of colors #sumIfEmpty: [ Color black ] >>>> >>>> In my book that is common sense API design. >>>> >>>> Doing that I do no take anything away, because today you already have to >>>> make sure the collection is not empty. >>>> >>>> The only change would be in the error behaviour. I think that is a >>>> reasonable price to pay. Instead of having #anyOne fail, it will say that #+ >>>> cannot add 0 to some object, and in a comment we can point to the >>>> alternative API. >> >> >> >> >>> >>>> >>>> http://izquotes.com/quote/242740 right ? >>>> >>>>> cheers -ben >>>>> >>>>>> >>>>>>>> On 01 Dec 2015, at 15:31, Esteban A. Maringolo >>>>>>>> <emaringolo(a)gmail.com> wrote: >>>>>>>> >>>>>>>> I don't want to be heretic (or too orthodox), but why not to >>>>>>>> delegate >>>>>>>> this behavior to other class (an iterator maybe?). >>>>>>>> >>>>>>>> It's too tempting adding these convenience methods to Collection >>>>>>>> and/or subclasses, but anything that requires an explicit protocol >>>>>>>> of >>>>>>>> its elements is wrong, IMO. >>>>>>>> >>>>>>>> something like aCollection arithmetic sum: [...] or.... aCollection >>>>>>>> arithmetic avg. > > > On Fri, Dec 4, 2015 at 3:26 AM, Chris Cunningham > <cunningham.cb(a)gmail.com> wrote: >> <uncontrolled snipping> >> >>> On Thu, Dec 3, 2015 at 5:48 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> * 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. >> >> but points aren't commutative: >> >> 2@2 + 1 " = 3@3" >> 1 + 2@2 " = 3@2" >> >> Of course, 0 wouldn't be an issue, unless you wanted to access x or y! >

Dec. 25, 2015