commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math] BigDecimal to power
Date Fri, 21 Jan 2011 19:15:47 GMT
Hi Andy,

Le 21/01/2011 18:22, Andy Turner a écrit :
> 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...

It may interesting to add this feature. I didn't look precisely but how
does it compare to our arbitrary precision dflp package ?

> 
> 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 are guidelines here: <http://commons.apache.org/math/developers.html>

There is also a code style configuration file available here
<http://people.apache.org/~luc/Apache-commons.xml>, but it is for Eclipse.

In order to check your code is compliant with some of our rules, you can
use checkstyle. There is a checkstyle configuration file at the top of
the source distribution.

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

Neither System.out nor System.err are allowed. Apache Commons Math is a
low level library and it can be used in many different systems. It can
be used in applications that are not connected to a console. Errors are
provided by exceptions and the application developers can do what they
want with them, printing them by temselves to System.out or System.err
for example, but also displaying a popup window in a graphical
environment, sending a notification through network in a distributed
environment, logging something in a file, or a database, or a system log ...

Also the units tests should be able to run unattended in continuous
integrations systems like Gump, Confluence, Hudson or in our maven build
system... So even in tests, we don't allow output. We use only the
automatic output features of Junit when test fails (these outputs are in
fact already wrapped by these integration frameworks).

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

Logging is a controversial issue here. We have had numerous discussions
about it in the past. You can see for example this thread:
<http://markmail.org/thread/a5jl6fkjjtm5qbsw>, or the part of another
thread that starts roughly at this message:
<http://markmail.org/message/6besiqutg4bh52zw> or even this very old
message: <http://markmail.org/message/ml7gxlmszk7xkcly>.

The bottom line is: no logging in Commons Math.

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

This would be fine if you can do it. We didn't did it on many of our
tests and it is one of our problems.

> 
> The library ojalgo (http://ojalgo.org/) might be used for some tests
> - it provides higher precision for some arithmetic than the standard
> offerings.

We do have an arbitrary precision package in Commons Math, the dflp
pacakge. You specify the precision you need, and you have available all
traditional functions (including trigonometric, hyperbolic, exponentials
...)

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

We mainly break up tests at top functional level only.

best regards,
Luc

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


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


Mime
View raw message