March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo float precision vs Python

by Sven Van Caekenberghe

Thanks for sharing, this is indeed something quite subtle. > On 20 Mar 2020, at 16:19, Tim Mackinnon <tim(a)testit.works> wrote: > > Actually I can answer my own question - its the difference between #sum and #sumNumbers (and an easy mistake to make - I almost wish that sum was the sumNumbers implementation and there was a sumSample that behaved like now) There was a *LOT* of debate about that (especially that #() sum isZero). I also would would prefer #sum to be like you describe. >> On 20 Mar 2020, at 14:52, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. >> >> I am curious why in Python adding these numbers: >> >> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 >> print(y) >> print(y / 15) >> >> Gives: >> >> 14832.682458496522 >> 988.8454972331015 >> >> In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. >> >> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. >> y. >> y / 15. >> >> >> Gives the same as Python. >> >> >> BUT: >> >> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. >> z. >> z / 15. >> >> >> Gives >> 14832.68245849652 >> 988.8454972331014 >> >> Is this correct? >> >> >

March 20, 2020

Re: [Pharo-users] Pharo float precision vs Python

by Tim Mackinnon

Actually this isnât quite so simple - as the problem outline below compounds itself by the use of #average (which uses #sum and not #sumNumbers) and thus gives a less precise answer. Why wouldnât #average use #sumNumbers inside? Or does there need to be #averageNumbers as a complement â¦. Argggg it makes my head hurt. Its important as we compare differently to python and this then makes us waste time. Tim > On 20 Mar 2020, at 15:19, Tim Mackinnon <tim(a)testit.works> wrote: > > Actually I can answer my own question - its the difference between #sum and #sumNumbers (and an easy mistake to make - I almost wish that sum was the sumNumbers implementation and there was a sumSample that behaved like now) > >> On 20 Mar 2020, at 14:52, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. >> >> I am curious why in Python adding these numbers: >> >> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 >> print(y) >> print(y / 15) >> >> Gives: >> >> 14832.682458496522 >> 988.8454972331015 >> >> In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. >> >> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. >> y. >> y / 15. >> >> Gives the same as Python. >> >> BUT: >> >> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. >> z. >> z / 15. >> >> Gives >> 14832.68245849652 >> 988.8454972331014 >> >> Is this correct? >> >> >

March 20, 2020

Re: [Pharo-users] Pharo float precision vs Python

by Tim Mackinnon

Actually I can answer my own question - its the difference between #sum and #sumNumbers (and an easy mistake to make - I almost wish that sum was the sumNumbers implementation and there was a sumSample that behaved like now) > On 20 Mar 2020, at 14:52, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. > > I am curious why in Python adding these numbers: > > y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 > print(y) > print(y / 15) > > Gives: > > 14832.682458496522 > 988.8454972331015 > > In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. > > y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. > y. > y / 15. > > Gives the same as Python. > > BUT: > > z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. > z. > z / 15. > > Gives > 14832.68245849652 > 988.8454972331014 > > Is this correct? > >

March 20, 2020

Pharo float precision vs Python

by Tim Mackinnon

Hi guys - I recall this came up a few months ago, but Iâm curious about the difference of Pharoâs use of Float64 vs Python - as I assumed that if languages use the same IEEE spec (or whatever spec it is) that simple stuff would be quite similar. I am curious why in Python adding these numbers: y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294 print(y) print(y / 15) Gives: 14832.682458496522 988.8454972331015 In pharo I have noticed an anomaly which I thought was precision but it may be something odd with iterators. y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 + 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 + 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 + 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 + 784.5488305664002 + 957.3522631840398 + 1001.7526196294. y. y / 15. Gives the same as Python. BUT: z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 . 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 . 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 . 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 . 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum. z. z / 15. Gives 14832.68245849652 988.8454972331014 Is this correct?

March 20, 2020

Re: [Pharo-users] Slots vs collections

by Richard Sargent

On Fri, Mar 20, 2020, 06:53 Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Thanks Julien. So, what I did experienced is because BooleanSlot is work > in progress. > To address my issue using slots, I guess collections should implement > asBit method (Sent by BooleanSlot). > Noury, when modelling something like this, think whether "all collections should implement asBit". I've added the word all, of course. There are so many possible collections for which #asBit wouldn't make sense that I would conclude the hypothesis to be incorrect. Even if you were to implement it on a single collection class, such as Array, there are still so many examples where #asBit could not apply. Perhaps, there could be an e.g. Bits class in the Collection hierarchy. But, even then, it seems to me that there are so many inherited methods that wouldn't make sense. What would be the use of #do:? What would #select: mean? You get the idea. An alternative possibility, and not the only one, is to model the bits as part of an integer, small or large. Of course, for performance, a ByteArray might be a good way to store bits. It has the benefit that every instance *can* represent bits. But, the inherited API operates on the bytes, not the bits. Encapsulation may be the answer. e.g. a Bits object that holds a ByteArray and provides the API that is needed. That's a rather long answer, admittedly. > Noury > > > On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque(a)inria.fr> > wrote: > > > > Hello, > > > > There is a work in progress prototype slot named BooleanSlot in the > Slot-Example package built-in the image. > > > > I think this slot does what you want. > > > > So, the answer is yes, it is possible to do that. But you will need to > fix todos left in BooleanSlot methods. > > > > Julien > > > > Le 20/03/20 Ã 12:24, N. Bouraqadi a Ã©crit : > >> Hi, > >> > >> Suppose I have an instance variable referencing a collection of > booleans. > >> I want to have all elements of the collection be stored as bits. > >> Is there a way I can express it using slots? > >> > >> This idea can be generalized to other types of slots. > >> > >> Noury > >> > > > > >

