- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] float & fraction equality bug

by raffaello.giulietti＠lifeware.ch

On 2017-11-09 21:49, Stephane Ducasse wrote: > On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Note that this started a long time ago and comes up episodically >> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.… >> http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html >> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html >> >> A bit like a "marronnier" (in French, a subject that is treated periodically >> by newspapers and magazines) > > Hi nicolas except that now we could a chapter describing some of the answers :) > It's easy to make = behave as an equivalence if the two objects it operates on are of the same class. But it is well-known that it's hard when their classes are different, short of implementing = trivially in this case. This is to say that there's no real hope to make = an equivalence if the wish is to make it useful in the presence of different kind of objects. In the context of numeric computations, luckily, there is some hope when conversions, if possible at all, are all performed consistently. But the same conversions should then be applied for all operations, whether comparisons or subtractions, etc., to ensure more familiar properties. This is not currently the case in Pharo. Raffaello

Nov. 9, 2017

Re: [Pharo-dev] float & fraction equality bug

by Nicolas Cellier

2017-11-09 21:55 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-11-09 20:10 GMT+01:00 Raffaello Giulietti < > raffaello.giulietti(a)lifeware.ch>: > >> On 2017-11-09 19:04, Nicolas Cellier wrote: >> >>> >>> >>> 2017-11-09 18:02 GMT+01:00 Raffaello Giulietti < >>> raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch >>> >>: >>> >>> >>> >>> >>> Anyway relying upon Float equality should allways be subject to >>> extreme caution and examination >>> >>> For example, what do you expect with plain old arithmetic in >>> mind: >>> >>> a := 0.1. >>> b := 0.3 - 0.2. >>> a = b >>> >>> This will lead to (a - b) reciprocal = 3.602879701896397e16 >>> If it is in a Graphics context, I'm not sure that it's the >>> expected scale... >>> >>> >>> >>> a = b evaluates to false in this example, so no wonder (a - b) >>> evaluates to a big number. >>> >>> >>> Writing a = b with floating point is rarely a good idea, so asking about >>> the context which could justify such approach makes sense IMO. >>> >>> >> Simple contexts, like the one which is the subject of this trail, are the >> one we should strive at because they are the ones most likely used in >> day-to-day working. Having useful properties and regularity for simple >> cases might perhaps cover 99% of the everyday usages (just a dishonestly >> biased estimate ;-) ) >> >> Complex contexts, with heavy arithmetic, are best dealt by numericists >> when Floats are involved, or with unlimited precision numbers like >> Fractions by other programmers. >> >> >> This differs from my experience. > Float strikes in the most simple place were we put false expectation > because of a different mental representation > >> >> >> >> But the example is not plain old arithmetic. >>> >>> Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest >>> to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it >>> seems). Every user of Floats should be fully aware of the implicit >>> loss of precision that using Floats entails. >>> >>> >>> Yes, it makes perfect sense! >>> But precisely because you are aware that 0.1e0 is "the Float closest to >>> 0.1" and not exactly 1/10, you should then not be surprised that they are >>> not equal. >>> >>> >> Indeed, I'm not surprised. But then >> 0.1 - (1/10) >> shall not evaluate to 0. If it evaluates to 0, then the numbers shall >> compare as being equal. >> >> The surprise lies in the inconsistency between the comparison and the >> subtraction, not in the isolated operations. >> >> >> >> >>> I agree that following assertion hold: >>> self assert: a ~= b & a isFloat & b isFloat & a isFinite & b >>> isFinite ==> (a - b) isZero not >>> >>> >> The arrow ==> is bidirectional even for finite Floats: >> >> self assert: (a - b) isZero not & a isFloat & b isFloat & a isFinite & b >> isFinite ==> a ~= b >> >> >> >> But (1/10) is not a Float and there is no Float that can represent it >>> exactly, so you can simply not apply the rules of FloatingPoint on it. >>> >>> When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - >>> 0.1. >>> It is the rounding operation asFloat that made the operation inexact, so >>> it's no more surprising than other floating point common sense >>> >> >> See above my observation about what I consider surprising. >> >> As already said, it's a false expectation in the context of mixed > arithmetic. > > >> >> >> >>> >>> In the case of mixed-mode Float/Fraction operations, I personally >>> prefer reducing the Fraction to a Float because other commercial >>> Smalltalk implementations do so, so there would be less pain porting >>> code to Pharo, perhaps attracting more Smalltalkers to Pharo. >>> >>> Mixed arithmetic is problematic, and from my experience mostly happens >>> in graphics in Smalltalk. >>> >>> If ever I would change something according to this principle (but I'm >>> not convinced it's necessary, it might lead to other strange side effects), >>> maybe it would be how mixed arithmetic is performed... >>> Something like exact difference like Martin suggested, then converting >>> to nearest Float because result is inexact: >>> ((1/10) - 0.1 asFraction) asFloat >>> >>> This way, you would have a less surprising result in most cases. >>> But i could craft a fraction such that the difference underflows, and >>> the assertion a ~= b ==> (a - b) isZero not would still not hold. >>> Is it really worth it? >>> Will it be adopted in other dialects? >>> >>> >>> >> As an alternative, the Float>>asFraction method could return the Fraction >> with the smallest denominator that would convert to the receiver by the >> Fraction>>asFloat method. >> >> So, 0.1 asFraction would return 1/10 rather than the beefy Fraction it >> currently returns. To return the beast, one would have to intentionally >> invoke asExactFraction or something similar. >> >> This might cause less surprising behavior. But I have to think more. >> >> >> No the goal here was to have a non null difference because we need to > preserve inequality for other features. > > Answering anything but a Float at a high computation price goes against > primary purpose of Float (speed, efficiency) > If that's what we want, then we shall not use Float in the first place. > That's why I don't believe in such proposal > > The minimal Fraction algorithm is an intersting challenge though. Not sure > how to find it... > Coming back to a bit of code, we have only minimal decimal (with only > powers of 2 & 5 at denominator): > > {[Float pi asFraction]. [Float pi asMinimalDecimalFraction]} collect: > #bench. > > >> >> >> But the main point here, I repeat myself, is to be consistent and to >>> have as much regularity as intrinsically possible. >>> >>> >>> >>> I think we have as much as possible already. >>> Non equality resolve more surprising behavior than it creates. >>> It makes the implementation more mathematically consistent (understand >>> preserving more properties). >>> Tell me how you are going to sort these 3 numbers: >>> >>> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} sort. >>> >>> tell me the expectation of: >>> >>> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. >>> >>> >> A clearly stated rule, consistently applied and known to everybody, helps. >> >> In presence of heterogeneous numbers, the rule should state the common >> denominator, so to say. Hence, the numbers involved in mixed-mode >> arithmetic are either all converted to one representation or all to the >> other: whether they are compared or added, subtracted or divided, etc. One >> rule for mixed-mode conversions, not two. >> >> >> Having an economy of rules is allways a good idea. > If you can obtain a consistent system with 1 single rule rather than 2 > then go. > But if it's at the price of sacrificing higher expectations, that's > another matter. > > Languages that have a simpler arithmetic model, bounded integer, no > Fraction, may stick to a single rule. > More sofisticated models like you'll find in Lisp and Scheme have exact > same logic as Squeak/Pharo. > > sophisticated... (i'm on my way copying/pasting that one a thousand times) We don't have 2 rules gratuitously as already explained. > - Total relation order of non nan values so as to be a good Magnitude > citizen imply non equality > - Producing Float in case of mixed arithmetic is for practicle purpose: > speed > (What are those damn Float for otherwise?) > it's also justified a posteriori by (exact op: inexact) -> inexact > > What are you ready to sacrifice/trade? > > > >> >> tell me why = is not a relation of equivalence anymore (not associative) >>> >>> >>> >> Ensuring that equality is an equivalence is always a problem when the >> entities involved are of different nature, like here. This is not a new >> problem and not inherent in numbers. (Logicians and set theorists would >> have much to tell.) Even comparing Points and ColoredPoints is problematic, >> so I have no final answer. >> >> In Smalltalk, furthermore, implementing equality makes it necessary to >> (publicly) expose much more internal details about an object than in other >> environments. >> >> >> Let's focus on Number. > Loosing equivalence is loosing ability to mix Numbers in Set. > But not only Numbers... Anything having a Number somewhere in an inst var, > like (1/10)@0 and 0.1@0. > >

