interval arithmetic revisited

Hi,
i added a setting, enableRealInterval (by default false), to the RealInterval package in scismalltalk: if it is set to true, some standard pharo methods will be overwritten & the package will work, if it is set to false the methods will be reset to their original form.  this overwriting and resetting happens via RBTransformationRules, hence if these methods are changed, those changes will be incorporated in the overwriting, which makes this approach much more robust than the simple original approach. for example in some tests the #setUp stores the old setting and sets it to true, then the test is run and in the #tearDown the old setting is restored. this simple use of a setting also allowed me to simplify the ConfigurationOfRealInterval and get rid of the dirty trick i had used there, hence i made a completely new ConfigurationOfRealInterval. the obvious disadvantage with this approach is that it fills up the .changes file. otoh in scismalltalk it at least works (see eg the fat tests in https://ci.inria.fr/pharo-contribution/job/SciSmalltalk/PHARO=50,VERSION=stable,VM=vm/1706/testReport/ ) & in my experience it is not necessary to always reset enableRealInterval to false.
now i would like to ask, whether it would make sense if i make a version for polymath (with the necessary renamings and such) or whether this approach is considered too brittle for a polymath package? (in my opinion it is probably too brittle to load it automatically, but not too brittle to completely throw it away)
werner

Hi Serge,
at the moment i'm on the road, hence i can only give a short answer. i used scismalltalk, because this way i could test whether things work as i expected by looking at the jenkins job and it was not necessary to go over the the polymath inbox and ask somebody to run several versions. and yes i made this change recently.

​Too brittle ? I don't understand.

Hi Serge,
now i have more time to answer your questions.

>Sorry I'm a fix confused ... can you give more context.
sure: in the first version i simply overwrote some basic pharo methods, the most problematic was perhaps Float>>/ . this method is a primitive and if the vm people change eg the primitive number part, the image would probably crash the moment the primitive will be overwritten. in the second version, using rules for the overwriting, things are handled in a much more lenient way. (and the changes itself are not really problematic, eg in Float>>/  "aNumber =0.0 ..." it overwritten by "aNumber isZero ...".) the main advantage related to other ways is this: of course the overwriting itself is slow, but the calcs with the original version is not slowed down at all & the calcs with the overwritten versions are fast too. of course there are other, cleaner possibilities to solve this general problem that one should not overwrite pharo methods although it is conceptually necessary: one could write an error handler that does the necessary things, or one could use a mock package, or one could use a metalink if bug 19283 would be corrected ( i looked into that bug and imo there is the possibility that the original metalink author does not really think it is a bug & additionally i could not see the simple obvious solution to that bug to make my own version). these three other solutions would probably not slow down the original calcs but they probably would somewhat slow down the overwritten methods. and they would probably look a little bit more complicated, the whole overwriting logic of the momentary version is in one simple setting object. i did not test that assumption (of a noticeable slowdown) though, because at the moment i'm more or less satisfied with the rulebased overwriting solution. my question to you, whether i should make a polymath version, is simply based on the fact that i dont know, whether you would find this solution acceptable (for some applications i think another solution would be preferable)?

>Why are you committing to SciSmalltalk ? Because we use PolyMath now :-)​
i am the typical trial&error-programmer: i made the new packages & uploaded it. i made the configuration of realinterval and tested it on my pc with the uploaded packages. when it worked, i uploaded the config and made a configurationofscismalltalk and tested it on my pc. then i uploaded it and watched jenkins. all this pretesting would have been more complicated and time-consuming if i had uploaded things stepwise to the inbox of polymath first and would have to talk with the integrator first about the procedure i should follow.
but i agree completely, i am the obviously the only person who uses scismalltalk about once a year, and one should stop that superfluous waste of jenkins ressources. i would prefer though if you dont delete the repository.
werner

Hi Serge,
and i interpret your mentioning, that we now use polymath, in such a way that it would make sense to make a polymath version and
will make one around the end of october (at the moment i dont have the time & the computer).
Werner

Hi,
i uploaded Math-RealInterval, Math-RealInterval-Extensions, Math-Tests-RealInterval, Math-Benchmarks-RealInterval & ConfigurationOfRealInterval to PolyMath/PolyMathInbox. of course i was not able to test the correctness of the config, but i hope <stupid grin> i got that more or less correct.
i would assume there are two possibilities to incorporate that:
1. only ConfigurationOfRealInterval is by default loaded with ConfigurationOfPolyMath. in that case one would need to load RealInterval by hand and i would add a little notice about that in the docu.
2. if one would load the project by default one would need to add something like this to the ConfigurationOfPolyMath:
in #baseline:
project: 'RealInterval'
                    with: [
                            spec
                                className: #ConfigurationOfRealInterval;
                                versionString: #development;
                                repository: 'http://www.smalltalkhub.com/mc/PolyMath/PolyMath/main'].
and eg in the 'Extensions' group add 'RealInterval'
in #version:
project: 'RealInterval' with: [spec versionString:#stable].

since by default nothing is overwritten in pharo this should not produce problems, but the tests would be run by that automatic image-producer.
werner

Hi Serge,
i noticed that as usual i made some typos in ConfigurationOfRealInterval, hence i uploaded a corrected config to inbox. i also added the inbox as repository, so after downloading this new config in a pharo6.1 a simple "ConfigurationOfRealInterval load." will load everything (without having first to move a package or so).
i'd like to know what you think and sorry for any inconvenience
werner