March 20, 2020

Re: [Pharo-users] Slots vs collections

by Noury Bouraqadi

Thanks Julien. So, what I did experienced is because BooleanSlot is work in progress. To address my issue using slots, I guess collections should implement asBit method (Sent by BooleanSlot). Noury > On 20 Mar 2020, at 13:56, Julien Delplanque <julien.delplanque(a)inria.fr> wrote: > > Hello, > > There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image. > > I think this slot does what you want. > > So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods. > > Julien > > Le 20/03/20 Ã 12:24, N. Bouraqadi a Ã©crit : >> Hi, >> >> Suppose I have an instance variable referencing a collection of booleans. >> I want to have all elements of the collection be stored as bits. >> Is there a way I can express it using slots? >> >> This idea can be generalized to other types of slots. >> >> Noury >> >

March 20, 2020

Re: [Pharo-users] Best ways to retrieve JSON objects from a feed?

by Sven Van Caekenberghe

> On 20 Mar 2020, at 14:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > And a very simple one: > > ZnClient new > forJsonREST; > get: 'https://api.ipify.org?format=json'. Here is another cool example: ZnClient new forJsonREST; get: 'https://ip.seeip.org/geoip'.

March 20, 2020

Re: [Pharo-users] Best ways to retrieve JSON objects from a feed?

by Sven Van Caekenberghe

Hi Tim, Sure this is possible (with the latest Zn of course): ZnClient new forJsonREST; url: 'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr'; addPath: { '20190101'. '20191231'. #bel }; get. I do not know how to use this API to get actual data, but the above succeeds with an empty JSON result. If you study #forJsonREST you should be able to figure out how this is done. Here is another example (from the unit tests): ZnClient new forJsonREST; url: 'http://easy.t3-platform.net/rest/geo-ip'; queryAt: 'address' put: '81.83.7.35'; get. And a very simple one: ZnClient new forJsonREST; get: 'https://api.ipify.org?format=json'. Note that the result depends a bit on whether NeoJSON is loaded or not (the fallback is to use STONJSON which is always present in the image). HTH, Sven > On 20 Mar 2020, at 14:14, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi everyone, Iâm finally finding some space from world chaos and looking more into Pharo, and I have a question about retrieving json data from feeds - how is the best way to elegantly parse it - e.g. > > I am doing : > > url := ZnUrl fromString: 'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr…. > url addPathSegments: {aDate1 asString. aDate2 asString. aCountryCode}. > result := ZnEasy get: url. > content := STONJSON fromString: result contents. > ... > > However I was kind of surprised there wasn't something on a ZnResponse for getting json objects e.g. > result getJsonObjects > > or something like that? > > Itâs so common I wonder if I am missing some trick? What arenât there helpers in place for this or is there a better way to do this that I havenât found yet? > > > I was kind of thinking something like (which obviously I can add myself) > > result asJsonObjects sum: [:obj | (obj at: âannualDataâ) first ] > > Tim

March 20, 2020

Best ways to retrieve JSON objects from a feed?

by Tim Mackinnon

Hi everyone, Iâm finally finding some space from world chaos and looking more into Pharo, and I have a question about retrieving json data from feeds - how is the best way to elegantly parse it - e.g. I am doing : url := ZnUrl fromString: 'http://climatedataapi.worldbank.org/climateweb/rest/v1/country/annualavg/pr…. url addPathSegments: {aDate1 asString. aDate2 asString. aCountryCode}. result := ZnEasy get: url. content := STONJSON fromString: result contents. ... However I was kind of surprised there wasn't something on a ZnResponse for getting json objects e.g. result getJsonObjects or something like that? Itâs so common I wonder if I am missing some trick? What arenât there helpers in place for this or is there a better way to do this that I havenât found yet? I was kind of thinking something like (which obviously I can add myself) result asJsonObjects sum: [:obj | (obj at: âannualDataâ) first ] Tim

March 20, 2020

Re: [Pharo-users] Slots vs collections

by Julien Delplanque

Hello, There is a work in progress prototype slot named BooleanSlot in the Slot-Example package built-in the image. I think this slot does what you want. So, the answer is yes, it is possible to do that. But you will need to fix todos left in BooleanSlot methods. Julien Le 20/03/20 Ã 12:24, N. Bouraqadi a Ã©critÂ : > Hi, > > Suppose I have an instance variable referencing a collection of booleans. > I want to have all elements of the collection be stored as bits. > Is there a way I can express it using slots? > > This idea can be generalized to other types of slots. > > Noury >

March 20, 2020