August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Complex Solutions

by Schwab,Wilhelm K

Ken, Understood about punch cards, and in fact I have some loose methods in String to avoid such hassles with hard to spot spellings. That said, I simply disagree with you on #cosh vs. #cosH. As I said, I'm not particularly invested in the outcome; I just find it cumbersome to type and to read, and despite that, would not conclude that cosH is not a typo - it would depend on the circumstances. As I said, I'm not planning any major troop movements over this one. As for the zero vector, it is hard to say. Note that a nearly zero vector is going to have a very poorly defined direction in that the result will likely be dominated by roundoff error. Often there is a better way to compute such things; a rearrangment of governing equations can make a world of difference - that's not something you can fix, it will be problem-specific how one would avoid computing the argument in tricky situations. One possible approach is to simply compute the angle the same way for all values and let under/over flow errors take care of the garbage. Another would be to raise an error. Finally, you might define #argument, #argumentIfSmall: (takes a block for the troublesome case) and #argumentIEEE to use their convetion. Something that deserves a careful look is the test for floats being close to each other. I have been supicious about that for a while, and on first glance, Dolphin seems to handle it very differently from the way Squeak does. IMHO, being different from Dolphin is cause for a good think. We shouls also see how VW handles it. Just looking at #closeTo:, it appears to "think" that 10^-4 is a good threshold, and that is questionable depending on the scales involved, and is far from the smallest float that can be reasonable represented. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken Dickey Sent: Sunday, August 30, 2009 6:10 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex Solutions >From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> ... >On #cosH vs. #cosh, etc.,I do not like what you have done, but it's >hardly cause to start a war. I would be more inclined to agree with >your no-typo argument if you spelled out hyperbolic. We write cos and >cosh; I see no advantage to typing cosH, which could just as easily be errant as cosh. I don't understand your comment. "cos" and "cosh" differ in a single, lower case character. In a line of code where I expect to see "cos" but the text is actually "cosh" I would be more likely to misread the text as "cos" than if the text is "cosH". In this case the capital is distinctive. It clues the reader to the difference. [I once had a bug in a Fortran program where 1 was substituted for l (ell) but in the punch card font, it was very difficult to distinguish this]. >#angle vs. #argument. The terminology of modulus and argument is heavily > drilled into engineers and physisists, so I would go with that inertia vs. > anything from Scheme or Lisp. Thanks. I'll make the change. >>Complex>>angle looks like it will answer zero for a value of zero?? >>Complex>>AFAIK, >> there should be no direction for a zero vector. In a way, it is >> splitting hairs because exact comparisons of floats are dubious, but >> it probably should raise an error for zero. I'll raise an error. Zero divide? One again, thanks. -KenD _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2009

Re: [Pharo-project] Complex Solutions

by Ken Dickey

>From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> ... >On #cosH vs. #cosh, etc.,I do not like what you have done, but it's hardly > cause to start a war. I would be more inclined to agree with your no-typo > argument if you spelled out hyperbolic. We write cos and cosh; I see no > advantage to typing cosH, which could just as easily be errant as cosh. I don't understand your comment. "cos" and "cosh" differ in a single, lower case character. In a line of code where I expect to see "cos" but the text is actually "cosh" I would be more likely to misread the text as "cos" than if the text is "cosH". In this case the capital is distinctive. It clues the reader to the difference. [I once had a bug in a Fortran program where 1 was substituted for l (ell) but in the punch card font, it was very difficult to distinguish this]. >#angle vs. #argument. The terminology of modulus and argument is heavily > drilled into engineers and physisists, so I would go with that inertia vs. > anything from Scheme or Lisp. Thanks. I'll make the change. >>Complex>>angle looks like it will answer zero for a value of zero?? >>Complex>>AFAIK, >> there should be no direction for a zero vector. In a way, it is >> splitting hairs because exact comparisons of floats are dubious, but >> it probably should raise an error for zero. I'll raise an error. Zero divide? One again, thanks. -KenD

Aug. 30, 2009

[Pharo-project] How to build a GUI

by Torsten Bergmann

