LaplaceGenerator

Hi,
i had a look at LaplaceGenerator, the comment indicates that it is unclear how to implement peek. one way could eventually be to add:
PMProbabilityDensity>>flatGenerator
^flatGenerator

and change:
LaplaceGenerator>>peek
|g n|
g:= laplaceDistribution flatGenerator .
n:= laplaceDistribution flatGenerator: g deepCopy; random.
laplaceDistribution flatGenerator: g.
^ n

and the test could eg look like this:
testPeekAlwaysReplyTheSameValue
    | g |
    g := self classToTest shape: 0.5 scale: 0.3.
    self assert: g peek equals: g peek.
    self assert: g peek equals: g next.
    self assert: g peek equals: g next

unfortunately i find the general approach taken here relatively irritating:

1. although the programmer obviously _knows_ that his #peek implementation is wrong, #peek nevertheless returns a Float that is clearly wrong instead of a #notYetImplemented & #shouldBeImplemented. additionally he adds a test of #peek that returns true instead of a correct test with perhaps a #skip. all this indicates to fast users like me that one can actually _use_ this method!

2.all this whole object can do at the moment is returning a laplace distributed randomnumber, which already is implemented in PMLaplaceDistribution. this thing is just a cumbersome duplicate of PMLaplaceDistribution>>random. if it is really such a problem for the user to write 'random' instead of 'next' (yes, i see, it is 2 letters more), why dont you just make a duplicate in PMProbabilityDensity:
PMProbabilityDensity>>next
^self random
or simply rename #random?

3. if you want a method #peek, something that would indeed make sense to me, why dont you just implement a #peek in PMProbabilityDensity, this way you could have it for all distributions, not only for laplaceDistribution? and you could imho throw the complete LaplaceGenerator object away. is it really necessary for a math package to have these oneortwo-function-objects that are just duplicates? to show it seriousness or its versatility or what for? please, dont misunderstand me, i dont want to be unfriendly, i just dont understand 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.

>OTOH, what is the use of a peek method for a distribution specific random generator? Just none!

Hi Didier,
yes ok.

>Implementing peek in a generic super class is the best thing to do.

i'm not so sure. i only implemented a PMProbabilityDensity twice, but i remember it is not the most simple undertaking. if i have additionally to remember that i have also to subclass a pmrandomdistribution in a completely other package, this would make the whole undertaking not really easier.
and if one puts such a conceptual distance between the implementations of #peek & #random this makes it difficult to analyze bugs. imagine eg for some reason PMProbabilityDensity would get its own generator (not the standard one) & a general #peek would be implemented in a pmrandomdistribution. in this case #peek would not work correctly anymore for PMNormalDistribution (it does not use the generator and the generator of 'Number random' would not be copied & quasi-reset). would that be really obvious (or even noticed) with a conceptual distance between #peek and #random?

in my preceeding message i said essentially i am irritated by the implementation & the intentional bug in it. i think its ok to describe my impressions here. but now i see me talking as if we would understand the authors intention. perhaps we do, but it is difficult to talk like that above the head of the author, perhaps he had another thing in mind, eg "if you dont use your common sense you'll end up with lots of objects like this" <g>. or perhaps not, anyway i feel uneasy to talk too much in this way, hence i'll stop it now.

werner

p.s. just since i have your ear:
in the not to far future i probably have to do some factor analysis. so far i have only looked at the comments in PrincipalComponentAnalysis (your work, right?), iow i dont really know what this package does, i only have a vague idea. can i look at the importance (the eigenvalues) of the factors to sort them? and lets say i have several data for a test with a few questions. does that package let me look at the weight of each factor for a given question (iow does it project the data on the space spanned by the eigenvectors)?

--
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.

Since I am the author, I can state that the intent of the implementation that you commented is exactly what I said earlier: the need for the peek method is for basic generator in order to tweak them. The one based on distribution should not be tweaked since they would lose their intended properties.

Re. principal component analysis

The recently added work is a quick (and dirty?) result of a 1 hour session with Stephane. I would prefer people to use the Jacobi transform to compute the eigenvalues and decide what they want to do with them. The original article on principal component analysis was written at CERN to reduce redundant parameters. The reference should be in my book (now available on the net, check with Stephane, I do not know where it is.

Hopefully, you will not consider myself too pedantic or distanced. My excuse is that I am retired and my interest in numerical methods is now (out)dated. But if you need advice on a specific problem to solve, I think I can be of some use, Just be patient, I am not checking this forum on a daily basis.

Cheers,

Didier

On Fri, Mar 31, 2017 at 12:50 AM, werner kassens <[hidden email]> wrote:

>OTOH, what is the use of a peek method for a distribution specific random generator? Just none!

Hi Didier,
yes ok.

>Implementing peek in a generic super class is the best thing to do.

i'm not so sure. i only implemented a PMProbabilityDensity twice, but i remember it is not the most simple undertaking. if i have additionally to remember that i have also to subclass a pmrandomdistribution in a completely other package, this would make the whole undertaking not really easier.
and if one puts such a conceptual distance between the implementations of #peek & #random this makes it difficult to analyze bugs. imagine eg for some reason PMProbabilityDensity would get its own generator (not the standard one) & a general #peek would be implemented in a pmrandomdistribution. in this case #peek would not work correctly anymore for PMNormalDistribution (it does not use the generator and the generator of 'Number random' would not be copied & quasi-reset). would that be really obvious (or even noticed) with a conceptual distance between #peek and #random?

in my preceeding message i said essentially i am irritated by the implementation & the intentional bug in it. i think its ok to describe my impressions here. but now i see me talking as if we would understand the authors intention. perhaps we do, but it is difficult to talk like that above the head of the author, perhaps he had another thing in mind, eg "if you dont use your common sense you'll end up with lots of objects like this" <g>. or perhaps not, anyway i feel uneasy to talk too much in this way, hence i'll stop it now.

werner

p.s. just since i have your ear:
in the not to far future i probably have to do some factor analysis. so far i have only looked at the comments in PrincipalComponentAnalysis (your work, right?), iow i dont really know what this package does, i only have a vague idea. can i look at the importance (the eigenvalues) of the factors to sort them? and lets say i have several data for a test with a few questions. does that package let me look at the weight of each factor for a given question (iow does it project the data on the space spanned by the eigenvectors)?

--
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.

--
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.