I can spend some time to change the code. I'll wait to here from others if the functionality is wanted as part of Commons Math before I do too much...
I am using the Netbeans IDE with which it is trivial to make some of the changes you suggest (package and class naming, removing the @author tags and main methods). I'll generate javadocs and make sure there are no issues with that. I'll make sure there is a clear description of each method and that any conditions or information about parameter values is detailed. I'll go through all the code and consider adding more comments in the methods to explain what is going on. Before I do this last bit, I'll have a look at some of the Maths source code to try and get a clearer idea of what is wanted in terms of in code documentation. Is there a particularly well documented class that anyone suggests I look at, or is there another resource you advise I use as a guide? There must be reasons why System.out calls are not wanted. I shall make sure to use System.err when this is more appropriate. I have had issues with logging in the past (in non-test code) to do with it using too many of a very limited addressing (I think it was to do with file handlers with parallelised code executed on compute elements with multiple processors). Anyway, maybe I was doing something wrong and I should learn to do logging better. I shall mark those tests that are "self tests" and distinguish them from tests that are based on my human reckoning. I'll also try to add more tests that use other standard Java and Commons code. I was thinking to add comments in the testing code along the following lines: // Source of tests expected result = "self test" // Source of tests expected result = "human calculation" // Source of tests expected result = "java.lang.Math.min(int,int)" // Source of tests expected result = "Perl" The library ojalgo (http://ojalgo.org/) might be used for some tests - it provides higher precision for some arithmetic than the standard offerings. I'll look into using the Perl you mention. I can see some methods that could be used for equivallence testing, although not all methods I have developed have an equivallent (noteably, there is no power function for BigFloat as yet): http://perldoc.perl.org/Math/BigInt.html#bpow%28%29 http://perldoc.perl.org/Math/BigFloat.html#bexp%28%29 For each class I aimed to provide a test method for every public method, but that within that test method, there may be multiple tests for different parameter inputs. With regard some tests being too large, what is the prefered way to break these up? Thanks for showing some interest :-) Best wishes, Andy ________________________________________ From: sebb [seb...@gmail.com] Sent: 21 January 2011 13:36 To: Commons Developers List; user@commons.apache.org Subject: Re: [Math] BigDecimal to power On 21 January 2011 13:19, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: > Hello. > > When proposing code, I think that you might get better attention by posting > to the "dev" ML. > >> I changed the license for my code and wrote some junit tests while >> refactoring. >> >> I think there are many improvements since I originally emailed. I have not >> had any off list expressions of interest and I wonder if there is yet any >> other interest in making this available as part of Commons Math? > > If the functionality is desired (let's wait for the others to answer this), > there would nevertheless be quite some changes needed for the code to fit in > Commons Math; a few things I noticed by glancing at the source: > > * "main" methods > * access to "System.out" for printing > * not fully documented > * class names contain an underscore Also package names are not org.apache.commons.mathx. There are also some @author tags which ought to be removed - credit can be give elsewhere. [Author tags quickly become unmanageable in code that is developed by a community] >> [...] >> >> The main reason I developed this code was that I needed to raise a >> BigDecimal to the power of another BigDecimal. Dealing with all the >> different cases has been a challenge. Although I'm not 100% confident I have >> handled every case, I'm reasonably happy with this effort. >> >> In terms of junit tests: where the expected result was not obvious to me and >> I could think of no obvious other way to calculate it using the java core >> code, I have used results returned from my methods to set expected results. >> This is better than nothing, but developers of this code should be warned >> that test failures may be a result of original errors rather than as a >> consequence of changes they have made. I wonder if there are some canonical >> math compliance test data that I should use... I was thinking that I should >> document or use some attribution or something to distinguish the different >> types of test if I got this far. >> >> Does anyone have any good advice for me at this stage? > > It certainly would be better to compare with the results of another library. > At least, the "self-tests" should be marked as such. > > I know that Perl has "Math::BigInt" and "Math::BigFloat" modules that might > be used to compute independent results. Also, some of the test cases are very large - it's better to have lots of smaller tests, so all errors can be found at once. > > Thanks, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
