robert burrell donkin wrote:
> On Tuesday, June 3, 2003, at 12:41 AM, Phil Steitz wrote:
>
>>  robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
>
>
> <snip>
>
>>> it seems to me that brent is assuring us that he went back to the
>>> mathematical basis of the algorithm and started from that. a clean
>>> implementation based on the mathematics should not infringe the
>>> copyright
>>> nor is it ethically dubious (providing that the correct credits for the
>>> original mathematics are provided if that's possible). what we need to
>>> think about is how we can demonstrate this to everybody's satisfaction.
>>> the openness of the ASF is one of it's great strengths and there
>>> should be
>>> some way we can show the right way to develop new implementations. (of
>>> course, we need to work out what that is first ;)
>>
>>
>> From Brent's notes on the gamma function implementations, I at least am
>> convinced that his implementation was developed from the math, not the NR
>> algorithm or code. The dodgy bit is that someone else who did the same
>> derivation and ended up with a similar implementation (e.g. NR) might
>> claim
>> ownership of the algorithm itself. This is why the limitation
>> expressed in the
>> NR copyright statement is important.
>
>
> definitely. i think that there are two important lessons here.
>
> the first that brent was right in the way that he went about
> demonstration that he developed his implementation from the mathematics.
> we should probably think about asking for mathematical descriptions of
> the algorithms so addition to the developers manual
Have you had a chance to look at the draft developer's guidelines that I
started and submitted here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=20404
We could add a note on this to the section called "documentation".
> if these are not
> available on the web then we should make efforts (as brent did) to
> create some notes and add them to the developers guide.
I agree. I think that the best approach will be to include full
descriptions of mathematical algorithms not available on the web using
links in the javadoc to the commonsmath developers/users guide.
>
> the second is that we're going to need to audit our implementations
> against copyrighted ones. (i'm hoping that some better qualified folks
> might volunteer for this.) if we find any that are too similar, then we
> should use apache development resources to create fresh clean room
> implementations.
I don't understand exactly what you mean here. It might be difficult to
find people with the combined legal and math skills to "audit" the code
for copyright infringement. What did you have in mind here?
>>> i believe that providing new implementation from the basic
>>> mathematics is
>>> what commonsmath should do. there is no real reason why we should start
>>> from existing code. if we can't, then maybe that's a sign that we're
>>> moving away from our aims.
>>
>>
>> The one exception to this is obviously existing code that is owned by the
>> contributor. Even in this case, however, refactoring will usually be
>> required
>> (certainly has been for me :)).
>
>
> maybe 'clean and original implementations created by commonsmath
> developers' was probably closer to what i wanted to say than 'new
> implementations'.
>
>  robert
>
>
> 
> To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
> For additional commands, email: commonsdevhelp@jakarta.apache.org
>

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