>Now i`m adding new capabilities. That means you are already working on the next milestone ... >but It does not have sense to raise something incorrect or incomplete If that wouldnt make sense you wouldnt have a pharo image (or any other kind of software) in your hands :) Even when you can prove your software is correct (whatever that means in a context of a UI builder compared to an algorithm) there is always something you can add. So it will never be complete. Even when it is not complete in your own eyes you should declare it "pre-alpha" work and make it accessible. Dont fear that others look at your code! Hey with Smalltalk in your hands your code cant be that ugly ;) You already got positive feedback that you started such a project and people are able to help or tell you what features/directions they would like to see. They may even help you to find and fix bugs. It could also be that nothing happens and you work on it alone as it is now. It may also be that you loose interest and others take it as a base and continue with your work (depending on license). Who knows ... >I prefer not to say when I will conclude my work Release early and show a steady progress by releasing often. Thats the key to success. And listen to feedback. Otherwise you will work towards "the perfect time to release" (remember you already said it will be in a releasable state after 14 days) You already mentioned the next tasks on your list (which will continue to grow the more you work since you will get more ideas and it will become more and more work for a single person). Most of the time projects working towards perfection will never be released or used. There is also the problem that others will start developing a similar one meanwhile since they cant wait or dont know that there is already someone investing his time and knowledge. Even when you think the day has come and anything is perfect you may be disappointed since it is possible that people disagree with the result and come up with something different. Even when it is good others may develop different UI builder frameworks (have a look at Java ;) As I said there is no "complete" or "correct" code - the world is spinning day by day and projects, people, contexts, ... will change. Anything that does not change or adapt to the next day can be declared as dead. >IÂ´m put much effort in that work and i want do it good. However ... it is your decision. I for my part would really like to see a nice UI builder for one of the early releases of Pharo, especially since you already put so much effort into it. Bye Torsten -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Aug. 30, 2009

Re: [Pharo-project] Package naming Scheme

by Miguel Enrique CobÃ¡ Martinez

El dom, 30-08-2009 a las 22:27 +0200, Torsten Bergmann escribiÃ³: > Currently pharo packages are named differently: > > - either "MyPackage" and "Tests-MyPackage" for the tests > - or "MyPackage" and "MyPackage-Tests" for the tests > - or something completely different like "GraphicsTests-Text" > > First one is used more often but not very good when > using the "alphabetize" functionality in the context > menu of the standard browser ;) > > Since the package naming scheme also affects > - the monticello repo layouts > - removal/shrink scripts (see ScriptLoader>>cleanupForProduction) > - and method category names for extensions > > we should agree on at least one to use. I vote for the Seaside convention, summarized on: http://code.google.com/p/seaside/wiki/PackageNaming At leas, in my projects is the one I use and it sorts correctly on the package browsers and in the Monticello repos. > > Were the pros and cons of the different naming > schemes already discussed? If so is there any docu around? > I remember Lukas suggested to use the one from Seaside... > > Thx > Torsten -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 30, 2009

Re: [Pharo-project] Complex Solutions

by Schwab,Wilhelm K

==================== Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? ==================== You apparently do NOT understand. 1i squared would answer a Complex, so it would respond favorably to #sqrt. ================== Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? ================== Yes. It's not "even when" - just don't do conversions when (you think) floating points numbers match. ============ 1i whatever he already made her/his choice to use Complex numbers, right? ============ Right. So don't try to turn it back into a Float and all will be well. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Sunday, August 30, 2009 4:27 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex Solutions Em 30/08/2009 13:36, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: > > > Ken, > > On #cosH vs. #cosh, etc.,I do not like what you have done, but > it's hardly cause to start a war. I would be more inclined to agree > with your no-typo argument if you spelled out hyperbolic. We write > cos and cosh; I see no advantage to typing cosH, which could just as > easily be errant as cosh. > > #angle vs. #argument. The terminology of modulus and argument is > heavily drilled into engineers and physisists, so I would go with > that inertia vs. anything from Scheme or Lisp. > > > ============= "If Complex does not interoperate, at least to > some extent, with Floats how would it be useful for anything? > Smalltalk without polymorphism ???" > > That's not it at all. Sig and I hav been very clear on using > polymorphism to get he expected behavior in each world, and how > it can extend to (for example) exponentials of matrices. I don't > know how to make it more clear that we have done. We object to > implicit coercion which works against anyone interested only in > real results. ============= > Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? Please not that once the programmer wrote: 1i whatever he already made her/his choice to use Complex numbers, right? > > =============== > >Complex>>angle looks like it will answer zero for a value of > >zero?? > >Complex>>AFAIK, there should be no direction for a zero > > vector. In a way, it is splitting hairs because exact > > comparisons of floats are dubious, but it probably should > > raise an error for zero. > > I am following ANSI X3J13 (they had a formal vote which declared > the angle of zero to be zero). Let me know of a better > refrerence. [The problem with standards is that there are so > many to chose from ;^]. =============== > > ANSI is the same group that put an end to time as we know it in > 2037 (maybe 2038); if you thought y2k was a mess, just wait until > time_t wraps. Zero vectors (and complex numbers act as vectors in > this case) have no direction, and ANSI's vote does not change > that. Many times you have shown a desire to make things more > mathematically correct; ANSI is just plain wrong here. The only > argument in their favor is that the distinction might be slightly > vacant because computing a truly zero result is very unlikely in a > floating point world. Oh well, interesting way of looking at things: a non sequitur comment on size of time_t and a dismissal of an agreed upon Standard. You'll have a lot of problem using complex numbers as you want if you don't follow IEEE and ANSI stipulations on the angle of certain operations when voltage is squared to calculate power or the angle of it (which follows the angle of the load) as there is more than a single mathematical correct answer. Back to mathematical purity, then we have a conundrum: as Ken wrote several times Complex is considered a superset of Real numbers in mathematics is Smalltalk class hierarchy that "decided" to consider Number as a subclass of Magnitude that has to respond to #<, but this is not necessary in mathematics in general, no reference about number theory you find such necessary condition. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 30, 2009

Re: [Pharo-project] How to build a GUI

by Henrik Johansen

On Aug 30, 2009, at 10:32 32PM, nullPointer wrote: > -Create a mechanism for link properties or accessors of a object > ( entitys ) > at controls.I donÂ´t like the MorphicModel mechanism,and dependences. > I want > events for all.That last is very important necessity. Having seen a...fair amount of how complex event handling can get in VisualWorks GUI's, I'd really appreciate it if you'd take a look into using Announcements :) Unless of course, events mean something entirely different in Squeak. > Now iÂ´m adding new capabilities. > > -Radio buttons widget mechanism.A selection of one must disable the > others > in the same container. > -Styles editor. I want add the capabilitie of create and edit styles > for the > widgets.And apply with a #applyStyle: method. and too from UIBuilder. > -Add new properties for set in the UIBuilder, not only the basics > text, > image or font. > -I want build a tabControl of intuitive way, add, remove and fill > tabs from > designer. > -A good way for persist the morph mechanism is needed.Perhaps not > now but it > will be necessary more ahead if something serious is wanted. I love the sweet smell of feature creep in the morning! Just remember, shipping something is better than nothing, and it's not like anything existing seems to come even close to what you have made already. > > I prefer not to say when I will conclude my work, but It does not > have sense > to raise something incorrect or incomplete. IÂ´m put much effort in > that work > and i want do it good. > > Regards :) Incorrect, I agree. Take a look at the Pharo bugtracker and note the amount of pure bugs not marked 1.0 if you feel 0 bugs is the limit for when something is in a releasable state though :) Incomplete... well, 20% gets used 80% of the time and all that. I have no idea of the structure of what you are doing, just thought I'd add one thing, which I've found immensely useful in the VW UIBuilder: - Include hooks in the interface building process. (preBuildWith: , postBuildWith:, preOpenWith: postOpenWith: ), so you can modify the spec at runtime. Not everything about how you want an interface to display can be known at design-time, adding such hooks provide the means to do pretty neat dynamic stuff based on the runtime environment. F.ex: - VisualWorks allows you to provide application-specified labels instead of hardcoding them in the design viewer. However, by default, only labels defined as methods on the class side of the ApplicationModel will be mapped to the builders list of labels. (as far as I know at least...). Using preBuildWith:, you can add instance-specific (say, taken from its model) labels to the Builders dictionary of available labels. Good luck with the further work, I look forward to seeing the results! Cheers, Henry

Aug. 30, 2009

Re: [Pharo-project] Complex Solutions

by csrabak＠bol.com.br

Em 30/08/2009 13:36, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: > > > Ken, > > On #cosH vs. #cosh, etc.,I do not like what you have done, but > it's hardly cause to start a war. I would be more inclined to agree > with your no-typo argument if you spelled out hyperbolic. We write > cos and cosh; I see no advantage to typing cosH, which could just as > easily be errant as cosh. > > #angle vs. #argument. The terminology of modulus and argument is > heavily drilled into engineers and physisists, so I would go with > that inertia vs. anything from Scheme or Lisp. > > > ============= "If Complex does not interoperate, at least to > some extent, with Floats how would it be useful for anything? > Smalltalk without polymorphism ???" > > That's not it at all. Sig and I hav been very clear on using > polymorphism to get he expected behavior in each world, and how > it can extend to (for example) exponentials of matrices. I don't > know how to make it more clear that we have done. We object to > implicit coercion which works against anyone interested only in > real results. ============= > Let me see if I understand your point then: it is OK in your view that we can do: 1i squared. retuning "-1 + 0i" so a Complex, but (1i squared) sqrt. raises an error? Or should we follow your logic and even when the imaginary part of a Complex is zero it should not be automatically converted in a real number? Please not that once the programmer wrote: 1i whatever he already made her/his choice to use Complex numbers, right? > > =============== > >Complex>>angle looks like it will answer zero for a value of > >zero?? > >Complex>>AFAIK, there should be no direction for a zero > > vector. In a way, it is splitting hairs because exact > > comparisons of floats are dubious, but it probably should > > raise an error for zero. > > I am following ANSI X3J13 (they had a formal vote which declared > the angle of zero to be zero). Let me know of a better > refrerence. [The problem with standards is that there are so > many to chose from ;^]. =============== > > ANSI is the same group that put an end to time as we know it in > 2037 (maybe 2038); if you thought y2k was a mess, just wait until > time_t wraps. Zero vectors (and complex numbers act as vectors in > this case) have no direction, and ANSI's vote does not change > that. Many times you have shown a desire to make things more > mathematically correct; ANSI is just plain wrong here. The only > argument in their favor is that the distinction might be slightly > vacant because computing a truly zero result is very unlikely in a > floating point world. Oh well, interesting way of looking at things: a non sequitur comment on size of time_t and a dismissal of an agreed upon Standard. You'll have a lot of problem using complex numbers as you want if you don't follow IEEE and ANSI stipulations on the angle of certain operations when voltage is squared to calculate power or the angle of it (which follows the angle of the load) as there is more than a single mathematical correct answer. Back to mathematical purity, then we have a conundrum: as Ken wrote several times Complex is considered a superset of Real numbers in mathematics is Smalltalk class hierarchy that "decided" to consider Number as a subclass of Magnitude that has to respond to #<, but this is not necessary in mathematics in general, no reference about number theory you find such necessary condition.

Aug. 30, 2009

[Pharo-project] Package Browser (bis)

by Ramiro Diaz Trepat

I am very happy now that the package browser is back with us, but I have a couple of questions: 1. Where did the refactoring tools go? This version does not seem to include them. 2. I know this may be too picky, but I don't know if you realized that when you start editing, instead of seeing a whole red frame (as unsaved) we only have left 4 red pixels, one in each corner of the editing pane. is this worthy of a ticket? Cheers r.

Aug. 30, 2009

Re: [Pharo-project] How to build a GUI

by nullPointer

Now iÂ´m adding new capabilities. -Radio buttons widget mechanism.A selection of one must disable the others in the same container. -Styles editor. I want add the capabilitie of create and edit styles for the widgets.And apply with a #applyStyle: method. and too from UIBuilder. -Add new properties for set in the UIBuilder, not only the basics text, image or font. -Create a mechanism for link properties or accessors of a object ( entitys ) at controls.I donÂ´t like the MorphicModel mechanism,and dependences. I want events for all.That last is very important necessity. -I want build a tabControl of intuitive way, add, remove and fill tabs from designer. -A good way for persist the morph mechanism is needed.Perhaps not now but it will be necessary more ahead if something serious is wanted. I prefer not to say when I will conclude my work, but It does not have sense to raise something incorrect or incomplete. IÂ´m put much effort in that work and i want do it good. Regards :) Torsten Bergmann wrote: > >>I believe than in two weeks i could up in SqueakSource > > Any news from the UI builder front? > > Bye > Torsten > -- > Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - > sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- View this message in context: http://n2.nabble.com/How-to-build-a-GUI-tp3548880p3549034.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 30, 2009

[Pharo-project] Package naming Scheme

by Torsten Bergmann

Currently pharo packages are named differently: - either "MyPackage" and "Tests-MyPackage" for the tests - or "MyPackage" and "MyPackage-Tests" for the tests - or something completely different like "GraphicsTests-Text" First one is used more often but not very good when using the "alphabetize" functionality in the context menu of the standard browser ;) Since the package naming scheme also affects - the monticello repo layouts - removal/shrink scripts (see ScriptLoader>>cleanupForProduction) - and method category names for extensions we should agree on at least one to use. Were the pros and cons of the different naming schemes already discussed? If so is there any docu around? I remember Lukas suggested to use the one from Seaside... Thx Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Aug. 30, 2009