> >> [...] > >> 1. Maintain functional compatibility with Commons Math > >> 2. Change for notation compatibility with the original paper > >> > >> Opinions on which action? > > > > I'm torn, since a lot of the Javadoc points to Wikipedia. > > However, if some sources explicitly discuss the drawback of our > > current convention, I'd be much tempted to fix it (the more so if > > the primary reference also uses the other one). > > I wouldn't worry about previous CM usage. [Numbers] is another > > library and there isn't any promise whatsoever about compatibility. > > Users who adapt their codes would certainly do so with minimal > > care. IIRC, similar fixes were done for the name and/or order of > > the arguments for some of the distribution classes in [Statistics]. > > I think that we then change it so it matches the source paper. It makes it a > lot easier to follow the adaption from the paper (which is only about 8 lines > of pseudocode) if the variables have the same name.
Indeed. > > I was initially confused when trying to set up some more unit tests to expand > coverage as I was looking at Wolfram’s formula. It all worked when I swapped > the A and B. > > Do you think it worth adding that anyone porting from CM should swap the > method implementations of getA and getB? No, but we might mention in CM's release notes[1] something like "Many functionalities have been moved to Commons Numbers, possibly with a different interface: <list of ported features>". > > My opinion is that this is not necessary if the form is more explicit in the > javadoc about what convention we are using. > A is for the numerator and B the denominator. Given this context it does make > more sense to have the lexical order for numerator over denominator as a / b > rather than b / a. + 1 Regards, Gilles [1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/changes/changes.xml;h=e6c2c8a7b4f057cf4533d44e17b6516c18dfbf71;hb=HEAD --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