Nov. 9, 2017

Re: [Pharo-dev] LayoutFrame bug

by Stephane Ducasse

I could not use MC, packages could not get dirty. So at the end I put a halt in the changersorter fileout because I could not find where the files where saved :) For the PR it happened also to me to use github. Now git is funky the last time I got conflict where there was none: since I was the only one to commit and I had to resolve by hand all the conflicts on github... Stef (zeBugAttractor that is a bit fedup I literally crash everything I used. Computers, telephons.... On Wed, Nov 8, 2017 at 11:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I know it's not the recommended way... > > But if experiencing difficulties with iceberg, you can just use MC to > produce the tonel output file, then use any git client to do the commit and > the pull request... > At worse, you can even modify the tonel file directly without MC (more > dangerous) > > I'm often using sourcetree which is really one of the lowest barrier client > to git (both macosx and windows, not linux though). > > Last time, I did it with git command line, then emmitted the PR from github > web API. > It's just 4 lines: > git branch blablabranch; git src add; git commit; git push --set-upstream > origin blablabranch > I managed to create the branch from iceberg with fogbugz entry # so it was 3 > commands and less blabla for me :) > > And the last alternative is to correct directly the file thru github web > API. > It's more boring to create a correct branch name and reference the bug entry > etc... but it may work. > > 2017-11-08 22:29 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi nicolas >> >> Tx I fixed it before seeing your email. Too bad. >> >> I introduced this bug when I did the asLayoutFrame conversion. >> Note that I split the refactoring in parts to avoid too change commits. >> Now I was also thinking how I could automate the change and this is >> not that easy because the expressions >> can use temps, instance variables... and it would take me age to be >> able to write a rewrite expression (sadly enough). >> >> >> I found it in 3 min because I know the changes I did but your way is >> quite nice because it was not easy to find from the stack trace. >> >> I fixed it but I cannot commit the fix. Iceberg does not let me. >> Now I cannot produce a PR. :( >> >> >> https://pharo.fogbugz.com/f/cases/20656/Nautilus-comment-panel-got-broken-b… >> >> Guille told me that I could modify the printOn: method to help me. >> And this is a bit better (I did not bother to be smart with ; or not) >> I will use this trick to ease the refactoring and minimize errors >> (probably sleeping more should help too and doing less boring tasks >> too :). >> >> >> printOn: aStream >> >> aStream nextPutAll: ' (LayoutFrame identity '. >> self leftFraction = 0 >> ifFalse: [ aStream << ('leftFraction: ', self leftFraction printString, ' >> ') ]. >> self topFraction = 0 >> ifFalse: [ aStream << ('topFraction: ', self topFraction printString, ' ') >> ]. >> self rightFraction = 1 >> ifFalse: [ aStream << ('rightFraction: ', self rightFraction >> printString, ' ') ]. >> self bottomFraction = 1 >> ifFalse: [ aStream << ('bottomFraction: ', self bottomFraction >> printString,' ') ]. >> self leftOffset = 0 >> ifFalse: [ aStream << ('leftOffset: ', self leftOffset printString,' ') ]. >> self topOffset = 0 >> ifFalse: [ aStream << ('topOffset: ', self topOffset printString,' ') ]. >> self rightOffset = 0 >> ifFalse: [ aStream << ('rightOffset: ', self rightOffset printString,' ') >> ]. >> self bottomOffset = 0 >> ifFalse: [ aStream << ('bottomOffset: ', self bottomOffset printString,' >> ') ]. >> aStream nextPutAll: ' ) ' >> >> >> >> On Wed, Nov 8, 2017 at 1:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > Yeah, I just got in trouble too by looking at class comments. >> > >> > Heroic debugging, Nicolas ! >> > >> >> On 8 Nov 2017, at 13:47, Nicolas Cellier >> >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> Hi, >> >> don't you get nice red-cross when opening a browser and selecting >> >> comment? >> >> (Pharo7.0-32bit-b5ec533.image) >> >> >> >> The problem is LayoutFrame having a Point instead of Number in >> >> fraction/offset inst. var. >> >> >> >> So I defined two horrible hacks in order to be able to work with Pharo >> >> >> >> Point>>@ n ^x @ n >> >> Point>>asInteger ^x asInteger >> >> >> >> then could instrument the LayoutFrame inst. var. setters with horrible >> >> checks like: >> >> aNumber isNumber ifFalse: [ self halt]. >> >> >> >> And after a few seconds of IDE usage: >> >> >> >> AbstractNautilusUI>>buildCodePanelWithCommentOnRight >> >> ...snip... >> >> sourceCodePanel >> >> addMorph: commentWidget >> >> fullFrame: (LayoutFrame identity leftFraction: 0.5@0 ; >> >> leftOffset: delta). >> >> >> >> Huh! it's as pleasant as not eating own dog food >> >> I think this comes from a recent refactoring. I can hardly use in >> >> image tools to trace it. >> >> Iceberg bugs, MC has lost ancestry and is just good at synchronizing >> >> disk working copy with image working copy, but there is github & git API: >> >> >> >> >> >> https://github.com/pharo-project/pharo/commit/042baad47fddb63db2dd0beefeec6… >> >> >> >> As it's nearly impossible to make giant refactorings like this without >> >> human error, >> >> and as it's as impossible to review pull request with many lines of >> >> code, >> >> I wonder if it is possible to automate those with rewrite rules... >> >> >> >> I let you finish the work (open issue, patch, commit, etc...) >> >> >> >> >> > >> > >> >

Nov. 9, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Stephane Ducasse

Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . Stef On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The basic tools, such as debugger, are expected to work. If something does not work, itâs a bug. > > Cheers, > Doru > > >> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> I think it's broken in Pharo 6 too, as I often find it unreliable. >> >> It's hard to know what should work anymore - we really need a stabilisation release to let the dust settle. >> >> I'm always a bit reticent to report things as I'm not sure what you expect to work. >> >> Tim >> >> Sent from my iPhone >> >>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi >>> >>> I have the following method and I have my cursor -MY CURSOR HERE- >>> I select the menu run to here and .... I exit the method. >>> :( >>> >>> Is run to here working in Pharo 70? >>> I start to get worry about the number of bugs I get when using Pharo70. >>> >>> Stef >>> >>> >>> fileOut >>> "File out the receiver, to a file whose name is a function of the >>> change-set name and a unique numeric tag." >>> >>> | nameToUse | >>> self halt. >>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>> nextVersion basename. >>> UIManager default >>> showWaitCursorWhile: >>> [ >>> | internalStream | >>> internalStream := (String new: 10000) writeStream. >>> >>> -MY CURSOR HERE- >>> >>> internalStream >>> header; >>> timeStamp. >>> self fileOutPreambleOn: internalStream. >>> self fileOutOn: internalStream. >>> self fileOutPostscriptOn: internalStream. >>> CodeExporter >>> writeSourceCodeFrom: internalStream >>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>> isSt: false ] >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > >

Nov. 9, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Stephane Ducasse

We should report and we should fix. On Wed, Nov 8, 2017 at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: > I think it's broken in Pharo 6 too, as I often find it unreliable. > > It's hard to know what should work anymore - we really need a stabilisation release to let the dust settle. > > I'm always a bit reticent to report things as I'm not sure what you expect to work. > > Tim > > Sent from my iPhone > >> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi >> >> I have the following method and I have my cursor -MY CURSOR HERE- >> I select the menu run to here and .... I exit the method. >> :( >> >> Is run to here working in Pharo 70? >> I start to get worry about the number of bugs I get when using Pharo70. >> >> Stef >> >> >> fileOut >> "File out the receiver, to a file whose name is a function of the >> change-set name and a unique numeric tag." >> >> | nameToUse | >> self halt. >> self class promptForDefaultChangeSetDirectoryIfNecessary. >> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >> nextVersion basename. >> UIManager default >> showWaitCursorWhile: >> [ >> | internalStream | >> internalStream := (String new: 10000) writeStream. >> >> -MY CURSOR HERE- >> >> internalStream >> header; >> timeStamp. >> self fileOutPreambleOn: internalStream. >> self fileOutOn: internalStream. >> self fileOutPostscriptOn: internalStream. >> CodeExporter >> writeSourceCodeFrom: internalStream >> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >> isSt: false ] >> > >

Nov. 9, 2017

Re: [Pharo-dev] Is fileout on the change sorter working in Pharo 70?

by Stephane Ducasse

Tx guille. We should probably improve the class comment of File to express that this is the low level layer. Stef On Thu, Nov 9, 2017 at 10:50 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > > > On Thu, Nov 9, 2017 at 10:35 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi >> >> 2017-11-08 21:53 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> It looks like the problem is here but I cannot find it. >>> >>> CodeExporter>> writeSourceCodeFrom: aStream baseName: baseName isSt: >>> stOrCsFlag >>> >>> | extension fileName outputStream | >>> self halt. >>> extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. >>> fileName := baseName, extension. >>> fileName := FileSystem disk checkName: fileName fixErrors: true. >>> outputStream := (File named: fileName) writeStream. >>> (ZnCrPortableWriteStream on: (ZnCharacterWriteStream >>> on: outputStream >>> encoding: 'utf8')) nextPutAll: aStream contents. >>> >>> outputStream close. >>> >>> self inform: 'Filed out to: ', String cr, fileName. >> >> >> Try rewrite code to FileSystem. I think we should never use File directly: >> >> extension := stOrCsFlag ifTrue: ['st'] ifFalse: ['cs']. >> FileLocator home / baseName , extension writeStreamDo: [:s | >> >> (ZnCrPortableWriteStream on: (ZnCharacterWriteStream >> >> on: s >> >> encoding: 'utf8')) nextPutAll: aStream contents]. >> >> We should choose what to use instead of #home in that case. >> > > I just discussed a point with Denis, just replicating it here. > > We should not **blindly** rewrite everything to use FileSystem. Because > that may break dependencies in the system. > For example, CodeExporter is used by Monticello. > > Should monticello depend on FileSystem or not? > > I'm not saying monticello should or should not depend on it. Just saying > that we should ask ourselves the question :) > > >> >> I wondering does File is actually used by FileSystem? >> > > It will ;) > > >> Should not we remove it from system? >> > > No! File is exactly the low level File representation, that FileSystem > should use. > > >> >> >>> >>> On Wed, Nov 8, 2017 at 9:38 PM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> wrote: >>> > Ah thanks we should fix this. >>> > >>> > On Wed, Nov 8, 2017 at 9:31 PM, Christian Kellermann >>> > <ckeen(a)pestilenz.org> wrote: >>> >> * Stephane Ducasse <stepharo.self(a)gmail.com> [171108 21:29]: >>> >>> Hi >>> >>> >>> >>> I'm trying to rescue some of my work (that I cannot save in MC nor in >>> >>> Iceberg because the system >>> >>> does not see it - super funny). >>> >>> >>> >>> I can browse the change using the changesorter when I do fileout >>> >>> the system tells me that the file it saved but I cannot find it on >>> my disc. >>> >>> Apparently none of the fileout is working in the changesorter. :( >>> >> >>> >> I have successfully filed out code with epicea but not changesorter. >>> >> >>> >> HTH, >>> >> >>> >> Christian >>> >> >>> >> -- >>> >> May you be peaceful, may you live in safety, may you be free from >>> >> suffering, and may you live with ease. >>> >> >>> >>> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Nov. 9, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Stephane Ducasse

>> > > Then should not we replace STON based class definition with actual smalltalk > based definition? Tonel could parse class definition in similar way like it > parses methods. Probably not :) but one of this day we will change the class definition in Pharo adn we do not really want to impact tonel. For me tonel is a storage format and it is ok like that. Using Strings will solve the glitches. Stef

Nov. 9, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by Stephane Ducasse

On Wed, Nov 8, 2017 at 10:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 8 Nov 2017, at 21:29, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Sven >> >> I understand but it is SUPER strange to save the code in a format that >> does not respect the syntax of the language. >> I think that we should write a parser for the class definition or save >> category as strings. >> >> I do not want to have to explain to people. Yes and no this is not the >> pharo syntax. >> >> Sorry I'm fed up. > > Tonel is a mix of different formats. Parts are custom to Tonel (the overall structure), parts are Pharo syntax (the method's source code), parts are STON (the contents of the meta data sections). > > Even if we make a change to how the Symbols are represented, it would still not make the meta sections Pharo syntax. > > But I do agree it is a bit confusing. > > Either we make them all Strings, or I could add an option to STON that allows STONWriter to control what constitutes a 'simple' or 'literal' Symbol. Yes this would be great. Stef > > And we could err on the safe side (like only allow 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'), because I dare you to look at String>>#isLiteralSymbol it is way more ugly than STON's simple definition (which allows all characters from 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./'). > > What is the opinion of the original Tonel designers ? > >> Stef >> >> On Mon, Nov 6, 2017 at 10:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 6 Nov 2017, at 20:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Esteban told me that this is because he uses STON for the class definition. >>>> Now a simple question may be we could use a string instead of a symbol >>>> because this is strange >>>> to have a class definitino that does not respect Pharo syntax. >>> >>> It might be a bit confusing at first sight, but it is correct, IMHO. >>> >>> It is STON syntax, not Pharo. >>> >>> Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself. >>> >>> STON fromString: (STON toString: #'My Strange Symbol'). >>> STON fromString: (STON toString: #'foo-bar'). >>> >>> If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted in STON. >>> >>> I see no problem there. >>> >>>> Stef >>>> >>>> On Mon, Nov 6, 2017 at 8:15 PM, Dale Henrichs >>>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>>> >>>>> >>>>> On 11/06/2017 08:23 AM, Sven Van Caekenberghe wrote: >>>>>> >>>>>> >>>>>>> On 6 Nov 2017, at 17:13, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/6/17 7:07 AM, Sven Van Caekenberghe wrote: >>>>>>>>> >>>>>>>>> On 6 Nov 2017, at 15:43, Dale Henrichs >>>>>>>>> <dale.henrichs(a)gemtalksystems.com> wrote: >>>>>>>>> >>>>>>>>> of course with Pharo's implementation of Symbol it is not practical to >>>>>>>>> use asString nor type checks - things that are not necessary in other >>>>>>>>> Smalltalk implementations >>>>>>>> >>>>>>>> How so ? >>>>>>>> >>>>>>>> What is the problem with Symbol>>#asString ? >>>>>>> >>>>>>> I am not going to go to every field in the api that is supposed to be a >>>>>>> String and add asString. There are too many places to worry about ... I >>>>>>> would prefer that Pharo be ANSI compliant:) >>>>>>> >>>>>>> It's not just Metacello. >>>>>>> >>>>>>> It's an annoying issue that has to be dealt with every time a Pharo >>>>>>> application is ported to another dialect of Smalltalk and an annoying >>>>>>> barrier for folks running on other dialects to move their application to >>>>>>> Pharo - in this case the bugs that are introduced by Pharo's behavior with >>>>>>> respect to Symbols can be very hard to diagnose -- >>>>>>> >>>>>>> Making things harder to share code between dialects is a bad thing for >>>>>>> Smalltalk overall -- just another reason for non-Smalltalk programmers to >>>>>>> question the whether they should use Smalltalk or not... >>>>>>> >>>>>>> And I don't need to hear about how Pharo is not Smalltalk:) >>>>>>> >>>>>>> Dale >>>>>> >>>>>> So there is nothing 'wrong', you just want Pharo to remain the same as >>>>>> every other non-changing Smalltalk out there. >>>>> >>>>> Did I say that? >>>>> >>>>> I support the direction that Pharo is going, but I reserve the right to >>>>> disagree with some of the details. >>>>> >>>>> This is just one detail ... nothing more nothing less ... For those of us >>>>> that work in multiple dialects, it IS annoying and I take an opportunity >>>>> every year or so to remind you guys of the things that I find annoying, just >>>>> to keep you guys honest:) >>>>> >>>>>> >>>>>> From one perspective you are right, it makes some cross platform porting >>>>>> in either direction harder. Seaside has many rules to help portability. Not >>>>>> mixing Strings and Symbol is probably one of them. >>>>> >>>>> ... and as I mentioned, this problem can be one of the more annoying issues >>>>> to track down, when a developer is not careful ... Honestly there are two >>>>> sides to the issue ... when developers use Symbols in tests to drive an API >>>>> that is supposed to use Strings (this happens the most often) things break >>>>> pretty quickly and the tests can be fixed pretty easily ... but when the >>>>> code itself is written with mixed Symbols and Strings, the tests might >>>>> actually pass after the port, and the bugs will only show up in subtle cases >>>>> ... I've hit a handful of these over the years and they are hard to track >>>>> down... >>>>>> >>>>>> >>>>>> But you know very well that Pharo was started so that we would be able to >>>>>> make changes, in any area or aspect of the system, without the burden of >>>>>> backwards or cross platform compatibility, even if some of these changes are >>>>>> taste based. >>>>> >>>>> Agree with your statement -- most of the changes that Pharo has made have >>>>> not been difficult to accommodate, but Symbol/String is at a fundamental >>>>> level and I'm not sure that it would be "illegal" to make this accommodation >>>>> --- I AM pretty certain that it would cause some short term pain, but >>>>> probably no more pain (and likely less pain) than is caused by trying to >>>>> move an application to a new version of Pharo:) >>>>>> >>>>>> And I happen to like the ability to mix and match Strings and Symbols (we >>>>>> discussed about this before). >>>>>> >>>>> I won't argue with taste, it's is simply the portability for this particular >>>>> problem that I am highlighting ... >>>>> >>>>> Dale >>>>> >>>> >>> >>> >> > >

Nov. 9, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #273: 20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-

by Stephane Ducasse

Thanks for this!!!!!! Stef On Thu, Nov 9, 2017 at 2:57 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: > There is a new Pharo build available! > > The status of the build #273 was: SUCCESS. > > The Pull Request #456 was integrated: "20661-Fixing-test-from-debugger-should-mark-test-as-green-when-proceed-" > Pull request url: https://github.com/pharo-project/pharo/pull/456 > > Issue Url: https://pharo.fogbugz.com/f/cases/20661 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 9, 2017

Re: [Pharo-dev] float & fraction equality bug

by Nicolas Cellier

2017-11-09 20:10 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > On 2017-11-09 19:04, Nicolas Cellier wrote: > >> >> >> 2017-11-09 18:02 GMT+01:00 Raffaello Giulietti < >> raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch >> >>: >> >> >> >> >> Anyway relying upon Float equality should allways be subject to >> extreme caution and examination >> >> For example, what do you expect with plain old arithmetic in mind: >> >> a := 0.1. >> b := 0.3 - 0.2. >> a = b >> >> This will lead to (a - b) reciprocal = 3.602879701896397e16 >> If it is in a Graphics context, I'm not sure that it's the >> expected scale... >> >> >> >> a = b evaluates to false in this example, so no wonder (a - b) >> evaluates to a big number. >> >> >> Writing a = b with floating point is rarely a good idea, so asking about >> the context which could justify such approach makes sense IMO. >> >> > Simple contexts, like the one which is the subject of this trail, are the > one we should strive at because they are the ones most likely used in > day-to-day working. Having useful properties and regularity for simple > cases might perhaps cover 99% of the everyday usages (just a dishonestly > biased estimate ;-) ) > > Complex contexts, with heavy arithmetic, are best dealt by numericists > when Floats are involved, or with unlimited precision numbers like > Fractions by other programmers. > > > This differs from my experience. Float strikes in the most simple place were we put false expectation because of a different mental representation > > > > But the example is not plain old arithmetic. >> >> Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest >> to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it >> seems). Every user of Floats should be fully aware of the implicit >> loss of precision that using Floats entails. >> >> >> Yes, it makes perfect sense! >> But precisely because you are aware that 0.1e0 is "the Float closest to >> 0.1" and not exactly 1/10, you should then not be surprised that they are >> not equal. >> >> > Indeed, I'm not surprised. But then > 0.1 - (1/10) > shall not evaluate to 0. If it evaluates to 0, then the numbers shall > compare as being equal. > > The surprise lies in the inconsistency between the comparison and the > subtraction, not in the isolated operations. > > > > >> I agree that following assertion hold: >> self assert: a ~= b & a isFloat & b isFloat & a isFinite & b >> isFinite ==> (a - b) isZero not >> >> > The arrow ==> is bidirectional even for finite Floats: > > self assert: (a - b) isZero not & a isFloat & b isFloat & a isFinite & b > isFinite ==> a ~= b > > > > But (1/10) is not a Float and there is no Float that can represent it >> exactly, so you can simply not apply the rules of FloatingPoint on it. >> >> When you write (1/10) - 0.1, you implicitely perform (1/10) asFloat - 0.1. >> It is the rounding operation asFloat that made the operation inexact, so >> it's no more surprising than other floating point common sense >> > > See above my observation about what I consider surprising. > > As already said, it's a false expectation in the context of mixed arithmetic. > > > >> >> In the case of mixed-mode Float/Fraction operations, I personally >> prefer reducing the Fraction to a Float because other commercial >> Smalltalk implementations do so, so there would be less pain porting >> code to Pharo, perhaps attracting more Smalltalkers to Pharo. >> >> Mixed arithmetic is problematic, and from my experience mostly happens in >> graphics in Smalltalk. >> >> If ever I would change something according to this principle (but I'm not >> convinced it's necessary, it might lead to other strange side effects), >> maybe it would be how mixed arithmetic is performed... >> Something like exact difference like Martin suggested, then converting to >> nearest Float because result is inexact: >> ((1/10) - 0.1 asFraction) asFloat >> >> This way, you would have a less surprising result in most cases. >> But i could craft a fraction such that the difference underflows, and the >> assertion a ~= b ==> (a - b) isZero not would still not hold. >> Is it really worth it? >> Will it be adopted in other dialects? >> >> >> > As an alternative, the Float>>asFraction method could return the Fraction > with the smallest denominator that would convert to the receiver by the > Fraction>>asFloat method. > > So, 0.1 asFraction would return 1/10 rather than the beefy Fraction it > currently returns. To return the beast, one would have to intentionally > invoke asExactFraction or something similar. > > This might cause less surprising behavior. But I have to think more. > > > No the goal here was to have a non null difference because we need to preserve inequality for other features. Answering anything but a Float at a high computation price goes against primary purpose of Float (speed, efficiency) If that's what we want, then we shall not use Float in the first place. That's why I don't believe in such proposal The minimal Fraction algorithm is an intersting challenge though. Not sure how to find it... Coming back to a bit of code, we have only minimal decimal (with only powers of 2 & 5 at denominator): {[Float pi asFraction]. [Float pi asMinimalDecimalFraction]} collect: #bench. > > > But the main point here, I repeat myself, is to be consistent and to >> have as much regularity as intrinsically possible. >> >> >> >> I think we have as much as possible already. >> Non equality resolve more surprising behavior than it creates. >> It makes the implementation more mathematically consistent (understand >> preserving more properties). >> Tell me how you are going to sort these 3 numbers: >> >> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} sort. >> >> tell me the expectation of: >> >> {1.0 . 1<<60+1/(1<<60). 1<<61+1/(1<<61)} asSet size. >> >> > A clearly stated rule, consistently applied and known to everybody, helps. > > In presence of heterogeneous numbers, the rule should state the common > denominator, so to say. Hence, the numbers involved in mixed-mode > arithmetic are either all converted to one representation or all to the > other: whether they are compared or added, subtracted or divided, etc. One > rule for mixed-mode conversions, not two. > > > Having an economy of rules is allways a good idea. If you can obtain a consistent system with 1 single rule rather than 2 then go. But if it's at the price of sacrificing higher expectations, that's another matter. Languages that have a simpler arithmetic model, bounded integer, no Fraction, may stick to a single rule. More sofisticated models like you'll find in Lisp and Scheme have exact same logic as Squeak/Pharo. We don't have 2 rules gratuitously as already explained. - Total relation order of non nan values so as to be a good Magnitude citizen imply non equality - Producing Float in case of mixed arithmetic is for practicle purpose: speed (What are those damn Float for otherwise?) it's also justified a posteriori by (exact op: inexact) -> inexact What are you ready to sacrifice/trade? > > tell me why = is not a relation of equivalence anymore (not associative) >> >> >> > Ensuring that equality is an equivalence is always a problem when the > entities involved are of different nature, like here. This is not a new > problem and not inherent in numbers. (Logicians and set theorists would > have much to tell.) Even comparing Points and ColoredPoints is problematic, > so I have no final answer. > > In Smalltalk, furthermore, implementing equality makes it necessary to > (publicly) expose much more internal details about an object than in other > environments. > > > Let's focus on Number. Loosing equivalence is loosing ability to mix Numbers in Set. But not only Numbers... Anything having a Number somewhere in an inst var, like (1/10)@0 and 0.1@0.

Nov. 9, 2017