October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] roundTo: strange behavior

by Nicolas Cellier

2016-10-31 22:49 GMT+01:00 John Brant <brant(a)refactoryworkers.com>: > > On Oct 31, 2016, at 3:58 PM, Martin McClure <martin(a)hand2mouse.com> > wrote: > > > > (1.19 roundTo: (1/10))asFloat > > > > I should note that the final example *should* result in a Float without > > having to have #asFloat sent to it. Per ANSI and traditional Smalltalk > > practice, any operation where the receiver *or* the argument is a Float > > produces a Float. > > While ANSI says that the numbers should be converted using the default > conversion table, all of the Smalltalkâs that Iâve tried donât follow that. > Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer > this behavior over the ANSI behavior. > > > John Brant > Whatever result species, don't trust (aFloat roundTo: aFraction) too much, they have some chances to be inexact, except for trivial powers of two. Example: (1.105 roundTo: 1/100) -> (111/100) 1.105 < (1105/1000) -> true Though the number was smaller than exact tie (in decimal), it was rounded up. Indeed, the exact computations have a different opinion: (1.105 asFraction roundTo: 1/100) -> (11/10) That's why we must implement round: with exact computations...

Oct. 31, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

On 10/31/2016 02:49 PM, John Brant wrote: >> On Oct 31, 2016, at 3:58 PM, Martin McClure <martin(a)hand2mouse.com> wrote: >> >> (1.19 roundTo: (1/10))asFloat >> >> I should note that the final example *should* result in a Float without >> having to have #asFloat sent to it. Per ANSI and traditional Smalltalk >> practice, any operation where the receiver *or* the argument is a Float >> produces a Float. > > While ANSI says that the numbers should be converted using the default conversion table, all of the Smalltalkâs that Iâve tried donât follow that. Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer this behavior over the ANSI behavior. > Thanks for the information. GemStone answers a Float. Since Fractions are more general than Floats, there is indeed a good basis for arguing that this is one of the things that ANSI got wrong. Regards, -Martin

Oct. 31, 2016

Re: [Pharo-dev] [Seaside-dev] Build failures

by Sven Van Caekenberghe

It already got reported twice, there are issues for it, but so far no luck (i.e. no actual resolution). I would guess that before the linux os of the CI slaves ran in 32-bit, while now it got upgraded to 64-bit. CC-ing pharo-dev > On 28 Oct 2016, at 14:12, Johan Brichau <johan(a)inceptive.be> wrote: > > Does anybody have any idea why this is failing: > >> /pharo: line 11: <https://ci.inria.fr/pharo-contribution/job/Grease/PHARO=40,VERSION=stable,V…>: No such file or directory > > Did not look at it yet, but it seems like something changed on de CI server?? > > Johan_______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Oct. 31, 2016

Re: [Pharo-dev] roundTo: strange behavior

by John Brant

> On Oct 31, 2016, at 3:58 PM, Martin McClure <martin(a)hand2mouse.com> wrote: > > (1.19 roundTo: (1/10))asFloat > > I should note that the final example *should* result in a Float without > having to have #asFloat sent to it. Per ANSI and traditional Smalltalk > practice, any operation where the receiver *or* the argument is a Float > produces a Float. While ANSI says that the numbers should be converted using the default conversion table, all of the Smalltalkâs that Iâve tried donât follow that. Iâve tried Dolphin, VW, Pharo, & VAST, and all return fractions. I prefer this behavior over the ANSI behavior. John Brant

Oct. 31, 2016

Re: [Pharo-dev] roundTo: strange behavior

by Martin McClure

