You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Al Chou <ho...@yahoo.com> on 2003/05/27 08:49:51 UTC
[math] licensing and buy vs. build (was Re: rolling formulas for statistics (was RE: Greetings from a newcomer (but not to numerics)))
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > --- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> >
> >>Al Chou wrote:
> >>
> >>>I agree we need to be scrupulously careful about how we use _NR_ as a
> >>
> >>resource,
> >>
> >>>and in an earlier post I had asked about how we should. I completely
> agree
> >>>with your assessment of the legitimacy of using a published formula that
> is
> >>>simply quoted by the authors of _NR_. My problem if I personally were
> >>>contributing code to commons-math is that I've lived so long with _NR_
> that
> >>
> >>it
> >>
> >>>would be difficult to distance myself from the actual code presented in
> the
> >>>books. Guess it's a good thing I don't really have time to code for the
> >>>project. If I do end up coding, I may have to take pains to write new
> code
> >>
> >>in
> >>
> >>>TDD fashion or some such, to avoid any licensing issues that might arise
> if
> >>
> >>I
> >>
> >>>attempt to write code using a reference program.
> >>>
> >>>What I'm not clear on, and I'm not sure I agree with J. Pietschmann's
> >>>assessment, is the allowability of incorporating code whose authors have
> >>>explicitly placed it in the public domain or licensed in a manner
> >>
> >>compatible
> >>
> >>>with Apache. But my opinions are heavily influenced by my career in
> >>>computational physics, where implementing an algorithm from scratch was
> the
> >>>last thing we ever wanted to do, given that almost any algorithm one would
> >>
> >>want
> >>
> >>>to use (not counting new ones or ones not widely used) has already been
> >>
> >>coded
> >>
> >>>and tested better already by someone else whose primary interest at the
> >>
> >>time
> >>
> >>>was exactly that. The buy vs. build decision in computational physics was
> >>>heavily biased towards "buy", because our interest was physics, not
> >>
> >>necessarily
> >>
> >>>numerical mathematics for its own sake. Had I been a numericist
> primarily,
> >>
> >>I'd
> >>
> >>>probably be more biased towards "build". Still, I can't help wanting to
> >>
> >>avoid
> >>
> >>>duplication when the new duplicate is likely to be of lower quality than
> >>
> >>code
> >>
> >>>that already exists and is free to use.
> >>
> >>I tend to agree, the goal is again, an Open Source library of really
> >>solid implementations. I believe if authorship and acknowledgment is
> >>maintained, the authors of public domain code may have an interest in
> >>seeing the inclusion and improvement of their implementations. I think
> >>this should be done in a case-by-case fashion. I've currently taken a
> >>more proactive approach and have begun to approach some of the authors
> >>at CERN and RndPack about their possible interest in becoming involved
> >>and/or providing code from their current projects. If it is available,
> >>if we can get permission, and if we can surmount any license
> >>transitions. Then it would be more beneficial to utilize that which is
> >>available. Its important to note that everything that is currently in
> >>the package was "donated" by the current development team and
> >>contributors. Community is the Apache Spirit.
> >>
> >>-Mark
> >
> >
> > I hope your efforts are fruitful, Mark. You raise a good point, in that
> the
> > authors whose work comprises COLT probably never imagined that the license
> they
> > agreed to distribute their code under would end up hindering others trying
> to
> > use it. Maybe it's a matter of talking to them and getting them to release
> > under multiple licenses.
> >
> From my perspective, "relicensing" by itself will not do us much good.
> We also have to think about refactoring, versioning and support. If
> people want to contribute and can get past whatever legal hurdles they
> need to donate their stuff, great. But I think it will be best to have
> contributors join the community -- and be willing to put some effort
> into refactoring/extending as necessary. We need to keep focused on
> assembling an easy-to-use, high-value toolkit. If we get tangled up in
> dependencies on large libraries or bring in too much diverse and/or
> specialized material, this will make commons-math both harder to use and
> harder to maintain.
>
> I think that we should keep focused on getting an intitial release
> together that does not include substantially more than what we have on
> the task list. There is not really that much left to implement to get
> us there. Once we have gotten past the huge hurdle of a Jakarta
> release, we can listen to the feedback of the developers who use
> commons-math and use this feedback to set priorities for what else to add.
>
> Just my not-too-apache-experienced humble opinion.
I think that even within the focused scope of the initial release there are
portions that could be boosted by not having to write original code (for
instance, a Newton's method or other root finder). Many entries found in the
Netlib repository are from ACM publications, which are subject to the following
policy:
Submittal of an algorithm for publication in one of the ACM
Transactions implies that unrestricted use of the algorithm within a
computer is permissible. General permission to copy and distribute
the algorithm without fee is granted provided that the copies are not
made or distributed for direct commercial advantage. The ACM
copyright notice and the title of the publication and its date appear,
and notice is given that copying is by permission of the Association
for Computing Machinery. To copy otherwise, or to republish, requires
a fee and/or specific permission.
Krogh, F. Algorithms Policy. ACM Tran. Math. Softw. 13(1987),
183-186.
Thus it seems to me that high quality implementations with Apache-compatible
licensing could be had by using ACM-published implementations as references.
The above is quoted from a package that transliterated the Dekker root finder
(which was published in ACM Transactions on Mathematical Software) from Algol
to Fortran and C (though I just looked at both transliterations, and they're
horrible to read, so it might take as much work to refactor them into something
comprehensible as it would to implement the algorithm from scratch).
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] ACM license
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 27 May 2003, Mark R. Diggory <md...@latte.harvard.edu>
wrote:
>>To copy otherwise, or to republish, requires
>>a fee and/or specific permission.
>>
> Basically what this is saying is "talk to us".
Yep, but it would also say that to people republishing the Apache code
that republishes or copies the licensed code - this is not a
restruction for the ASF (I'm sure they'd we'd get a positive response)
but on the things you could do with the ASF's software.
This may be subtle point, but I want to stress it again. It's not
enough that something can be distributed under the Apache Software
License, there must not be any additional requirements on top of the
Apache Software License if it is going to be distributed by the ASF.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Tim O'Brien wrote:
>On Tue, 2003-05-27 at 11:00, Mark R. Diggory wrote:
>
>
>>Basically what this is saying is "talk to us". ACM is suggesting
>>involvement and acknowledgment of their efforts in organizing and
>>archiving these algorithms...<snip>...Open Source
>>Apache project and the legal bindings they would want in such a
>>relationship..
>>
>>
>
>-1
>
>I welcome greater participation especially from the ACM, but I also
>encourage people not to "jump the gun". Commons-math is a sandbox
>component, nothing guarantees promotion to Commons proper. Commons-math
>is not attempting to be a repository for all numerical algorithms - at
>least not in the current proposal.
>
>
+1 Yes I do agree that we should not focus on being a repository for all
numerical algoithms.
>The scope as defined in the proposal is very limited to encourage
>developers to submit patches focused on a small set of realistic goals.
>aimed at a real-world requirements.
>
>
IMHO, I don't consider this discussion to be "jumping the gun" or out of
scope of the issues realted to this project. My primary point is that if
your interested in using/developing code based on an algorithm published
by the ACM, that instead of looking at the license and say, nope, can't
do that. You contact the responsible parties at ACM and ask them
directly concerning if you can apply it in this case. Seems overly
"assuming" to do otherwise. Finally, I wanted to state is that there was
also a probible future of activity between ACM and Apache Math
developers considering such cases.
>I'd like to see us explore an idea of providing an interface to other
>implementations of algorithms (i.e. commons-logging), but I think that
>is something for *the future*. Right now, we need focus, unit tests,
>pages of detailed documentation, and attention to detail.
>
>
Yes, I think that would be intersting, I suspect in the future we will
see cases wher ethis can be applied.
Cheers,
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brent Worden wrote:
> I agree. The this looks like a very solid framework. One suggestion I
> would like to make, is instead of a both a firstDirevative and
> secondDerivate method to evaluate the derivates. Create a single
> getDerivate() method that returns a UnivariateRealFunction. That way if a
> user needs the n-th derivate, they just call the getDerivate() method n
> times, once on the original function and once on each of the returned
> functions. That way, common-math supports creating whatever degree derivate a
> method might need without ever having to change the framework. We provide
> the maximum amout of derivate creation support to the user while providing
> us with the minimual amount of maintenance.
Given that numerical algorithms try to avoid derivatives
for a number of reasons, a generic method to calculate
potentially arbitrary derivatives seems to be overkill.
In fact, only very few methods even use a second derivative.
Furthermore, the implementor of the function should know best
how the derivatives are calculated. Note that the contract
allows for numerical derivatives (although this is discouraged).
If a function object is returned, implementation is decoupled,
and higher derivatives might be implemented by someone who
does not match the precision and performance perceptions of
the implementor of the base function.
I'd like to keep it all in one object for this reasons.
I know this may seem to be a bit inconvenient for people who
want to find a zero of a derivative of a function they just
see lying around, but you definitely don't want to solve a
numerical derivative for a root, you'll just get garbage.
> Why not allow the user to supply any number of initial values and design the
> solvers to compensate as best they can when not enough values are provided.
> Each algorithm has criteria about the initial values that must be met before
> root finding can be attempted. If the user provided initial values do not
> satisfy the criteria, the solver should first attempt to morph the initial
> values into a set of values that do satisfy the criteria. If this can not
> be accomplish, then the solver would raise an exception. This would take
> away some of the user's responsibility of knowing how these algorithms
> actually work and place it on us to create more robust components.
The user should have some rough ideas of the interval of the root.
It could be quite a large interval, but then the solver may complain.
There is no "best" algorithm, which can take arbitrary functions
and start values and produce a root with a reasonable amount of work.
Also, many functions have multiple roots. An exhaustive search for
all roots is often impossible. Therefore, the interval is mostly to
prevent the solver from finding a root outside of the domain of
interest for the user. There is no way to get the user's domain of
interest without explicit input.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
> "J.Pietschmann" <j3...@yahoo.de> wrote in message
> news:3ED655F4.7000903@yahoo.de...
>
>>Phil Steitz wrote:
>>
>>>Can you provide a math reference desribing this?
>>
>>H.M.Antia: Num. Methods for Scientists and Engineers.
>>
>>
>>> I have been referring
>>>to Atkinson and I am having a hard time following the implementation.
>>>What exactly do you mean by "only inverse quadratic interpolation"?
>>
>>Brent's method requires a bracketed root as a start. The primary
>>method for shrinking the bracket is inverse quadratic interpolation.
>>This means you get three points
>> x0,y0 x1,y1 x2,y2 x0<x2<x1
>>and interpolate a parabola
>> x=a*y^2+b*y+c
>>and because your goal is to find the x for y=0, your next estimate
>>for the root is c (set y=0). The convergence is of the order 1.8,
>>which is better than the secant method (~1.4 if non bracketing, 1..1.2
>>on average if bracketing).
>>The full Brent algorithm measures how well the interval shrinks, and
>>resorts to bisection if progress is too slow. I didn't implement this
>>because I forgot to take the book with me and had only a hazy memory
>>of the control parameters. All in all the algorithm combines
>>near-guaranteed convergence (occasionally problems might falsely
>>detected as ill-conditioned) with near Newton-speed.
>>
>>
>>>What do you have in mind re: plausibility?
>>
>>If the interval to search is (x0,x1), then absAccuracy should be of
>>the order of max(abs(x0),abs(x1))*relAccuracy. Achievable relative
>>accuracy depends on underlying hardware, although nowadays basically
>>everyone uses IEEE 754 (means, uh, 52 bit for double? Damn, have to
>>look it up!). Both relative and absolute accuracy of function
>>evaluation are also important, which is the reason to let the user
>>override defaults.
>>This means if relAcc is given then reject absAcc if
>> max(abs(x0),abs(x1))*relAcc+c*absAcc == max(abs(x0),abs(x1))*relAcc
>>for some predermined constant c in 0.2..1.
>>
>>
>>>I guess I like your rootfinding framework better than Brent's (Here I
>>>mean Brent Worden, the famous commons-math contributor, not the
>>>numerical analyst). I suggest that we agree to use your interfaces and
>>>UnivariateRealSolverImpl base,include Brent's bisection implementation
>>>strategy and modify his CDF inversion to use the new rootfinding
>>
> framework.
>
>>No argument against :-) I took special care for the JavaDocs, which
>>seems to pay off...
>
>
> I agree. The this looks like a very solid framework. One suggestion I
> would like to make, is instead of a both a firstDirevative and
> secondDerivate method to evaluate the derivates. Create a single
> getDerivate() method that returns a UnivariateRealFunction. That way if a
> user needs the n-th derivate, they just call the getDerivate() method n
> times, once on the original function and once on each of the returned
> functions. That way, common-math supports creating whatever degree derivate
> a
> method might need without ever having to change the framework. We provide
> the maximum amout of derivate creation support to the user while providing
> us with the minimual amount of maintenance.
Mathematically, that is certainly a natural suggestion. I am not sure,
however, how easy it will be to implement in UnivariateRealFunction
implementations (contract will be tricky regarding existence) or how
often it will actually be used. Given that the rootfinding solutions
that we seem to be converging on (pun intended) for the first release do
not require derivative computations,
one thing we might consider would be to remove derivatives entirely from
the UnivariateRealFunction interface for now.
It may be more natural for an R->R function to mark itself (infinitely?)
differentiable by implementing a DifferentiableUnivariateRealFunction
(getting a bit long, but you get the idea) interface that extends
UnivariateRealFunction than to not throw exceptions or return null or
"NaF" (not a function, of course) when you ask it for its derivative.
>
>
>>>I do have a few small questions/comments on the framework:
>>>
>>>1. Having solve() *require* brackets makes it impossible (or at least,
>>>un-natural) to add Newton's method or any other method that just starts
>>>with one initial value.
>>
>>Why? Start with -4000000,+4000000000 or so. The algorithm is not
>>*required* to start with a bracket, just with an interval. Individual
>>solver implementations should document whether they require a bracket.
>>Apart from this, there is always the possiblity to add another method.
>
>
> Why not allow the user to supply any number of initial values and design the
> solvers to compensate as best they can when not enough values are provided.
> Each algorithm has criteria about the initial values that must be met before
> root finding can be attempted. If the user provided initial values do not
> satisfy the criteria, the solver should first attempt to morph the initial
> values into a set of values that do satisfy the criteria. If this can not
> be accomplish, then the solver would raise an exception. This would take
> away some of the user's responsibility of knowing how these algorithms
> actually work and place it on us to create more robust components.
>
>
>>>2. I am curious as to why the "result" property is there. How exactly
>>>do we expect clients to make use of this?
>>
>>The client can ask for the last result as long as no further attempt
>>to solve for another root was made. I found this handy. I don't insist
>>on keeping it.
>>
>>
>>>3. What were you thinking about putting into the base solve()
>>>implementation as diagnostics? Do you mean things like checking to make
>>>sure the bracket is good?\
>>
>>No, just adding a message indicating that an unimplemented method
>>was called. Some frameworks don't display the type of the exception
>>to the user and rely on the message.
>>
>>
>>>4. Thinking of the developers who will use this stuff, I feel like we
>>>need a way to insulate them from having to think about rootfinding
>>>strategy choice. As Al has pointed out, we are not (at least yet ;-))
>>>in the AI business, so we can't automagically make the best choice for
>>>them; but it might be a good idea to somehow specify a default strategy.
>>
>
> A simple and flexible way to make the "best" choice for the user, is to
> control the creation of solver instances.
> This could be done via a factory or factory method. The creation could be
> based on the class of function the user want to evaluate (real, polynomial,
> rational, etc.) Also, we could create a solver chain that provides the
> ability to link various solvers together so if a solver fails to find a
> root, the next solver in the chain is given a chance to solve it. Either,
> eventually one of the solvers finds a root or all solvers fail and an
> exception is raised. The complexity of creating the "best chain" would be
> contained in the factory or factory method, totally hidden from the user.
> This again would relieve users of having some numerical method knowledge
> about root finding methods.
Nice idea; but do we really need to do this? See below.
>
>
>>> Unfortunately, the "safe" choice would likely be bisection.
>>
>>Brent's algorithm is quite safe in this respect.
>
>
> I'm by no means beholden to bisection. I just used it because I needed
> something to use for the distribution work. Brent's algorithm is
> guarranteed to converge to a root, provided one is bracketed by the initial
> values. So, if a bracket can be provided or generated, it is just as good
> as bisection as far as safety and it should almost always beat it in speed
> of convergence.
I agree. I suggest that we make the necessary adjustments, test the heck
out of it, beg Al, J. and whatever other numerical analysts we can find
to review it, and annoint Richard Brent's algorithm as our Solver and,
while leaving the extensibility in the framework, we do not add any
other strategies to the initial release.
>
>
>>I'll see whether I can complete the implementation near term.
>
> Unfortunately
>
>>I'll go on vacation on saturday and will be offline until 2003-06-09.
>>
>>
>>J.Pietschmann
>
>
> Brent Worden
> http://www.brent.worden.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by Brent Worden <br...@worden.org>.
"J.Pietschmann" <j3...@yahoo.de> wrote in message
news:3ED655F4.7000903@yahoo.de...
> Phil Steitz wrote:
> > Can you provide a math reference desribing this?
>
> H.M.Antia: Num. Methods for Scientists and Engineers.
>
> > I have been referring
> > to Atkinson and I am having a hard time following the implementation.
> > What exactly do you mean by "only inverse quadratic interpolation"?
>
> Brent's method requires a bracketed root as a start. The primary
> method for shrinking the bracket is inverse quadratic interpolation.
> This means you get three points
> x0,y0 x1,y1 x2,y2 x0<x2<x1
> and interpolate a parabola
> x=a*y^2+b*y+c
> and because your goal is to find the x for y=0, your next estimate
> for the root is c (set y=0). The convergence is of the order 1.8,
> which is better than the secant method (~1.4 if non bracketing, 1..1.2
> on average if bracketing).
> The full Brent algorithm measures how well the interval shrinks, and
> resorts to bisection if progress is too slow. I didn't implement this
> because I forgot to take the book with me and had only a hazy memory
> of the control parameters. All in all the algorithm combines
> near-guaranteed convergence (occasionally problems might falsely
> detected as ill-conditioned) with near Newton-speed.
>
> > What do you have in mind re: plausibility?
> If the interval to search is (x0,x1), then absAccuracy should be of
> the order of max(abs(x0),abs(x1))*relAccuracy. Achievable relative
> accuracy depends on underlying hardware, although nowadays basically
> everyone uses IEEE 754 (means, uh, 52 bit for double? Damn, have to
> look it up!). Both relative and absolute accuracy of function
> evaluation are also important, which is the reason to let the user
> override defaults.
> This means if relAcc is given then reject absAcc if
> max(abs(x0),abs(x1))*relAcc+c*absAcc == max(abs(x0),abs(x1))*relAcc
> for some predermined constant c in 0.2..1.
>
> > I guess I like your rootfinding framework better than Brent's (Here I
> > mean Brent Worden, the famous commons-math contributor, not the
> > numerical analyst). I suggest that we agree to use your interfaces and
> > UnivariateRealSolverImpl base,include Brent's bisection implementation
> > strategy and modify his CDF inversion to use the new rootfinding
framework.
>
> No argument against :-) I took special care for the JavaDocs, which
> seems to pay off...
I agree. The this looks like a very solid framework. One suggestion I
would like to make, is instead of a both a firstDirevative and
secondDerivate method to evaluate the derivates. Create a single
getDerivate() method that returns a UnivariateRealFunction. That way if a
user needs the n-th derivate, they just call the getDerivate() method n
times, once on the original function and once on each of the returned
functions. That way, common-math supports creating whatever degree derivate
a
method might need without ever having to change the framework. We provide
the maximum amout of derivate creation support to the user while providing
us with the minimual amount of maintenance.
>
> > I do have a few small questions/comments on the framework:
> >
> > 1. Having solve() *require* brackets makes it impossible (or at least,
> > un-natural) to add Newton's method or any other method that just starts
> > with one initial value.
>
> Why? Start with -4000000,+4000000000 or so. The algorithm is not
> *required* to start with a bracket, just with an interval. Individual
> solver implementations should document whether they require a bracket.
> Apart from this, there is always the possiblity to add another method.
Why not allow the user to supply any number of initial values and design the
solvers to compensate as best they can when not enough values are provided.
Each algorithm has criteria about the initial values that must be met before
root finding can be attempted. If the user provided initial values do not
satisfy the criteria, the solver should first attempt to morph the initial
values into a set of values that do satisfy the criteria. If this can not
be accomplish, then the solver would raise an exception. This would take
away some of the user's responsibility of knowing how these algorithms
actually work and place it on us to create more robust components.
>
> > 2. I am curious as to why the "result" property is there. How exactly
> > do we expect clients to make use of this?
>
> The client can ask for the last result as long as no further attempt
> to solve for another root was made. I found this handy. I don't insist
> on keeping it.
>
> > 3. What were you thinking about putting into the base solve()
> > implementation as diagnostics? Do you mean things like checking to make
> > sure the bracket is good?\
>
> No, just adding a message indicating that an unimplemented method
> was called. Some frameworks don't display the type of the exception
> to the user and rely on the message.
>
> > 4. Thinking of the developers who will use this stuff, I feel like we
> > need a way to insulate them from having to think about rootfinding
> > strategy choice. As Al has pointed out, we are not (at least yet ;-))
> > in the AI business, so we can't automagically make the best choice for
> > them; but it might be a good idea to somehow specify a default strategy.
A simple and flexible way to make the "best" choice for the user, is to
control the creation of solver instances.
This could be done via a factory or factory method. The creation could be
based on the class of function the user want to evaluate (real, polynomial,
rational, etc.) Also, we could create a solver chain that provides the
ability to link various solvers together so if a solver fails to find a
root, the next solver in the chain is given a chance to solve it. Either,
eventually one of the solvers finds a root or all solvers fail and an
exception is raised. The complexity of creating the "best chain" would be
contained in the factory or factory method, totally hidden from the user.
This again would relieve users of having some numerical method knowledge
about root finding methods.
> > Unfortunately, the "safe" choice would likely be bisection.
>
> Brent's algorithm is quite safe in this respect.
I'm by no means beholden to bisection. I just used it because I needed
something to use for the distribution work. Brent's algorithm is
guarranteed to converge to a root, provided one is bracketed by the initial
values. So, if a bracket can be provided or generated, it is just as good
as bisection as far as safety and it should almost always beat it in speed
of convergence.
> I'll see whether I can complete the implementation near term.
Unfortunately
> I'll go on vacation on saturday and will be offline until 2003-06-09.
>
>
> J.Pietschmann
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Phil Steitz wrote:
> Can you provide a math reference desribing this?
H.M.Antia: Num. Methods for Scientists and Engineers.
> I have been referring
> to Atkinson and I am having a hard time following the implementation.
> What exactly do you mean by "only inverse quadratic interpolation"?
Brent's method requires a bracketed root as a start. The primary
method for shrinking the bracket is inverse quadratic interpolation.
This means you get three points
x0,y0 x1,y1 x2,y2 x0<x2<x1
and interpolate a parabola
x=a*y^2+b*y+c
and because your goal is to find the x for y=0, your next estimate
for the root is c (set y=0). The convergence is of the order 1.8,
which is better than the secant method (~1.4 if non bracketing, 1..1.2
on average if bracketing).
The full Brent algorithm measures how well the interval shrinks, and
resorts to bisection if progress is too slow. I didn't implement this
because I forgot to take the book with me and had only a hazy memory
of the control parameters. All in all the algorithm combines
near-guaranteed convergence (occasionally problems might falsely
detected as ill-conditioned) with near Newton-speed.
> What do you have in mind re: plausibility?
If the interval to search is (x0,x1), then absAccuracy should be of
the order of max(abs(x0),abs(x1))*relAccuracy. Achievable relative
accuracy depends on underlying hardware, although nowadays basically
everyone uses IEEE 754 (means, uh, 52 bit for double? Damn, have to
look it up!). Both relative and absolute accuracy of function
evaluation are also important, which is the reason to let the user
override defaults.
This means if relAcc is given then reject absAcc if
max(abs(x0),abs(x1))*relAcc+c*absAcc == max(abs(x0),abs(x1))*relAcc
for some predermined constant c in 0.2..1.
> I guess I like your rootfinding framework better than Brent's (Here I
> mean Brent Worden, the famous commons-math contributor, not the
> numerical analyst). I suggest that we agree to use your interfaces and
> UnivariateRealSolverImpl base,include Brent's bisection implementation
> strategy and modify his CDF inversion to use the new rootfinding framework.
No argument against :-) I took special care for the JavaDocs, which
seems to pay off...
> I do have a few small questions/comments on the framework:
>
> 1. Having solve() *require* brackets makes it impossible (or at least,
> un-natural) to add Newton's method or any other method that just starts
> with one initial value.
Why? Start with -4000000,+4000000000 or so. The algorithm is not
*required* to start with a bracket, just with an interval. Individual
solver implementations should document whether they require a bracket.
Apart from this, there is always the possiblity to add another method.
> 2. I am curious as to why the "result" property is there. How exactly
> do we expect clients to make use of this?
The client can ask for the last result as long as no further attempt
to solve for another root was made. I found this handy. I don't insist
on keeping it.
> 3. What were you thinking about putting into the base solve()
> implementation as diagnostics? Do you mean things like checking to make
> sure the bracket is good?\
No, just adding a message indicating that an unimplemented method
was called. Some frameworks don't display the type of the exception
to the user and rely on the message.
> 4. Thinking of the developers who will use this stuff, I feel like we
> need a way to insulate them from having to think about rootfinding
> strategy choice. As Al has pointed out, we are not (at least yet ;-))
> in the AI business, so we can't automagically make the best choice for
> them; but it might be a good idea to somehow specify a default strategy.
> Unfortunately, the "safe" choice would likely be bisection.
Brent's algorithm is quite safe in this respect.
I'll see whether I can complete the implementation near term. Unfortunately
I'll go on vacation on saturday and will be offline until 2003-06-09.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by Phil Steitz <ph...@steitz.com>.
J.Pietschmann wrote:
> Brent Worden wrote:
>
>> In the chi-square patch, I created a root finding utility class. I
>> used the
>> bisection method to provide a default mechanism for computing inverse
>> CDFs.
>> It's driven by a simple Function interface. Check it out and see if it's
>> something you can use or improve.
>
>
> Here's my take on root finding. Note that BrentSolver uses only
> inverse quadratic interpolation rather than the full Brent algorithm.
Can you provide a math reference desribing this? I have been referring
to Atkinson and I am having a hard time following the implementation.
What exactly do you mean by "only inverse quadratic interpolation"? Am
I correct in assuming that what you mean by this is that you *never* use
Secant or Bisection? Looks to me like this is the case, but I am having
a little difficulty following the code. If it is the case, what impact
does this have on convergence/stability?
>
> THere are a few issues with accuracy, there should really be a
> relative accuracy too, as well as some plausiblity checks.
What do you have in mind re: plausibility?
I guess I like your rootfinding framework better than Brent's (Here I
mean Brent Worden, the famous commons-math contributor, not the
numerical analyst). I suggest that we agree to use your interfaces and
UnivariateRealSolverImpl base,include Brent's bisection implementation
strategy and modify his CDF inversion to use the new rootfinding framework.
I do have a few small questions/comments on the framework:
1. Having solve() *require* brackets makes it impossible (or at least,
un-natural) to add Newton's method or any other method that just starts
with one initial value. Brent W. includes a method that will try to
find a bracket from initial values. I suppose that we could add a
solve() with only one initial value and if necessary push it out to a
bracket. Personally, given the multiple good implementations available
now, I am OK with dropping Newton altogether, so this could be a moot
point at least for the initial release.
2. I am curious as to why the "result" property is there. How exactly
do we expect clients to make use of this?
3. What were you thinking about putting into the base solve()
implementation as diagnostics? Do you mean things like checking to make
sure the bracket is good?
4. Thinking of the developers who will use this stuff, I feel like we
need a way to insulate them from having to think about rootfinding
strategy choice. As Al has pointed out, we are not (at least yet ;-))
in the AI business, so we can't automagically make the best choice for
them; but it might be a good idea to somehow specify a default strategy.
Unfortunately, the "safe" choice would likely be bisection. We
could obviously annoint bisection as the "default" by naming it
something like "Solver", but there might be simpler/better ways to do this.
<flame-invitation> I bet that in most real world applications the
difference in convergence speed is not a big deal and guaranteed
convergence/domain of application is more important than expected speed
of convergence. Consider, for example, our own use in CDF inversion to
get critical values for stat tests. </flame-invitation>.
Phil
>
> J.Pietschmann
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Brent Worden wrote:
> In the chi-square patch, I created a root finding utility class. I used the
> bisection method to provide a default mechanism for computing inverse CDFs.
> It's driven by a simple Function interface. Check it out and see if it's
> something you can use or improve.
Here's my take on root finding. Note that BrentSolver uses only
inverse quadratic interpolation rather than the full Brent algorithm.
THere are a few issues with accuracy, there should really be a
relative accuracy too, as well as some plausiblity checks.
J.Pietschmann
Re: [math] Priority
Posted by Phil Steitz <ph...@steitz.com>.
Brent Worden wrote:
>>and unit tests. While things like rootfinding for
>>non-differentiable functions
>>may eventually have a place and may benefit from algorithms that
>>someone can
>>claim copyright ownership of, if no one else does it before I get
>>to it, I will
>>translate my simple newton's method implementation (which is trivial) and
>>submit it. I would appreciate input on what a nice Java interface
>>would look
>>like for rootfinding, initally assuming that the function has a
>>derivative, but
>>ideally extensible to support strategies that do not require
>>differentiability.
>
>
> In the chi-square patch, I created a root finding utility class. I used the
> bisection method to provide a default mechanism for computing inverse CDFs.
> It's driven by a simple Function interface. Check it out and see if it's
> something you can use or improve.
>
> The relevant types are org.apache.jakarta.commons.math.RootFinding and
> org.apache.jakarta.commons.math.Function and there it's utilized in
> org.apache.jakarta.commons.math.stat.distribution.AbstractContinuousDistribu
> tion.
>
> Let me know what you think.
>
Looks fine to me,at least. I was looking for some magical way to avoid
the "Function" interface requirement; but after thinking about this some
more and looking at your implementation, I think that is about as
convenient as we can make it for users. Newton's method or other
algorithms could be added as alternative RootFinding strategies. I
didn't think of bisection, which is a great idea for the CDF inversion
application, since these functions tend to be well-behaved. Thanks for
setting this up.
Phil
> Brent Worden
> http://www.brent.worden.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] Priority
Posted by Al Chou <ho...@yahoo.com>.
--- Brent Worden <br...@worden.org> wrote:
> > and unit tests. While things like rootfinding for
> > non-differentiable functions
> > may eventually have a place and may benefit from algorithms that
> > someone can
> > claim copyright ownership of, if no one else does it before I get
> > to it, I will
> > translate my simple newton's method implementation (which is trivial) and
> > submit it. I would appreciate input on what a nice Java interface
> > would look
> > like for rootfinding, initally assuming that the function has a
> > derivative, but
> > ideally extensible to support strategies that do not require
> > differentiability.
>
> In the chi-square patch, I created a root finding utility class. I used the
> bisection method to provide a default mechanism for computing inverse CDFs.
> It's driven by a simple Function interface. Check it out and see if it's
> something you can use or improve.
>
> The relevant types are org.apache.jakarta.commons.math.RootFinding and
> org.apache.jakarta.commons.math.Function and there it's utilized in
> org.apache.jakarta.commons.math.stat.distribution.AbstractContinuousDistribu
> tion.
>
> Let me know what you think.
>
> Brent Worden
> http://www.brent.worden.org
Brent,
I think I have a few improvements that came to mind while I was coding a
Ridders' method implementation. Should I send you a diff file privately?
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [math] Priority
Posted by Brent Worden <br...@worden.org>.
> and unit tests. While things like rootfinding for
> non-differentiable functions
> may eventually have a place and may benefit from algorithms that
> someone can
> claim copyright ownership of, if no one else does it before I get
> to it, I will
> translate my simple newton's method implementation (which is trivial) and
> submit it. I would appreciate input on what a nice Java interface
> would look
> like for rootfinding, initally assuming that the function has a
> derivative, but
> ideally extensible to support strategies that do not require
> differentiability.
In the chi-square patch, I created a root finding utility class. I used the
bisection method to provide a default mechanism for computing inverse CDFs.
It's driven by a simple Function interface. Check it out and see if it's
something you can use or improve.
The relevant types are org.apache.jakarta.commons.math.RootFinding and
org.apache.jakarta.commons.math.Function and there it's utilized in
org.apache.jakarta.commons.math.stat.distribution.AbstractContinuousDistribu
tion.
Let me know what you think.
Brent Worden
http://www.brent.worden.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Priority
Posted by Phil Steitz <st...@yahoo.com>.
--- Tim O'Brien <to...@discursive.com> wrote:
> On Tue, 2003-05-27 at 11:00, Mark R. Diggory wrote:
> > Basically what this is saying is "talk to us". ACM is suggesting
> > involvement and acknowledgment of their efforts in organizing and
> > archiving these algorithms...<snip>...Open Source
> > Apache project and the legal bindings they would want in such a
> > relationship..
>
> -1
>
> I welcome greater participation especially from the ACM, but I also
> encourage people not to "jump the gun". Commons-math is a sandbox
> component, nothing guarantees promotion to Commons proper. Commons-math
> is not attempting to be a repository for all numerical algorithms - at
> least not in the current proposal.
>
> The scope as defined in the proposal is very limited to encourage
> developers to submit patches focused on a small set of realistic goals.
> aimed at a real-world requirements.
>
> I'd like to see us explore an idea of providing an interface to other
> implementations of algorithms (i.e. commons-logging), but I think that
> is something for *the future*. Right now, we need focus, unit tests,
> pages of detailed documentation, and attention to detail.
>
I agree. I at least plan to keep plugging away providing simple standard-
algorithm implementations for stuff on the task list and filling out the docs
and unit tests. While things like rootfinding for non-differentiable functions
may eventually have a place and may benefit from algorithms that someone can
claim copyright ownership of, if no one else does it before I get to it, I will
translate my simple newton's method implementation (which is trivial) and
submit it. I would appreciate input on what a nice Java interface would look
like for rootfinding, initally assuming that the function has a derivative, but
ideally extensible to support strategies that do not require differentiability.
Phil
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[math] Priority
Posted by Tim O'Brien <to...@discursive.com>.
On Tue, 2003-05-27 at 11:00, Mark R. Diggory wrote:
> Basically what this is saying is "talk to us". ACM is suggesting
> involvement and acknowledgment of their efforts in organizing and
> archiving these algorithms...<snip>...Open Source
> Apache project and the legal bindings they would want in such a
> relationship..
-1
I welcome greater participation especially from the ACM, but I also
encourage people not to "jump the gun". Commons-math is a sandbox
component, nothing guarantees promotion to Commons proper. Commons-math
is not attempting to be a repository for all numerical algorithms - at
least not in the current proposal.
The scope as defined in the proposal is very limited to encourage
developers to submit patches focused on a small set of realistic goals.
aimed at a real-world requirements.
I'd like to see us explore an idea of providing an interface to other
implementations of algorithms (i.e. commons-logging), but I think that
is something for *the future*. Right now, we need focus, unit tests,
pages of detailed documentation, and attention to detail.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] ACM license
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
DavidNeuer@nascopgh.com wrote:
>>"Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>>
>>
>>
>>>To copy otherwise, or to republish, requires
>>>a fee and/or specific permission.
>>>
>>>
>>>
>>Basically what this is saying is "talk to us". ACM
>>is suggesting
>>involvement and acknowledgment of their efforts in
>>organizing and
>>archiving these algorithms. I think often these
>>license clauses (while
>>legally protecting the the license') are also
>>grounds for establishing
>>'legal' avenues of involvement and partnership.
>>
>>
>
>Absolutely. I'm an ACM member as well, and it's a great organization. It's
>certainly possible they *might* choose to donate code to the Apache
>project. I merely meant to point out that the license has restrictions
>that would prohibit simply incorportating the software into an Apache
>Group project w/out such permission from ACM.
>
>
True
>
>
>>As such, if we
>>have an interest in using ACM material, we should
>>contact ACM and get an
>>official position on the usage of such material for
>>an Open Source
>>Apache project and the legal bindings they would
>>want in such a
>>relationship..
>>
>>
>
>Well, again, my understanding of the Apache project and its mission leads
>me to believe that those "legal bindings" would have to be "you may
>release this under the Apache license" w/ no additional restrictions
>placed by the ACM.
>
>
Yes, that would be quite direct and obvious.
>
>
>>We also have to consider here, what *copies are not
>>made or distributed
>>for direct commercial advantage* means in this case
>>as well.
>>
>>
>
>IANAL, but the plain language seems quite clear. "Direct commercial
>advantage" means you are selling the software as a product (with or w/out
>source, alone or in combination w/ other software), not e.g. teaching a
>course (for which you and some institution get paid) or using the code for
>some other purpose which happens to generate revenue but where the primary
>activity is not distribution of the code (like leasing computer time on a
>supercomputer which happens to have the software installed as a library --
>no distribution there).
>
>
I still am not convinced that direct commercial advantage means --> sell
a tool/source based on it for a profit. This is the danger of poorly
worded licenses. What does commercial *advantage* mean? (Hope I'm not
sounding too "Clintonesque").
>
>
>>Remember, the core necessity of
>>Open Source
>>licensing is about protecting the authors rights,
>>not about restricting
>>the reuse and development of Open Source code.
>>
>>
>>
>
>Careful there pilgrim! That kind of talk starts license wars (as very
>reasonable people can quite strongly disagree about "the core neccessity
>of OSS" -- it's the tension between authors' rights and users' rights that
>causes the split between GPL proponents and Apache license proponents).
>
>
"Well, thems a fightn' words there cowboy!" I can't promise, but I'll
try not to make so many "generalized" statements in the future ;-)
>To end on a non-flamewar-inspiring note, the correct thing to do WRT ACM
>stuff is obviously to ask the ACM on a case-by-case basis if they'd be
>interested in donating it.
>
>Dave
>
>
See, my response to priorities. I do agree.
Cheers,
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] ACM license
Posted by Da...@nascopgh.com.
> "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>
> >To copy otherwise, or to republish, requires
> >a fee and/or specific permission.
> >
> Basically what this is saying is "talk to us". ACM
> is suggesting
> involvement and acknowledgment of their efforts in
> organizing and
> archiving these algorithms. I think often these
> license clauses (while
> legally protecting the the license') are also
> grounds for establishing
> 'legal' avenues of involvement and partnership.
Absolutely. I'm an ACM member as well, and it's a great organization. It's
certainly possible they *might* choose to donate code to the Apache
project. I merely meant to point out that the license has restrictions
that would prohibit simply incorportating the software into an Apache
Group project w/out such permission from ACM.
> As such, if we
> have an interest in using ACM material, we should
> contact ACM and get an
> official position on the usage of such material for
> an Open Source
> Apache project and the legal bindings they would
> want in such a
> relationship..
Well, again, my understanding of the Apache project and its mission leads
me to believe that those "legal bindings" would have to be "you may
release this under the Apache license" w/ no additional restrictions
placed by the ACM.
>
> We also have to consider here, what *copies are not
> made or distributed
> for direct commercial advantage* means in this case
> as well.
IANAL, but the plain language seems quite clear. "Direct commercial
advantage" means you are selling the software as a product (with or w/out
source, alone or in combination w/ other software), not e.g. teaching a
course (for which you and some institution get paid) or using the code for
some other purpose which happens to generate revenue but where the primary
activity is not distribution of the code (like leasing computer time on a
supercomputer which happens to have the software installed as a library --
no distribution there).
>
> Remember, the core necessity of
> Open Source
> licensing is about protecting the authors rights,
> not about restricting
> the reuse and development of Open Source code.
>
Careful there pilgrim! That kind of talk starts license wars (as very
reasonable people can quite strongly disagree about "the core neccessity
of OSS" -- it's the tension between authors' rights and users' rights that
causes the split between GPL proponents and Apache license proponents).
To end on a non-flamewar-inspiring note, the correct thing to do WRT ACM
stuff is obviously to ask the ACM on a case-by-case basis if they'd be
interested in donating it.
Dave
Re: [math] ACM license
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I caution at assuming this is 'restrictive'. I would like to point out
an important clause in this license that you should consider, I've
received emails from ACM members who are following our project (I am
actually an inactive ACM member myself). ACM is a member based
organization just like Apache.
>To copy otherwise, or to republish, requires
>a fee and/or specific permission.
>
Basically what this is saying is "talk to us". ACM is suggesting
involvement and acknowledgment of their efforts in organizing and
archiving these algorithms. I think often these license clauses (while
legally protecting the the license') are also grounds for establishing
'legal' avenues of involvement and partnership. This clause basically
makes it the responsibility of ACM to decide if the terms and conditions
of the license are to be applied. It gives them jurisdiction to alter
the conditions for the license on a case by case basis. As such, if we
have an interest in using ACM material, we should contact ACM and get an
official position on the usage of such material for an Open Source
Apache project and the legal bindings they would want in such a
relationship..
We also have to consider here, what *copies are not made or distributed
for direct commercial advantage* means in this case as well. This really
appears similar (yet vague) to the Apache clause that suggests that you
cannot use the Apache name as a label to promote your project. IE you
can say 'Foobar, Powered by Apache', but you can't say 'Apache FooBar ',
which suggests that Apache endorses your FooBar as an Apache product. I
feel this is suggesting that you can't use the ACM algorithms as a basis
to gain commercial advantage over another product, not that you are
excluded from using them in a commercial product or to use them here?
Perhaps, as ACM has such a large repository of public source. Apache and
ACM should get together and establish an avenue of opinion when it comes
to this case and other cases where ACM algorithms may be applied in
Apache Source code. Remember, the core necessity of Open Source
licensing is about protecting the authors rights, not about restricting
the reuse and development of Open Source code.
-Mark
Al Chou wrote:
>--- DavidNeuer@nascopgh.com wrote:
>
>
>>>--- Phil Steitz <ph...@steitz.com> wrote:
>>>
>>>Many entries found in
>>>the
>>>Netlib repository are from ACM publications, which
>>>are subject to the
>>>following
>>>policy:
>>>
>>> Submittal of an algorithm for publication
>>>in one of the ACM
>>> Transactions implies that unrestricted use of
>>>the algorithm within a
>>> computer is permissible. General permission
>>>to copy and distribute
>>> the algorithm without fee is granted provided
>>>that the copies are
>>>not
>>> made or distributed for direct commercial
>>> advantage. The
>>>ACM
>>> copyright notice and the title of the
>>>publication and its date
>>>appear,
>>> and notice is given that copying is by
>>>permission of the
>>>Association
>>> for Computing Machinery. To copy otherwise, or
>>>to republish,
>>>requires
>>> a fee and/or specific permission.
>>>
>>>
>>I don't know if I would call that Apache-compatible licensing terms. The
>>language seems to specifically preclude distribution for profit, which is
>>a restriction over and above the Apache license.
>>
>>
>
>Darn, I should have read the Apache license first. I didn't realize until this
>morning how un-restrictive it is. Oh, well.
>
>
>Al
>
>=====
>Albert Davidson Chou
>
> Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] ACM license
Posted by Al Chou <ho...@yahoo.com>.
--- DavidNeuer@nascopgh.com wrote:
> > --- Phil Steitz <ph...@steitz.com> wrote:
> >
> > Many entries found in
> > the
> > Netlib repository are from ACM publications, which
> > are subject to the
> > following
> > policy:
> >
> > Submittal of an algorithm for publication
> > in one of the ACM
> > Transactions implies that unrestricted use of
> > the algorithm within a
> > computer is permissible. General permission
> > to copy and distribute
> > the algorithm without fee is granted provided
> > that the copies are
> > not
> > made or distributed for direct commercial
> > advantage. The
> > ACM
> > copyright notice and the title of the
> > publication and its date
> > appear,
> > and notice is given that copying is by
> > permission of the
> > Association
> > for Computing Machinery. To copy otherwise, or
> > to republish,
> > requires
> > a fee and/or specific permission.
>
> I don't know if I would call that Apache-compatible licensing terms. The
> language seems to specifically preclude distribution for profit, which is
> a restriction over and above the Apache license.
Darn, I should have read the Apache license first. I didn't realize until this
morning how un-restrictive it is. Oh, well.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] ACM license
Posted by Da...@nascopgh.com.
> --- Phil Steitz <ph...@steitz.com> wrote:
>
> Many entries found in
> the
> Netlib repository are from ACM publications, which
> are subject to the
> following
> policy:
>
> Submittal of an algorithm for publication
> in one of the ACM
> Transactions implies that unrestricted use of
> the algorithm within a
> computer is permissible. General permission
> to copy and distribute
> the algorithm without fee is granted provided
> that the copies are
> not
> made or distributed for direct commercial
> advantage. The
> ACM
> copyright notice and the title of the
> publication and its date
> appear,
> and notice is given that copying is by
> permission of the
> Association
> for Computing Machinery. To copy otherwise, or
> to republish,
> requires
> a fee and/or specific permission.
>
I don't know if I would call that Apache-compatible licensing terms. The
language seems to specifically preclude distribution for profit, which is
a restriction over and above the Apache license.