dhb refactoring

Hi,
i noticed that dhb has been refactored by putting its objects in different packages. a few observations:

1. shouldnt then the tests also be put in their respective packages?

2. the resulting dependencies (and there are a lot of dependencies in this refactoring) are not modelled in the config, hence it is not possible to simplify dependencies of outside packages. eg StatisticalMoments depends on: distributionForHistogram and distributionGamma which in turn depend on distributionBeta, series and dhb-numerical. this means an outside package that depends on StatisticalMoments wont work if it only depends on  StatisticalMoments and only describes this dependency in the config.

3. there are a lot of cyclical dependencies introduced, the most problematic are:
math-core depends on: math-dhb-numerical depends on:math-core
distributionGamma depends on: math-dhb-numerical  depends on: distributionGamma
core-distribution depends on: math-dhb-numerical depends on:core-distribution
these dependencies also are not completely modeled in the config, perhaps for good reason,i dont know how metacello would react. anyway this seems to be a rather problematic refactoring for me.

4. a few distributions get their own packages, others dont get that. why?

5. the reason for DhbVector's existence is essentially that DhbMatrix needs a sequentialCollection that is compatible with itself so that dhbmatrix works correctly, dhbvector has no real reason for its existence by itself alone, iow i would not put dhbvector in another package than dhbmatrix.

and there are some other minor points like point 5, that im too lazy to describe at the moment.

normally i would assume that this refactoring is a work in progress but actually it is made a stable version. hence my question, is it intended to keep dhb in this somehow sorry state?

werner

On Saturday, August 1, 2015 at 11:51:29 PM UTC+2, Serge Stinckwich wrote:

The idea is to be able to load only a few packages depending of the needs.

Hi,
updating scismalltalk and fixing bugs seems to be somehow difficult with that refactoring.  for example jenkins said this after some uploading:
...
Loaded -> Math-Core-Process-StephaneDucasse.1 --- http://smalltalkhub.com/mc/SergeStinckwich/SciSmalltalk/main/ --- cache
*** Warning: Warning: This package depends on the following classes:
  DhbNewtonZeroFinder
You must resolve these dependencies before you will be able to load these definitions:
  CdfNewtonZeroFinder
  computeInitialValues
  evaluateIteration
  setDerivative:


DhbErfApproximation>>initialize (DhbPolynomial is Undeclared)
...
but i had put CdfNewtonZeroFinder in Math-Core-Distribution (not Math-Core-Process) and nothing in Math-Core-Processor or DhbNewtonZeroFinder depends on CdfNewtonZeroFinder (its the other way around) . further it had thrown CdfNewtonZeroFinder out of Math-Core-Distribution, although it was there (i checked in smalltalkhub). i reset scismalltalk to its old state without fixing those two bugs in the statistics part, since i dont know how to work with this refactoring that has effects that i dont understand.
sorry

werner

Hi,
unfortunately i can't use scismalltalk's dhb anymore, because of those circular dependencies, that - it seems - will not be corrected anytime soon. otoh i like the idea to make outside packages only dependent on a minimum part of dhb. hence i made a private dhb without circular dependencies.

1. i dont know whether it is desirable to upload this version? perhaps Stephane will upload a corrected version in the near future? of course he can do such a refactoring much, much better than me and i certainly dont want to interfere with his intentions.

2. the main problem is, that in order to minimize dependencies i got 22 dhb-packages. if i make the number smaller, there will always be not necessary objects additionally loaded _and_ in most cases additional dependencies introduced. i dont know how to go about this? i guess 22 packages are too much?

3. in order to document where the docu is, i always prepended the package-name with a 'dhb' eg 'Math-Distributions' became 'Math-DHB-Distributions'. i dont know whether that would be acceptable? of course it would be simple to change that.

4. 22 packages would blow up the config considerably. another solution to this would eventually be to make a separate ConfigurationOfDhb? but then another problem would emerge: if eg packageA in scismalltalk would only depend on 'Math-DHB-Distributions', how would one write that in the baseline without loading the whole dhb-project, if somebody just wants to load packageA (with its dependencies, iow Math-DHB-Distributions and Math-DHB-Distributions' dependencies modelled in ConfigurationOfDhb)? although i am confident, such a situation _can_ be solved within the metacello-language, i dont know what the correct solution would be? or perhaps simply no separate config?

well, those are the 4 obvious questions, that came to mind.

werner

Hi,
i guess i did not get a reply to my questions because i was a bit too unspecific; i'll try to be a bit more specific:

one could for example make 4 packages that are completely independent of anything else:
 core consisting of
    DhbCongruentialRandomNumberGenerator,
    DhbFloatingPointMachine,
    DhbMitchellMooreGenerator,
    DhbWeightedPoint and extensions
    Number>>equalsTo:, >>random, >>relativelyEqualsTo:upTo:
    Integer>>random
 corefunctions similar to the book but without erf, which has some outside dependencies
 core-interpolation
 core-matrix
with all the rest of dhb in one package one would get 5 packages.

or if one would add packages with 1 dependency, but omitting those parts that only make sense if one uses a finer division one could add
 core-process
 series
both a bit enhanced to catch more dependencies.
hence in this case one would have 7 packages.

or if one would add packages with 2 dependencies, but only those that are reused (other objects depend on it) one could add
zerofinder
polynomial
core-distribution
integrator
hence one would have 11 packages

there are possibilities for other packages with 2 dependencies: cluster and eigenvectors (consisting of DhbJacobiTransformation and DhbLargestEigenValueFinder), but their objects are not reused so far in public packages. one would have 13 packages.

generally, depending on ones choice it would eventually be necessary to eliminate some unnecessary dependencies on dhbvector by slightly changing the implementation of some things, i dont remember that anymore exactly, but i guess it wouldnt be too complicated and it would _not_ be slower.

should one want to have a separate statistics package, of course this is possible. one could also divide the statistics part in eg 3 smaller parts. but the statistics parts depends in such a way on other things, that in the end - i dont know - perhaps 90% of dhb would be loaded anyway (if i count correctly, it would depend _directly_ on 7 of the so far mentioned packages, more indirectly by their dependencies). especially a separate statisticalmoments package is perhaps a bit difficult in a simple way without some dirty tricks, as it would be easy to introduce cyclical dependencies (moments depend on some high-level statistics parts and some high-level parts use moments).

anyway, should one want to split also the rest into packages with different dependencies one could get a statistics (7dep.), polynomialfit (3dep.), optimizer (3dep.) and a small almost depreciable extra (1dep.) part. iow 17 packages.

having said all that, please let me rephrase my questions: will the cyclical dependencies probably be repaired in the future or does anything that i proposed here or in my last message make any sense or is it preferable if things stay as they are?

werner