tl;dr: 1.2000000000000002 *is* the correct answer for 1.19 roundTo: 0.1. (1.19 roundTo: (1/10))asFloat gives a different answer because it's rounding to a multiple of exactly 0.1, not the Float nearest to 0.1. On 10/31/2016 08:35 AM, test wrote: > oops, make that original number 1.19 in the example. OK, so the examples are now 1.19 round: 1. 1.19 roundTo: 0.1. (1.19 roundTo: (1/10))asFloat I should note that the final example *should* result in a Float without having to have #asFloat sent to it. Per ANSI and traditional Smalltalk practice, any operation where the receiver *or* the argument is a Float produces a Float. Since 0.1 is not quite equal to 1/10, the correct answer may not be the same for the latter two examples. Whether you define #round: to be one or the other is an interesting question. I've learned the hard way not to trust the results from Smalltalk math libraries too far, so let's manually figure out what the correct answer is for each of these, and see if Pharo's doing it right. To start, every Float (ignoring infinities, NaNs, and subnormals) is (by definition) a Fraction constrained to have a numerator in the range [2**52..2**53) and a denominator that is a power of two. Pharo says: 0.1 asFraction ==> (3602879701896397/36028797018963968) Is this correct? The numerator is less than 2**52, so this Fraction has been reduced. Let's restore it to what it would be in its Float form by multiplying numerator and denominator by, in this case, 2: 7205759403792794 ----------------- 72057594037927936 It's easy to see that this fraction is very nearly equal to 1/10, and to see that there could be no Float closer to 1/10. --- But I haven't shown the conversion from the string '0.1' to the actual Float instance is correct. It's possible that there's some rounding error there, which is reversed by a rounding in a different direction by the #asFraction. The Float for '0.1' is two words with values, 1069128089 and 2576980378. Convert to hex and combine them, you get 16r3FB999999999999A The numerator of our fraction is the low-order 52 bits of this, with a 1 added on the most-significant end, so 16r1999999999999A, which in decimal is 7205759403792794. Which is what we got above, so we're good so far. ======== Doing the same analysis on 1.19 gives a numerator of 16r130A3D70A3D70A, and a denominator 1/16th the previous one, or 5359283556570890 ---------------- 4503599627370496 This one's harder, I can't just look at it and say it's the closest possible to 1.19. But we know that 1.19 = 119/100. 119/100 * 4503599627370496/4503599627370496 = 535928355657089024 ------------------ 450359962737049600 and is still exactly 1.19. But to make a representable Float we have to divide numerator and denominator by 100, rounding the numerator if necessary. And we can see that the numerator is correctly rounded, so Pharo also converts the string '1.19' into a Float correctly. How does Pharo do on 1.19 asFraction? (2679641778285445/2251799813685248) Once again, this has been reduced by dividing numerator and denominator by two, but it's numerically correct. ====== Now that we know that we have the correct Fractions for the floats, we can check the rounding functions. 1.19 roundTo: 0.1 should ideally be equivalent to (1.19 asFraction roundTo: 0.1 asFraction) asFloat. In Pharo 5, 1.19 asFraction roundTo: 0.1 asFraction ==> (10808639105689191/9007199254740992) For this to correct, (10808639105689191/9007199254740992) must be a multiple of (3602879701896397/36028797018963968), since that's 0.1 asFraction. Is it a multiple? We can align the denominators by multiplying (10808639105689191/9007199254740992) by 4/4, and we get 43234556422756764 ----------------- 36028797018963968 which would be a multiple of 3602879701896397 ----------------- 36028797018963968 iff 43234556422756764 is a multiple of 3602879701896397. Looking at the original problem (1.19 roundTo: 0.1) we'd expect the multiple to be 12. Sure enough, 3602879701896397 * 12 ==> 43234556422756764. So we're correct so far. Now we have to convert our answer to the nearest representable Float. Our denominator is already a power of two, but our numerator is out of range -- it's too large. It's even, so we can cut it in half, getting 21617278211378382 Still too large, still even. Cut it in half again: 10808639105689191 Just a bit too large. Cut it in half again: 5404319552844595.5 Now it's in range [2**52..2**53) but it's not an integer, so we must round. Our number is exactly halfway between two representable numbers, so by IEEE754 we round to the even one, which is 5404319552844596 The Float we get back from 1.19 roundTo: 0.1 is 16r3FF3333333333334 and the numerator part of that is 16r13333333333334, or 5404319552844596 Which agrees with what we computed before. So this *is* the correct Float result. And it prints as 1.2000000000000002. This print string implies that there is a Float nearer to 1.2 than this. 1.2 is represented as 16r3FF3333333333333, so one representable Float less than the result of the #roundTo:. But, as we've shown, 1.2000000000000002 is *correct*. (Which was not what I expected when started this -- I suspected there might be rounding error in the computation of #roundTo:. But for this example, there isn't). I haven't done the full analysis of it, but I expect that (1.19 roundTo: (1/10))asFloat gives the Float with representation 16r3FF3333333333333 because it's rounding to a multiple of exactly 0.1, not the Float nearest to 0.1. Regards, -Martin

Oct. 31, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Sean P. DeNigris

Denis Kudriashov wrote > So you don't need blocks generally. > I thought it was seen in my blog post. I guess I was confused by "Also there is way to get multiple mocks at once: [ :mockA :mockB | "your code here" ] runWithMocks" Denis Kudriashov wrote > all projects are compatible. Great! Denis Kudriashov wrote > But also it makes tests fragile for refactorings Ah, very good point! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 31, 2016

Let's talk with Dr Metacello: Moving Pharo to Github

by Guillermo Polito

Hi all, We arranged with Dale a public discussion on discord *this wednesday at 8am PDT (15h Paris)*. The idea is to discuss about the alternatives to store the Pharo sources in Git. Dale is already working on git since a couple of years, - he made has already experimented on a project using git submodules [1] - he is managing the GSDevKit/GLASS project in a kind of ad-hoc fashion (from what I understood in the discussion and looking at the repo...) [2] I was analyzing a bit the pros and cons of git submodules and git subtrees [3] The idea is that we discuss about these alternatives, we learn from the experience of Dale, and try to define some points about the architecture of Pharo source-code's storage in the future. See you there, [1] https://github.com/dalehenrich/amber-skeleton [2] https://github.com/GsDevKit/GsDevKit_home [3] https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-pro…

Oct. 31, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Denis Kudriashov

2016-10-31 16:40 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > You can look at features here: > > http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html. > > Ah, yes. I seem to recall one major hurdle for me was that each test needed > everything wrapped in a block. Is that still the case? Could this be hidden > somewhere in the mechanism? It was changed in version 3. Now blocks could be used to easily get multiple mocks (as block arguments) or to validate group of messages. But it is not necessary. You can just work with separate mocks created by "Mock new". So you don't need blocks generally. I thought it was seen in my blog post. > I also wonder whether Mocketry could be easily > integrated with Phexample, as I really love the stacked test concept... > Months ago I committed version of Phexample based on StateSpecs (new config in Phexample repo). So all projects are compatible. > > > Denis Kudriashov wrote > > BabyMock could not be treated as modern mock library just because it uses > > symbols instead of normal message sends. Even C# and Java mocks are based > > on normal messages. > In practice, I don't see why this makes such a big difference. What am I > missing? For me it is just not readable, more code to write. But also it makes tests fragile for refactorings. Try to change signature of method: new argument, remove argument, switch argument places. And tests will be broken (because mocks use symbols and not real messages).

Oct. 31, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Dimitris Chloupis

I completely agree, I am all for minimal image and then the user should be able to install anything he/she wants through Catalog Browser, I think we need to make sure that the welcome text clearly illustrate this and that the new user is not confused. But that means that you the people who create project that are not in the main distribution make sure your project is on Catalog Browser and that there is a clear description of what it does. Pharo already an excellent mechanism for installing packages. Just today I tried to install OSC library in Pharo 5 though monticello and configuration and I failed, then I tried the Catalog Browser and worked like a charm. Big thanks to Esteban for this amazing tool is by far my favorite, second being GTSpotter of course ;) On Mon, Oct 31, 2016 at 5:50 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Denis Kudriashov wrote > > You can look at features here: > > http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html. > > Ah, yes. I seem to recall one major hurdle for me was that each test needed > everything wrapped in a block. Is that still the case? Could this be hidden > somewhere in the mechanism? I also wonder whether Mocketry could be easily > integrated with Phexample, as I really love the stacked test concept... > > > Denis Kudriashov wrote > > BabyMock could not be treated as modern mock library just because it uses > > symbols instead of normal message sends. Even C# and Java mocks are based > > on normal messages. > > In practice, I don't see why this makes such a big difference. What am I > missing? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 31, 2016

Re: [Pharo-dev] Mocks are missing in Pharo (from thread OSProcess is missing)

by Sean P. DeNigris

Denis Kudriashov wrote > You can look at features here: > http://dionisiydk.blogspot.fr/2016/04/new-version-of-mocketry-30.html. Ah, yes. I seem to recall one major hurdle for me was that each test needed everything wrapped in a block. Is that still the case? Could this be hidden somewhere in the mechanism? I also wonder whether Mocketry could be easily integrated with Phexample, as I really love the stacked test concept... Denis Kudriashov wrote > BabyMock could not be treated as modern mock library just because it uses > symbols instead of normal message sends. Even C# and Java mocks are based > on normal messages. In practice, I don't see why this makes such a big difference. What am I missing? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Mocks-are-missing-in-Pharo-from-thread-OSProcess-is-m… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 31, 2016