I would suggest that your argument is more for Apache Math than for a new mailing list. (Note Apache Math, not Jakarta Math)
For me, [math] goes beyond the role of a simple library of common code.
Not that far, IMHO. Most of what is there now is basic, widely useful utility code.
Instead it presents a wealth of detailed mathematical code. The user of the library needs some mathematical knowledge to get the best from the library.
Not very much. Default impls, etc. are designed to make it simple to do simple things. If this is not true, we have not done a good job designing and documenting the code.
Related to this is that the developers and advisors will be drawn from a different (less java/programmer centric position).
I respectfully disagree here. We do need some targeted help with numerics, but what we really need is Java developers with math proficiency and need (for math functionality).
Secondly, there is no reason why [math] could not be implemented in C, C# or another language as far as I can see. (There is no general rule here, [lang] and [collections] are java focussed, but [codec] could be multi-language.
I disagree. I see [math] as very Java-focussed. The whole point of [math] is to provide ASF-licensed pure Java implementations of basic math functionality.
One option that could be considered in to use the package name org.apache.math for your 1.0 release even if you are still hosted in commons. It avoids problems later.
I would prefer to keep commons in the package name. Later, if we toss out the current PROOPOSAL (http://jakarta.apache.org/commons/math/proposal.html) and try to become an "Apache math library" a new (multi-language) project could be started in the incubator, using some commons-math components for Java implementations. Even then, I would see commons-math as a valuable commons component.
So, consider me -0 to a commons-math-user at the moment.
Stephen
----- Original Message ----- From: "Mark R. Diggory" <[EMAIL PROTECTED]>
Do you get my argument though?
I get the argument, but I disagree with it. As Brent points out below, there are plenty of math forums out there for general discussion of algorithms and other math topics. I see no reason for Apache to host yet another one of these. I don't know what you mean by "non-developer" users, since our users are by definition Java developers. Discussion here should focus on issues related to the [math] code base. From time to time, this discussion will naturally include some math content. Since we are trying to stick to established algorithms and basic functionality, I would actually see it as a red flag if we ventured off into extended mathematical discussions.
For the reasons that I mentioned above, I do not want [math] to be split out from j-c. I will cut a RC for 1.0 this weekend and I would prefer that we focus on getting the release out rather than how the user list works at this time.
Phil
I'm suggesting that creating the new list will help promote maths 'non-developer' user base who are interested in algorithms and stability (not because the load is too high). Individuals who are not interested in usage of other commons components per se. Individuals like Kim or David (or anyone from the jama or colt lists), who may not necessarily be developing Apache code, but could supply excellent discussion on the subject area. It would really help to promote the project and attract a many individuals who are knowledgeable in the field of mathematics, thus offering expert feedback to help improve the product. A math library is a much different beast than a collections api, discovery or bean utilities; certain standards are expected. I want a list where such things can be discussed without risking being bothersome to the commons developer/user lists with overly abstract discussion on mathematics and not overwhelming such math users with discussion from other commons sub-groups.
I think providing a user friendly environment is important here, and someone barking "use a filter stupid, its not our fault" is really not very user friendly, ASF has the facilities and can do better.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
