commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Turner <A.G.D.Tur...@leeds.ac.uk>
Subject RE: [Math] BigDecimal to power
Date Fri, 21 Jan 2011 17:22:13 GMT
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 [sebbaz@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 <gilles@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message