scismalltalk policy
Locked
 
|
Hi,
-- some time ago Nicolas asked about the scismalltak policies. regarding recent developments i'd guess this was a valid question. perhaps we should talk about this? anyway - i just tell you my personal policies that i follow when dealing with scismalltalk: dhb 1.scismalltalks dhb in its present form is compatible with hernans dhb (which is essentially the original dhb) in so far as the calculations return the same results eg in the DHBtests of the book examples, and this should imo remain so, as there is at the moment no other docu than the book by Didier H Besset (at least that would be my official argument, my unofficial argument is that i have a lot of respect for Msr Bessets work). of course this rule is only valid as long as the result is no bug! 2.and dhb basically does not do more than hernans dhb (some things are implemented in another way to speed up calculations though) and in my opinion this should also remain so. the additions i made within dhb are essentially that a few methods are more flexible than originally, but remain -i think- within the spirit of the mentioned book. additionally i documented all functional changes in Math-Tests-DHB-Numerical, hence if you want to see which are those changes you can run these tests on hernans dhb and see which tests are red there. 3.any other additions so far are put in their own package and this should imo remain so too. for small additions there is Math-DHB-Extensions, for calculations with complex numbers there are several packages, and then there are several other extensions that you can see when looking at the configuration and look for packages that depend on dhb. remarks: i should add that the two dhb versions are not compatible insofar as you cant load hernans dhb over scismalltalk's one, as this _does_ produce nonsense results. and there is one exception to the first rule: asVector was renamed to asDhbVector since asVector is used in Moose and dhbs asVector has lead to an incompatibility with Moose. regarding rule 2 i had made one tiny addition, which you would expect anyway, when reading the book or carefully analyzing the code (there are hints that this addition was originally intended). KDTree dont do anything (!) that makes IndexedKDTree slower than it is now (there is the Math-Benchmarks-KDTree for testing this). reason: im a speed freak with slow computers, and use it in a singular spectral analysis program that occasionally does some serious real-world-number-crunching. feel free to speed it up though. Complex, Quaternion Nicolas Cellier usually takes care that his contributions work in squeak and pharo. hence it would be preferable that changes dont make his packages unnecessarily incompatible with squeak. General 1. it would be nice if no unnecessary dependencies would be added to existing packages by eg substituting methods that are in the core by methods that are part of an extension. 2. nothing should be unnessarily made slower. i guess thats it. werner You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
Werner, HwaJong Oh You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Hwa Jong Oh, You wrote:
> I've failed to find "the book by Didier H Besset." I think this is the book: http://www.worldcat.org/title/object-oriented-implementation-of-numerical-methods-an-introduction-with-java-and-smalltalk/oclc/423850908 (It is the only WorldCat entry with that author.) http://sourceforge.net/projects/dhbnumerics/ Have fun! David -- You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Thank you.
-- 2015년 1월 22일 목요일 오후 7시 29분 36초 UTC+9, David Corking 님의 말: Hwa Jong Oh, You wrote: You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by werner kassens-2
On Fri, Jan 16, 2015 at 2:45 PM, werner kassens <[hidden email]> wrote:
> Hi, Dear Werner, > some time ago Nicolas asked about the scismalltak policies. regarding recent > developments i'd guess this was a valid question. perhaps we should talk > about this? anyway - i just tell you my personal policies that i follow when > dealing with scismalltalk: Thank you for discussing policies issues. > dhb > 1.scismalltalks dhb in its present form is compatible with hernans dhb > (which is essentially the original dhb) in so far as the calculations return > the same results eg in the DHBtests of the book examples, and this should > imo remain so, as there is at the moment no other docu than the book by > Didier H Besset (at least that would be my official argument, my unofficial > argument is that i have a lot of respect for Msr Bessets work). of course > this rule is only valid as long as the result is no bug! The book of Didier will soon be available online as a pdf. > 2.and dhb basically does not do more than hernans dhb (some things are > implemented in another way to speed up calculations though) and in my > opinion this should also remain so. the additions i made within dhb are > essentially that a few methods are more flexible than originally, but remain > -i think- within the spirit of the mentioned book. additionally i documented > all functional changes in Math-Tests-DHB-Numerical, hence if you want to see > which are those changes you can run these tests on hernans dhb and see which > tests are red there. > > 3.any other additions so far are put in their own package and this should > imo remain so too. for small additions there is Math-DHB-Extensions, for > calculations with complex numbers there are several packages, and then there > are several other extensions that you can see when looking at the > configuration and look for packages that depend on dhb. > > remarks: i should add that the two dhb versions are not compatible insofar > as you cant load hernans dhb over scismalltalk's one, as this _does_ produce > nonsense results. and there is one exception to the first rule: asVector was > renamed to asDhbVector since asVector is used in Moose and dhbs asVector has > lead to an incompatibility with Moose. regarding rule 2 i had made one tiny > addition, which you would expect anyway, when reading the book or carefully > analyzing the code (there are hints that this addition was originally > intended). This is great that Hernan has a repository with the original code in sync with Didier's book, but SciSmalltalk has to move in order to add more functionality in the future. What I want to do is to have a uniform prefix for all SciSmalltalk classes, maybe SCI or MATH. There are some distributions and random generator classes other DHB classes that might be fusion together. > KDTree > dont do anything (!) that makes IndexedKDTree slower than it is now (there > is the Math-Benchmarks-KDTree for testing this). reason: im a speed freak > with slow computers, and use it in a singular spectral analysis program that > occasionally does some serious real-world-number-crunching. feel free to > speed it up though. ;-) > Complex, Quaternion > Nicolas Cellier usually takes care that his contributions work in squeak and > pharo. hence it would be preferable that changes dont make his packages > unnecessarily incompatible with squeak. There are some code that are manage outside the SciSmalltalk repo. I think we should put all the code in the same repo in order to fix the error without depending of outside contributors. > General > 1. it would be nice if no unnecessary dependencies would be added to > existing packages by eg substituting methods that are in the core by methods > that are part of an extension. > > 2. nothing should be unnessarily made slower. We should have benchmarks to test if any regression appears. Regards -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ -- You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by HwaJong Oh
On Thu, Jan 22, 2015 at 7:44 AM, Hwa Jong Oh <[hidden email]> wrote:
> Werner, > > I've failed to find "the book by Didier H Besset. Could anyone give me a > link? The book will be available soon ;-) -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ -- You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by SergeStinckwich
Hi Serge,
-- >> 2. nothing should be unnecessarily made slower. >We should have benchmarks to test if any regression appears. good to know that you wouldnt mind if one uploads seemingly unnecessary benchmarks. having benchmarks does not necessarily lead to its use though. >There are some code that are manage outside the SciSmalltalk repo. >I think we should put all the code in the same repo in order to fix >the error without depending of outside contributors. of course this would be nice, but then isnt it most probable that those outside contributers will want to correct the errors in their code anyway? >What I want to do is to have a uniform prefix for all SciSmalltalk >classes, maybe SCI or MATH. ok im a bit dense here, i understand that SCIVector and SCIMatrix dont collide with Vector and Matrix but what is the advantage of generally complicating the typing of object names? and the readers of the book by Msr Besset might eventually be interested to try out scismalltalk if it is still compatibel with the original dhb code; renaming everything would destroy that compatibility. >SciSmalltalk has to move in order to add more functionality in the future. >There are some distributions and random generator classes other DHB >classes that might be fusion together. i see. when things get a new package structure it might eventually be beneficial to still keep the possibility to load a quasi-dhb via the config. werner You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
On Wed, Jan 28, 2015 at 9:08 AM, werner kassens <[hidden email]> wrote:
> Hi Serge, > >>> 2. nothing should be unnecessarily made slower. >>We should have benchmarks to test if any regression appears. > > good to know that you wouldnt mind if one uploads seemingly unnecessary > benchmarks. having benchmarks does not necessarily lead to its use though. The idea of having benchmarks is to detect regression in the code. >>There are some code that are manage outside the SciSmalltalk repo. >>I think we should put all the code in the same repo in order to fix >>the error without depending of outside contributors. > > of course this would be nice, but then isnt it most probable that those > outside contributers will want to correct the errors in their code anyway? @Nicolas what are your thoughts about that ? >>What I want to do is to have a uniform prefix for all SciSmalltalk >>classes, maybe SCI or MATH. > ok im a bit dense here, i understand that SCIVector and SCIMatrix dont > collide with Vector and Matrix but what is the advantage of generally > complicating the typing of object names? I think this is better to have an uniform way to name the classes. The same for classes for tests. If they are name the same, this is easier to manage in Jenkins. > and the readers of the book by Msr Besset might eventually be interested to > try out scismalltalk if it is still compatibel with the original dhb code; > renaming everything would destroy that compatibility. You may have notice that the book of Didier is now available on github here: https://github.com/SquareBracketAssociates/NumericalMethods This book will be the basis of the future documentation for SciSmalltalk. >>SciSmalltalk has to move in order to add more functionality in the future. >>There are some distributions and random generator classes other DHB >>classes that might be fusion together. > > i see. when things get a new package structure it might eventually be > beneficial to still keep the possibility to load a quasi-dhb via the config. There is a repo with the original code of Didier and the book is available now. The people are free to use this old code with the book. SciSmalltalk will move to integrate new tools in a more uniform manner and we will to modify the book accordingly. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/ -- You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Hi Serge,
-- i see, makes sense to me. does this mean that the shortened version of the book will be enlarged to cover other parts of scismalltalk? and is this covered by the licence? werner You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by werner kassens-2
Werner, My policy is 1. change and commit. 2. If people don't like it, roll it back. 3. If a change is breaking something, write test that validates it and try again. When I read SciSmalltalk and included DHB codes and etc, I feel the urge to change something like a typo in names or unused assignments or ridiculously long methods or coding convention seriously violating smalltalk style or tests that are looping 10000 times or tests that uses random thus fail occasionally or test that does not do what it should. HwaJong Oh You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by werner kassens-2
Werner,
--
Performance and compatibility I can understand, but stick to the DHB's book's examples? DHB is not a god, and his book is not bible. If DHB committed his code to squeaksource or smalltalkhub, it is under MIT license. Mathematics change and Smalltalk change over time. Making DHB read-only state leaves me nothing but to pray and worship.
If a variation is causing compatibility problem, can't we just select one variation and move on? Dependancy problem is will be there no matter what, even if we freeze SciSmalltalk entirely.
I've changed my asVector to asHjoVector in the old days to avoid collision. The name is so easy to collide in its nature.
I would like to apply GlueGun which is my compatibility patching tool served pretty well to me. Could anyone point me to the problem?
Yay to this.
Nay to this. A little bit slower but simpler code is HwaJong Oh You received this message because you are subscribed to the Google Groups "SciSmalltalk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to SciSmalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |