Re: [VOTE] Invite Rahul Akolkar to join the Apache Commons PMC
Niall Pemberton wrote: [X] +1, don't let Rahul get away - lets try to get him to join the new PMC [ ] -1, no leave him out J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Invite Simon Kitching to join the Apache Commons PMC
Niall Pemberton wrote: [X] +1, don't let Simon get away - lets try to get him to join the new PMC [ ] -1, no leave him out J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r512384 - in /jakarta/commons/proper/math/trunk: pom.xml project.xml
Luc Maisonobe wrote: [EMAIL PROTECTED] wrote : Modified: jakarta/commons/proper/math/trunk/pom.xml [snip] - nameJörg Weimar/name + nameJ�rg Weimar/name It seems the name of this contributor get corrupted when I checked in the pom file after modifying unrelated lines. The XML header does not specify any encoding here, so the default value should be UTF-8 but in fact the original character was not UTF-8. I could fix this either by simultaneaously ensuring UTF-8 encoding in the XML header and using an UTF-8 character, or by using a XML entity (#246; in this case). Is there some widely adopted policy for pom files and do they really support non-ASCII characters ? I'm not aware of an Apache wide policy, either for POM files or XML in general. Using an entity makes it harder for people which want to have just a quick look at the file using a text editor; most modern text editors allow to adjust the character encoding quickly. My recommendation: add an encoding to the XML declaration (even if it is UTF-8) in order to make the encoding obvious for anyone opening the fil in a text editor, and use the Unicode character directly instead of a character reference. HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r506591 - in /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/fraction: Fraction.java FractionConversionException.java
[EMAIL PROTECTED] wrote: [...] - * Licensed to the Apache Software Foundation (ASF) under one or more - * contributor license agreements. See the NOTICE file distributed with [...] + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with Looks like there have been line ending issues. The overview shows the prop changes as well. I've got the proper line endings here after svn up, but could you double check everything is ok on your side as well? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Luc Maisonobe as Jakarta Commons committer
Phil Steitz wrote: [X] +1 Let him commit! [ ] +0 [ ] -0 [ ] -1 No, because... I hope this will boost [math] considerably! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][VOTE] Accept Mantissa contribution
Phil Steitz wrote: [X ] +1 Accept the Mantissa codebase into commons-math [ ] +0 OK... [ ] -0 OK, but I have the following concerns... [ ] -1 No, because... Looks good to me. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
Phil Steitz wrote: I looked at this some more last night and now agree that if you are just computing SSE, scoring the data and running that one sum in a second pass should in general be more accurate. The problem is, as Luc pointed out, the need to store all of the data and I don't see any way around that. That's what I meant by more complex. If there are better stateless formulas, then we should look at them. I don't think there is a stateless formula not subject to numerical problems in certain cases. I am still -0 on adding a separate stateful impl, but could be convinced if others feel differently and someone is willing to volunteer to research, code, doc and write tests for it. I don't think it's worth the effort. The current behaviour should be prominently documented, of course, and if someone can come up with a way to warn unsuspecting users that the result may be somewhat inaccurate in case the bit cancellation is detected, that would be great (I'd like to avoid introducing a logging mechanism). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (MATH-85) [math] SimpleRegression getSumSquaredErrors
Phil Steitz wrote: Just replace the return statement by : Math.amx(0, sumYY - sumXY * sumXY / sumXX); Sounds good. Well, the majority of the num math text books on my shelf actually recommend computing the sum of the squared errors instead of the algebraic equivalent form given in the more analytically oriented text books (and used above). This is, of course, more complicated and still prone to adverse numerical effects unless the sequence is also sorted. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Unifying maven reports?
Martin Cooper wrote: - findbugs (same as pmd?) I would rather see this as + than -. CheckStyle, PMD and findbugs have some overlap, but each one has also unique code quality tests. There are a few more utilities of this kind, and there's even a Java Code Meta Checker which consolidates their outputs in a single reports, see http://sourceforge.net/projects/metacheck Well, in my experience getting this configured for a software with some external dependencies (which usually means: mixed styles) in a way that the signal isn't completely drowned in noise is an art in itself. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RE-VOTE] Release Commons Math 1.1
Phil Steitz wrote: to call for another release vote, +0 J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] auxillary components
robert burrell donkin wrote: it's easier to automate a flat structure +1 I also think more granularity in a flat structure will 1. Reduce the complexity of dependencies between components 2. Might foster reuse (less fears of unnecessary or cyclic dependencies between components) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons math 1.1
Phil Steitz wrote: [X] +0 I support this release but am unable to help Sorry, no time at hand for helping you. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unnecessary casts in Commons-Math
Elliotte Harold wrote: I loaded Commons-Math into Eclipse, which promptly complained about numerous unnecessary casts. For example, this cast to double in LaguerreSolver.solve: Complex N = new Complex((double)n, 0.0); Complex N1 = new Complex((double)(n-1), 0.0); If I submitted a patch to remove these unnecessary casts, would it be likely to be accepted or rejected? Personally I find extra code like this to be very ugly, but I know some programmers and projects like these casts. If the commons-math policy is to use these, I'll set my Eclipse project preferences to ignore this. If not I can patch it. What do people prefer? Dunno. I'll look after this next weekend. There are a few other issues pending with the new solvers anyway. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [configuration] Checkstyle
Oliver Heger wrote: Personally I prefer to have Javadocs for all methods. This makes the code more readable. But it would be a bunch of work to fix this now. There is http://sourceforge.net/projects/jdochelper and various other stuff on the 'forge which might help, as usual. I haven't have time to try it out though (if you do, please post to community@ or [EMAIL PROTECTED] or something if you like it). I personally would find it useful to turn checkstyle into a stream editor which also fixes style errors which can be fixed automatically, like file headers, JavaDoc templates, indentation and brace style and so on. HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex equals
Phil Steitz wrote: So which do you prefer? A difficult question. Maybe trying to instantiate a Complex like 1+i*Nan should result in Complex.NaN for which both Re() and Img() are NaN. This means there is really only a single complex NaN. Going through the (old) archives, I remember at one point we were talking about adhering to C9x Annex G: IEC 559-compatible complex arithmetic*. *I can't put my hands on that spec right now, but I will have a look to see what the recommendation is. Probably the best idea anybody can come up with. I'm certainly not able to outsmart the C9x standard developers. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex equals
Phil Steitz wrote: Yes, you are correct about the IEEE 745 spec, but one could argue that the spec applies only to primitive values - at least that seems to be the way it works in Java. Since equals among objects in Java *must* be reflexive, Ok, this makes sense. Before the change, 0 + NaN * i was not equal to NaN + i for example, It can be argued this is correct behaviour, while: wheras isNaN returns true for both. this may be misleading (although still correct). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex equals
Phil Steitz wrote: When implementing hashCode I noticed that equals was distinguishing x,NaN from NaN, y, which is not consistent with isNaN. I changed the semantics to make *,NaN == NaN,* == Complex.NaN. I'm not sure I understand your change, but IIRC IEEE 745 requires that a NaN doesn't compare equal to anything, including itself. This would probably mean a Complex with a NaN component shouldn't compare equal to anything. I may misremember something though. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] [proposal] Restructuring the analysis package
Phil Steitz wrote: For math 1.2, I would like to propose the following changes to the analysis package: 1. Create solver, interpolator, integrator subpackages: [snip] Looks ok. Some (well, moset) of Zhang's contributions contain several solve methods. I'll create separate solvers for this. THere are methods for handling complex functions too; in order to take advantage of them, I think we should introduce complex functions and equivalents to the existing algorithms for real functions. 2. Implement the abstract factory pattern (and top level Utils class) in the solver package in the other two packages. It's on my TODO list. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Houskeeping - committers, contributors please read
Brent Worden wrote: 36266 looks ok. J., you have this issue assigned to yourself. Are you going to commit the changes? Commit is prepared, unfortunately I've problems connecting to svn.apache.org. I'll try again tomorrow. Same for the other SoC code. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
Phil Steitz wrote: Great!! I created a release branch for 1.1 and updated the POM in trunk to 1.2, so there will be no contention with the release. I also committed the sources in what I think is the latest version to trunk. Pls check out and make any changes you see fit. Now that's convenient! Thank you! BTW I'd rather created a new Integration or SoC entry in bugzilla and declared the existing bugs as blockers rather than mark them as duplicate. This way, reports from others could be easily tracked too without mixing them with Zhang's contribution. New, exiting bugzilla feature. (Another BTW: also a neat way to track release blocking bugs and feature requests). I think one could argue for including both kinds of things, similiar to other places in [math]. Provide users with the choice to select an algorithm or use a default or adaptive selection. The problem is that making a reasonable choice about which algorithm to use requires months, if not years of education and experience. I'd say if we require this, a lot of people will be dissapointed. As I said, the holy grail is an algorithm which is consistently performance-wise within a factor of two (or five) of a carefully picked, perhaps customized algorithm, and either gives the correct answer or bails out for 99.99% of the cases anybody wants to throw at it. Including functions like 1/(x^3), x*sin(1/x) or 1E+6*exp(-((x-0.5)/1E-6)^100). Unfortunately, unpleasant things like singularities in the integration interval are uncomfortably common in real world problems. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 36060] New: - [math][patch] Integration Source Files
[EMAIL PROTECTED] wrote: Add TrapezoidIntegrator.java Add TrapezoidIntegratorTest.java Update UnivariateRealIntegrator.java Update UnivariateRealIntegratorImpl.java Ok, I had a look at the files. It looks good, except that some style issues which look like being copied from C source should be fixed. Phil, Brent, Al: I've been inactive for a while now but I can take care of integgrating the integration files. I'll create a branch if this interferes with releasing 1.1 Zhang: you don't have to create a new bugzilla entry for every update, you can just create new attachments to an existing entry. I'd also prefer an attachment for each source file rather than a zip archive. All: What's the opinion about piling up implementations of text book integration algorithms? The holy grail is completely automatic intgration, so that the user doesn't have to know anything about the integrated function. Last time I checked adaptive higher order Gauss integration was en vogue for this purpose. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] make dependency on servlet api optional
Simon Kitching wrote: This is only a *compile-time* dependency. Currently there is a single utility class provided in the standard logging jar which can be used to avoid memory leaks when using commons-logging in servlet containers. The presence of the class doesn't do any harm when used in non-servlet-containers; commons-logging will run fine and the class is simply not used. There's a recurring problem: projects developing into kitchen-sinks (Damn hard to avoid writing kitching sink here :-) ). I had to build Apache software from source multiple times for debugging purposes, and I don't like to track down all of the obscure compile time dependencies. Nor do I like to wait half an hour until all dependencies have been fetched from ibiblio or whatever. I'd prefer a more modular approach: - Split the project (preferred, but not all that easy) - Provide several build targets according to dependencies - Compile optional (non-core, or less likely to be missed) components or features only if libraries they depend on are in the classpath. Issue a warning otherwise: Component/Feature FooBar not compiled because FooLib not found... Take a look at the FOP build file to see the third approach in action. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Uzhgorod wrote: When i was speaking about the Graph Library I meant the algorithmistsc implementation of a powerfull package for operations with graphs as mathematical object (graph - a set of vertexes, and a set of edges and a function which for two given vertexes returns true if they are connected ) There's already jakarta commons graph2, although it could certainly use a new contributor. You might also want to check freshmeat for various projects, a quick search for java based packages gives http://www.jgraph.com/ http://jgrapht.sourceforge.net/ http://openjgraph.sourceforge.net/ http://web.mit.edu/bshi/Public/nv2d/ GraphMapper (appears to be dead) There are various packages in other languages, including a very sophisticated C++ library. If you could afford it, I'd be rather interested in an OSI licensed Eclipse plugin similar to OptimalJ http://javacentral.compuware.com/pasta/ preferably with some clever UI which leverages the graphic representation of calls/dependencies for refactoring (I can hopefully point you to several papers for ideas). Or build a really good graphic page flow visualization for Cocoon's flow, also as Eclipse plugin. :-) Regards J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Paul Libbrecht wrote: There's a difference between a graph plotter and a chart plotter: the source data. To me a chart-plotter is fed by a bunch of numbers whereas a graph-plotter is fed by a bunch of functions. Ah, I see. Well, at least the screen shots from http://vofce.sourceforge.net/ look promising. Although I lived well with GnuPlot for this purpose until now. That characteristic is probably a very high requirement and is probably the reason why it's mostly only found in more general purpose computer-algebra-systems There are a few general purpose CAS written in Java available. (yacas et al, plunder sourceforge as usual). I'm not sure whether any of them has a plotting component. I'd still be very surprised if there isn't even an attempt at a java graph plotter on sourceforge. If not, ripping code off GnuPlot and/or GNU plotutils should be easy enough. :-) You might also ask here (not OSS) http://www.accesscom.com/~lillge/pgc/ or here http://www.pa.uky.edu/~phy211/graph_applets/plot_graph.html or here http://www.rddvs.com/RICHplot.html http://dsaka20.kushiro-ct.ac.jp/~yanto/java/surface/ http://sol.cs.wcu.edu/~par/grapher/GrapherUtility.html or a dozen or so of other websites (making plotting applets must be *really* fun!) HTH J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] FW: [interest in] SummerOfCode2005 commons-math project
Paul Libbrecht wrote: I fear it's off-goal but we took some time here to look for a graph-plotter, either Swing component or picture generator, that would be open-source, tested on several platforms. Well... we found none ! That's interesting. Is the evaluation published somewhere? Or could you put it into the Wiki: the packages evaluated, and why they didn't fit your requirements? I was under the impression JFreeChart is almost as good or better than gnuplot, but I never took a really close look at it. There's also Krysalis Wings... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons - math] Vector and Scalar multiplications
Phil Steitz wrote:
I think what you really mean here is the function call / object
instantiation overhead, right?
Well, no. I'm interested in background information on hot run
time optimizers work now, i.e. whether they will optimize
for(i=0;in;i++) {
a.set(i,a.get(i).add(b));
}
into
for(i=0;in;i++) {
for(j=0;jm;j++) {
a[i][j]+=b[j];
}
}
including optimizing array boundary checks away, doing loop
unrolling etc., and what the conditions are for these optimizations
to kick in. Sun Java 1.3 apparently had limited capabilities
in this area.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons - math] Vector and Scalar multiplications
Tzvika Barenholz wrote: Is there somewhere in the Math package simple methods for multiplying vectors with other vectors of scalars? No. Did i miss something? as far as I could tell there is no RealVector class or the like at all. That's probably because there are already two common representations of a vector: 1. a Java array 2. a special case of a matrix with either one row or one column. What exactly do you mean by methods for multiplying vectors with other vectors of scalars? General vector algebra usually only defines scalar*vector. There are multiple (conflicting) definitions for vector*vector in various contexts, the most common is (a1, a2, ...)*(b1, b2, ...)=(a1*b1, a2*b2, ...) Could you be more specific? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [commons - math] Vector and Scalar multiplications
Tzvika Barenholz wrote: There are multiple (conflicting) definitions for vector*vector in various contexts, the most common is (a1, a2, ...)*(b1, b2, ...)=(a1*b1, a2*b2, ...) ... I mean exactly the above indicated 'common one'. of course i could relate to it as a multiplication of two matrices (the left a row the right a column) but seems a bit ugly. You'll get a 1x1 matrix in this case, i.e. you geft the scalar product of two vectors: a1*b1+a2*b2+... Do you think there is a point in adding a sort of static methods class , VectorUtils or the like? I never felt the need to do this. In Java 1.3 even with HotSpot, there is still a noticable speed advantage if you unroll and inline simple vector operations in inner loops instead of calling a function. Does anybody have more recent data about Java performance for numerical comuptations? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] API changes for RC2
Phil Steitz wrote: Spooky -- delightful word choice ;-) The getDataRef method is there to limit copy operations and to support hacking the underlying array -- evil, hazardous, breaks encapsulation -- ... and every decent sparse matrix implementation will break its implied semantics. Make it part of the implementation rather than the interface. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Customizing Jars was: Re: [lang] Interpolation
matthew.hawthorne wrote: I see your point, but keep in mind that this was done to make the lives of the users easier. Forcing a user to include a huge [collections] jar for a project that only uses 1 or 2 classes from it doesn't seem practical to me. Well, there's always the tradeoff between 1. providing many small jars, thereby creating lots of dependencies and making versioning hard, and 2. providing a few large jars, thereby keeping the dependency graph small but making it harder to upgrade small parts and providing the feeling a lot of unnecessaary things are loaded into memory One solution is to provide a tool which packages only used classes and their dependencies into one or a few custom jars. Unfortunately, the dependency tracking mechanism needs some metadata to track dependencies created by data driven class loading. A possiblity to get around this would be a tool which notifies classes used during compilation and JUnit test runs and creates a customized jar from the pool of library and program classes in the deployment stage. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] [vote] Release 1.0-RC1
- [X] +1 Go ahead and release 1.0-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 1.0-RC1, because... - J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Filtering by subcommunity Was: Re: [all] Math needs a user a dev email list.
Kim van der Linde wrote: I think I am a typical math only user and developer and I just joined the e-mail lists. The last days, I seriously contemplated on leaving both lists because of the use amout of completly irrelevant bullshit that passes by every morning and during the day on my computer. I have better things to do. I still give it a few days, basically to find out whether people are good enough to put [math] in the header always. If so, I can filter, but my experience with other mailing lists is that people forget sometimes I have experimented with a combination of procmail and bogofilter (basically the same a spam filtering) in order to improve automatic classification, with encouraging results. There are further ideas yet to be explored. Unfortunately, this is a complex setup, not ready for the common user. Better mailing list subscriber support including automatic filtering for lists covering multiple topics of interests really needs to be build into the mail client. So much to do ... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Math needs a user email list.
Stephen Colebourne wrote: For me, [math] goes beyond the role of a simple library of common code. IT would be interesting to hear what you (and others) think about the further evolution of [math]. I also really like to know what current users of [math] currently do with the library, and what they expect from further development. From my point of view, [math] provides currently mainly basic to moderatly advanced functionality to do descriptive and analytical statistics. The algebra and solver packages are more or less utilities for this purpose. Building on this, obvious development directions would include graphical data representation, like GnuPlot or JFreeChart (BTW there aren't many good plotting/charting packages, and various initiatives in ASF communities have stalled. Why???), higher level functionality for statistical tests, or going deeper into the simulation domain. What do you think? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Getting 1.0 out the door -- tasks remaining
Phil Steitz wrote: root-finding interfaces. ... Does that mean that you think we need to change the interfaces. If so, how exactly? Along the lines that I suggested earlier (stateless, value objects returned)? Actually I don't know how to proceed. It would be nice to have a common pattern for to interfaces for solving non-linear equations (aka root finding), solving systems of linear equations, interpolation and perhaps some functions from the stat area. OTOH, each problem has some unique aspects and performance tradeoffs (in terms of copying stuff and perhaps more), and I have no good idea how to get this unified while keeping it reasonably simple and intuitive. Duh! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Getting 1.0 out the door -- tasks remaining
Phil Steitz wrote: 1) Decide what to do about inverse cumulative probabilities where p = 1 (easy solution is to document and throw) Nearly +1 2) Decide what, if anything to do about the root-finding interfaces. I am OK releasing as is. Uh, oh! 4) Decide what to do about RealMatrix rank. Only reasonable solution at this point appears to be to drop it from the interface. I'd vote for dropping it. A robust implementation would require SVD, which is quite complex in itself, and I personally never found a real usage for a matrix rank unless it dropped out of a related computation as a side effect anyway. 6) Decide whether or not to add BigDecimalMatrix. I'm undecided; if the unit tests are up to a decent coverage, I think it could be included. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Markup stuff on lang???
Paulo Gaspar wrote: I also think that the markup stuff is quite useful, but it is weird to have it in lang. It would make a nice o.a.c.text.markup sub-sub-project. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Graph theory
Herve Quiroz wrote: - retrieve information, such as diameter - determine if the graph is a simple graph, a multigraph, or a pseudograph - find paths between nodes according to various properties and algorithms - perform operations on several graphs, such as vertex/edges coloring Check the commons-sandbox graph2 module first. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Graph Project
Rowan Christmas wrote: It seems to be under the Gump project, and I was unable to find a formal page that had things like contact/api information on it. See also the graph2 subproject in the jakarta commons sandbox. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] RealSolver refactoring proposal
Phil Steitz wrote: I would like to propose that we simplify the UnivariateRealSolver design as follows: 1. Eliminate the function f from the UnivariateRealSolverFactory new* methods, adding it as a parameter to the solve() methods on the instances instead. Well, the idea behind passing the function in a constructor is that data specific for the function can be reused across invocations of solve(). A potential application, currently unused, would be function specific sanity checks for the convergence criteria. I'm not sure how useful this is, because this may also depend on the interval. 2. Eliminate the default* fields from UnivariateRealSolverImpl (what are these supposed to be for? Shouldn't they be constants, if we do need them?) The idea was to provide changeable defaults for creating new solvers. At least I hope so, being currently too lazy to have another loook at the code... 3. Eliminate the stateful methods in UnivariateRealSolver. What exactly was the rationale for the stateful design? A stateless design could eliminate a fair amount of code (actually, UnivariateRealSolverImpl could be completely eliminated in this case). It seems to me that the client should be able to maintain state information about previous runs, etc. What am I missing? Hm. Saving the result of the last solve() call can be eliminated. I'm not sure whether you think of the setters for the various other parameters as stateful. I'd like to keep the possiblities to configure the convergence criteria. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
Henri Yandell wrote: LocalizedMessageSource? and change getResourceKey to getMessageKey ? Other names: LocalizedMessagable LocalizedThrowableMessagable etc. Sounds good, but the scope should be [lang], [ressource] or the yet-to-create [i18n] project. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] i18n package proposal
Phil Steitz wrote:
I am with Henri here. I would not expect error messages from [math] (or
[collections] or [lang], etc.) to be passed up directly to a gui or end
user console. Designing and managing error messages for the end user to
see should happen at the application level, supported by something like
[resources], IMHO. I would be hesitant to take on the maintenance of
localized [math] error message strings or to load too much content into
these strings. Same would apply to other commons components.
This would, however, mean that instead of a generic MathException
there should be a ConvergenceFailureException, SingularMatrixException
etc. in order to give the application a chance to react properlz
without having to parse the error message. Not necessarily a bad thing.
In my experience, if a basic library like [math] throws an exception,
applications rarely deal with it other than
- telling the user an unexpected math exception has been caught
- throwing it right to the top level, perhaps crashing the whole app
In FOP, the code responsible for reading images has something like
catch(Exception e) {
log(Can't read image);
}
This deprives the user basically from all facts which could help
in tracking down the problem (for example the specific XML parsing
error including line number in case of an SVG image). OTOH, unwinding
all possible exceptions is hard, and if we got to the root SAX
exception, we'd still have to rely on the actuall message in this
exception.
Yeah, confused? So am I :-)
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] - Multiple Linear Regression
Inger, Matthew wrote: Has there been any though to resource bundle usage in commons/math? No. Contributions are welcome, we've got other messages in need of i18n as well. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] - Multiple Linear Regression
Inger, Matthew wrote: Is there any plan to possibly have a MultivariateRealFunction interface? Well, as you see the very existence of UnivariateRealFunction somehow suggests this. However, nobody expressed a real need until now... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: How to block just these cvs commit mails
ASHWIN Suresh wrote: True, but it would be great if there is a server-side method of doing it. I don't want the mails to even reach my machine, it is better to avoid their transfer from the server. These mails are rather frequent and voluminous anyways. Filter all mails with either - To: is [EMAIL PROTECTED] - Subject starts with cvs commit: If you use IMAP, you can delete them from the server without downloading more than the mail headers. How to automate this depends on your mail client. If you have access to the MDA you can already filter there. Exact ways how to do this depend on details of your MDA. BTW: -Original Message- Messages with 75% old quotes are voluminous too. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/betwixt project.xml
[EMAIL PROTECTED] wrote: Added Tim as a developer. It'd probably be a good idea to have an xml file with entity definitions for commons developers so that the entry is the same in each project.xml. Shared entities are a PITA for people who care only about certain subprojects (referencing shared files outside the subproject's directory generally sucks, especially if they don't make it into source distributions). I'd suggest do talk to the Maven people whether they could provide a sort of include mechanism with graceful fallback, somewhat like XInclude. Or actually use XInclude (pull out Cocoon's XInclude processor). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][RESULT] New committer - Neil O'Toole
robert burrell donkin wrote: if it doesn't seem like materializing, probably the general list would be a good place to find a volunteer. Is already in the works. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] re: move to Apache Commons
Phil Steitz wrote: Recent comments have suggested that Java may not be suitable for numerical computation (a view that I do not share) Well, I think this should be put into context. Let's examine some approaches to numerical computation: 1. A cleanly designed library of commonly used, somewhat low level functionality, like [math]. While it is relatively easy to build solutions for complex problems, this approach suffers from lots of temporary object creation and data copying. This is hard to avoid in Java without giving up data encapsulation and providing ample opportunity to users for shooting themselves in the foot. See the constructor of CubicSplineFunction for an example. 2. Provide solutions to higher level problems. Inline the code for the lower level functionality, do memory allocation less dynamically and weight the usage of abstractions carefully against possible object proliferation. For example in a ray tracer, use the vector components explicitely instead of using vector objects. This is, in general, noticably faster than approach 1, and an increase of *two* orders of magnitude is possible, although not necessarily common. Profiled and well optimized Java code run on a HotSpot JVM can be on par with average C code with regards to performance. 3. Get a highly optimized C/C++/FORTRAN library (possibly including a compiler), which takes processor architecture, cache size and organization and whatnot into account. A performance improvement of another order of magnitude compared to approach 2 is not unheard of. I tried an EMF simulator two years ago, and when built on a generic Java library, very similar to RealMatrixImpl, a 1000x1000x1000 data point simulation run all night. Switching to approach 2 brought it down to roughly 5min, barely enough to fetch a coffee. The real good stuff, using C and tricky algorithms specifically designed for EMF simulations, is nearly interactive, in the 5..10s range. Summary: whether Java programs can be used for tackling numerical problems depends on the problem, the problem size, how you want to solve it, and the tradeoffs you are willing to consider. some design/refactoring decisions made some time ago that moved things more in the framework direction in commons math. Hm. There are reasons that there are usually a bunch of different algorithms for solving seemingly the same problem. Which specific algorithm should be used can heavily depend on the higher level problem, and a good choice can be a really huge win. And yes, unsuspecting users are regularly bitten by stock textbook solutions which are either much too slow or fail unexpectedly. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: math to apache commons was Re: [all] Separate email list for math development?
Mark R. Diggory wrote: ... There is significant number of us with an interest in seeing numerically sound implementations of various aspects of mathematics in java... Suffice it to say that java implementations do provide an elegant means to explore ideal Design Patterns for Mathematical packages and provide a foundation for exploring how to bridge java with other languages that may be more optimized to handle such computations. These are noble goals. Agreed. I can see the development of higher level APIs as a major goal for [math]. Interestingly, there are quite a few directions to pursue. One major direction is floating point number crunching, in particular - engineering and physics support, including large equation systems, ODE, PDE, numerical integration, continuus optimization, large eigenvalue problems, integral equations - computer geometry support, mainly CSG - computer graphics The other rough direction is discrete math: - number theory - graph theory (we've got [graph]) - planning and discrete optimization - encryption The application branch, somewhat randomly choosen keywords - CAS - data visualization, including curve fitting, descriptive statistics, adaptive filtering and isosurface detection - neural networks and machine learning in general - diagram layout, general graph layout - 3D modelling and rendering - ERP - network simulation Well, the utility of [math] for real world heavy number crunching (the very first point above) will always be limited. Other directions seems to be more interesting in terms of getting people using it in real world applications. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] BeanUtils, BeanTransformers and BeanListUnivariate
Mark R. Diggory wrote: In Repast they/we encountered that reflection costs tend to make wanting to work with Collections as the core of a mathematical evaluation a bit costly, In RePast the solution to this was to pickup the trove API (similar to BCEL) and actually generate bytecode optimizations of these types of method calls on the Collections of Objects. Nice, but using a byte code manipulator in [math]? Shudder! We don't do byte code! Isn't there a high-level API available for this purpose? Also, I've been considering some naming and consolidation of the lower end Univariate API. I think this is poorly named (think we discussed this before). I'm considering that Abstract/StoreUnivariate/Impl should probably be named DescriptiveStatistics. and that Abstract/Univariate/Impl StorelessDescriptiveStatistics or LiteDescriptiveStatistics Sounds useful: +1. This would also allow us to remove runtime dependencies on commons-logging and bean-utils. I somehow think the commons package could use another reorganization, for example splitting a JDK 1.3 compatibility package with nestable exceptions a a bunch of other stuff delivered in 1.4 out of [lang]. Why does beanutils depend on logging? Maybe a split of this package could help too. Unrelated to math but perhaps to the beanutils dependencies: While working on [text] I noticed some similar patterns: - core library with deps mainly on [lang] - tools depending on ant (for ant tasks), [cli], [digester], [logging] and others - Unit tests depending on all kinds of weird libs. How should commons components be organized? Should we have o.a.c.stuff o.a.c.stuff.tools o.a.c.stuff.anttask or rather o.a.c.stuff o.a.c.tools.stuff ... Opinions? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] interface for UnivariateRealFunction (differentiability)
Matt Cliff wrote: What is the purpose for having the firstDerivative() and secondDerivative() methods on a UnivariateRealFunction ? The first derivative could be used in a Newton solver. The second derivative could be used in yet another higher order root finder, or for providing error estimates and guidance in modified, more robust Newton root finders (sorry, I'm too lazy to look up method names). The reason they are in the function class is that partial results might be shared for calculating the values of the function and its derivatives. Reusing intermediate results can bring Newton in front of the Brent-Dekker solver in terms of efficiency again. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Results] Promote Math project to Commons Proper...
Mark R. Diggory wrote: 8. Gather a list of committers for the component, ask [EMAIL PROTECTED] to give them commit access to component in commons-proper. Well, I didn't work as much on [math] as I should have, but you can count me in. I don't have karma for jakarta-commonss though. If we are at it, I'd like to propose Brent Worden as committer too, he seems to be very committed:-) to [math], counting the number of his patches and the timespan of his engagement. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] [collections] order-statistics tree (augmented red-black)
Bryce Alcock wrote: I would like an order - statistics tree, Which behaves with the same running times as a standard red-black binary search tree. ... 1. Are there any plans to do something like this in either the Math, or Collections sections of Commons? I don't think so. I'm not quite familar with the term statistics tree. If it's a modification to rbtrees which optimizes for a predetermined ad-hoc statistic for modification or read access it should probably go into the collections module. If the statistic is calculated on the fly from the access, then, well, it should probably also go into the collections module. Could you explain a bit more? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox 'article'
Hm, the problem with graph2 is that the important interfaces aren't documented or demonstrated by comprehensble examples. They use some tricks which should be explained in some sort of design documents before the code could be unleashed onto unsuspecting users. I also suspect that generic graph code has always to fight with the problem that has to parallel data structures containing the real user data, and that DFS is pretty easy to code, especially if some knowledge about the data can be hold up. Well if someone would bother to add reading and writing GML and adding graph layout, that would be a killer... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Isn't it about time?
Brent Worden wrote: I am of the opinion that everything we've been discussing should be held over to the next release. No problem. The Decomposer could be added without incompatible changes itself, the only problem would be that in order to take full advantage, RealMatrix will have to be changed into an interface and a bunch of GeneralRealMatrix, TridiagonalRealMatrix, SymmetricRealMatrix and so on have to be added (only the first for a start). I'll try to get another shot at completing the documentation next week. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Isn't it about time?
Mark R. Diggory wrote:
How close does everyone think we are to a release?
Maybe its getting time for a Vote?
Most of the stoppers have been sorted out. Open issues
- a Complex class
- providing more flexibile framework for solving linear
equation systems.
I think of RealMatrix as Data holder only, and providing
a decomposer class with an associated factory, a decomposition
class holding the decomposition and providing the backward
pass of the solving algorithms.
Like
class RealMatrix {
// get a matrix specific decomposer factory
DecompositionFactory getDecompositionFactory();
}
class DecompositionFactory {
// get overall default factory
static newInstance();
// construct a new default decomposer
Decomposer newDecomposer();
// example for a specific decomposer (Householder or QR)
Decomposer newQRDecopmposer();
}
Decomposer {
Decomposition decompose(RealMatrix);
}
Decomposition {
// solve A*x=b
RealVector solve(RealVector b);
// solve matrix equation
RealMatrix solve(RealMatrix b);
RealMatrix invert();
}
This way it would be possible to
a) take advantage of special matrix forms, like symmetric
or tridiagonal matrices, thereby using simple and more
stable methods
b) use different solvers in case one solver proves to be
unsatisfactory (like QR or even SVD instead of the standard LR
decomposition, or post-iterations)
c) reuse the decomposition for solvong multiple systems with
differend right hand sides
The decomposition objects could provide for an error estimate, if
available for this decomposition.
Any comments regarding numerical integration methods? Minimizing
functions? Optimization (linear and non-linear programming)?
Regards
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex implementation
Mark R. Diggory wrote: Not to suggest I'm not for creating a Complex class, I just know we have issues. Well, and *all* these issues have been discussed to death in the C++ community before. While the FORTRAN folks were laughing. Main points: in order to make a Complex class useful, you need - a convenient notation - acceptable performance, which basically means no temporary objects - convenient mixing with other numerical datatypes C++ ultimately got a solution heavily using operator overloading, expression templates and half a zillion of auxillary classes. The result is FORTRAN performance combined with an intuitive syntax, and with the drawbacks of a compilation process taking forever plus one day and nearly all available memory. And the library is basically maintainable by demigods only. In what sense this is better than making complex numbers a language built-in like in FORTRAN still baffles me, but I digress. Now to the point: Java currently doesn't have any of the mechanisms which allowed the C++ crowds to meet ends. IOW: a pure Java support for complex numbers will suck one way or another (probably both). There is no way around the performance problem short of providing a sophisticated preprocessor, thereby making complex numbers a part of the language - which would solve the notation and integration problem as well. Matrices have the same problems as complex numbers, only worse. There is a reason BLAS is only taught to people really needing it. Whate ever happened to the efforts at JCP to solve the complex matrice conundrum? How many projects would profit from convenient matrix and complex number support? I'm not surprised there is not much pressure to get something up and running. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex implementation
Henri Yandell wrote: Just to bring this subject up again. Can you provide a short proposal what you need? A Complex class with the usual operations and functions (norm(), arg(), exp(), log(), sin() etc...), similar to j.m.Integer? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Maven build and elements of style
Robert Leland wrote: Borland popularized the @todo, which I use. Maven, or one of the plug-ins, also recognized the 'TODO:' so there are no javadoc warnings. I replaced @todo with TODO: while fixing the JavaDoc warnings. Questions: - TODO (without colon), as recognized by Eclipse out-of-the-box, or TODO: (with colon)? I used the latter, more for aestethics. Will Maven recognize TODO? - What about the FIXME? Replace with TODO:? There are also some comments containing NOTE: at the beginning of each comment line. As a matter of consistent style, should this be removed? I had the idea of building a setup your IDE for work with Apache projects guide in the Wiki, unfortunately, there isn't much content yet there. If FIXME should be recognized (or TODO: instead of TODO) this should be put there. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Maven build and elements of style
Mark R. Diggory wrote: Now, Eclipse does allow the definition of local project task tags. Maybe it would make sense to build a .project file for math that contained these configurations, then add it to the cvs so that all Eclipse users actually can use it without needing to customize Eclipse for each tag? Hmm, unfortunately it looks like that information isn't actually stored in .project, sorry. No, it's global rather than project local. But you can put suggestions somewhere into the Wiki. Start here (lots of dummy text still): http://nagoya.apache.org/wiki/apachewiki.cgi?ToolChest J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Maven build and elements of style
Hi, is there a way to tell maven not to reload the three SNAPSHOT jars without secifying --offline (which may cause failure due to other missing jars)? Could we use release jars instead of snapshots? Further notices: There are a few FIXME comments. I've configured my Eclipse to mark FIXMEs, but the out-of-the-box config highlights only TODOs. Can we agree on a common style here? I also get a lot of checkstyle warnings for operators placed at the beginning of a line. This is both Old Emacs style as well as Eclipse's auto formatting style. I have no idea how the Eclipse auto formatter can be told to put the operators at the end of the line. Also, I personally find operators at the end of the line awful too, although it is more consistent with common line breaking rules in documents. Questions: where's the operator at previous line end originating? Are there IDEs/formatters which auto-format operators at the end of the previous line? Can/should we revert to operator at the beginning of the line? Is there some way to order JavaDoc to tell the correct line for its warnings? I get them consistently wrong, by an unpredictable amount. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Exceptions again...
Hi, I found that [math] still wont compile on JDK 1.3 due to the super(throwable) constructors in MathException. Should we just write off 1.3 users, now that a reasonable 1.4 is available on basically all platforms which run Java at all? Unless I'm mistaken, Brent's patch contained some corrections for this problem. Further, there still wasn't a conclusion on what to do with analysis.ConvergenceException, which is used in util.ContinuedFraction only, and also is a RuntimeException instead of a checked Exception. Point one: given the current code, it seems to be misplaced. Point two: Falling out of the loops in the root finders actually indicates a convergence problem (either too stringent accuracy settings, ill conditioned functions causing oscillations or a bug in the algorithm) I'd like to use a ConvergenceException for this condition too, however, throwing a mix of checked and unchecked exceptions for conditions of comparable complexity is something I'd rather avoid. Possible solutions: 1. abolish ConvergenceException completely and replace it in ContinuedFraction by a (checked) MathException. This will cause adding a throws MathException in a heck of a lot of places, including on gamma and beta functions and everywhere they are used. The discussion whether the kind of functions should throw a checked exception wans't conclusive yet. 2. derive ConvergenceException from MathException (and palce it in [math] root), further see above. 3. make MathException a runtime exception and replace ConvergenceException with a MathException. 4. make MathException a runtime exception and derive ConvergenceException from MathException. 5. Leave as is but move ConvergenceExcpetion to [math] root 6. as 5 but move to [math]/util Any ideas/recomendations/votes? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Exceptions again...
[EMAIL PROTECTED] wrote: Why not just use NestableException in Commons Lang? Has been proposed http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106304647620410w=2 apaprently included in some patch http://marc.theaimsgroup.com/?l=jakarta-commons-devm=106369042012878w=2 but last I checked it wasn't in the repository. Personally, I'd be ok with requiring 1.4 for the stated reasons, but if the majority finds the added dependency is worth the effect of 1.3 compatiblity, so be it. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/io project.xml
__matthewHawthorne wrote: Wouldn't tabs show up as a weird character, and not just blank spaces? This depends on the viewer. Common mail clients as well as the common breed of text editors, XML editors and IDEs show tabs as a fixed number of spaces, usually 8 by default, occasionally this can be configured. in fact, I don't know of *any* editor which shows a literal tab (Unicode U+0009) not as a fixed number of spaces. The presence of tabs can often only be inferred from a jumping cursor, which is an annoyance in itself. Real word processors are another matter, but they usually use tabs for building sort of tables (what else?), and don't visualize tabs with something else either. I don't want to just undo it since I liked the changes I made. I meant, undo inserting tabs, replacing it with proper spaces. Your attempt seemed to be successful. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [graph] is the projec alive?
Henri Yandell wrote: There's no PROPOSAL.html or STATUS.html in there, so it's not got the necessary requirements for a promotion to Commons proper to be considered. There's lots of stuff which is, ahem, fragile, in particular the XML output stuff. Well, it seems current XML supportis more for debugging purposes, but adding some more serious support for reading and writing will certainly be a worthwile addition. Instead of the homegrown format a somewhat more widely used vocabulary would seem in order, however, there are quite a few XML vocabularies for generic graphs out there, but not really anything a standard blessed by some acknowledged consortium nor a sort of industry standard. Some Candidates for discussion: http://www.cs.rpi.edu/~puninj/XGMML/ http://www.concept67.fsnet.co.uk/gsix/ http://www.gupro.de/GXL/ http://www.cs.rpi.edu/~puninj/RGML/ (with some W3C blessing) http://zvon.org/ZvonSW/ZvonGraphotron/index.html A XML-ification of the GraphViz input would be also worth a look, if anybody is interesting in graph layout. Any takers for writing up a comprehensive review of these formats? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Project Maturity?
Mark R. Diggory wrote: 3.) Test Coverage. The coverage report doesn't seem to be available from the jakarta site. Can I have a look at it somewhere else? 4.) Code review. I just discovered a bunch of printStackTrace() in BeanTransformer. Any ideas how this should be handled in a better way? Throwing a MathException? Algorithm Development Tasks * Framework and implementation strategie(s) for finding roots or real-valued functions of one (real) variable. * Cubic spline interpolation. Should be already there? Additions: - Find a way to make [math] compile and run under JDK 1.3 again. This mainly consists of deriving the exceptions from [lang] NestableException and adding a GUMP/Maven dependency on [lang]. - Clean up and unify exceptions. The ConvergenceException thrown in ContinuedFraction is a runtime exception not derived from MathException. The issues here: + Root finding should throw a ConvergenceException in case of convergence problems (falling out of the loop without decreasing the interval enough). However, because the exception is not derived from MathException, it must be handled separately by callers if this is done so. + Deriving ConvergenceException from the checked MathException would add a lot of throws clauses. This seems to be justified for the relative complex ContinuedFraction, but unfortunately this is used in the gamma function, where throwing a checked exception may throw off people (but then, java.io throws the checked IOException even for close()). This has been discussed in general terms, but without a conclusion for our specific case. - Make the default root finder run time configurable again. Well, if necessary. - I'd like to refactor the linear equation solving a bit, adding a new class for the matrix decomposition so that solvers can be written which can take advantage of special matrix forms (e.g. symmetric or tridiagonal). As usual, time is lacking. - The internal data exposure issue in RealMatrix and in the interpolator has to be discussed and resolved. See the comment in the interpolator class for details. - Possibly get rid of RootFinding in favor of moving the functionality to UnivariateRealSolverUtil? Dunno. - Rename UnivariateRealSolverUtil to UnivariateRealSolverUtils? - Rename UnivariateRealSolverImpl to UnivariateRealSolverSPI? - It has been already discussed but can't we load off DoubleArray and related classes to [collections] or the new [pcollections]? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] [commons] Dependency diagrams
Arun Thomas wrote: Neat to see, but something that might be interesting is to also differentiate between required runtime and compile time dependencies. The first diagram shows compile time dependencies. Run time dependencies would be the transitive closure. I think the dependencies are already set up this way, but I didn't check. Unfortunately, [graph] is not yet up to the task of helping with this kind of manipulations. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] [commons] Dependency diagrams
Hi all, a first shot at a graphical representation of dependencies of commons projects: http://cvs.apache.org/~pietsch/dependencies.html Warning: The images are big (~2M), and it's not very pretty yet. Some more canonicalization of dependency and project names would help too. If a Mavan guru could tell me the difference between id, name and groupId in the project.xml dependencies... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Code generation was: Re: [collections] contribute?
__matthewHawthorne wrote: There are many times that I've wished I had found a nice way to autogenerate things while creating a bunch of redundant primitive methods. There are half a zillion methods for generating code, starting with Bash/Sed/Perl hacks, leading to dedicated macro languages like the C preprocessor and m4, continuing with a variety of web templating languages like PHP, there's XSLT and finally high level stuff like lex/yacc, ANTLR and all the other grammar generators. The recurrent problems: - Need dedicated Ant tasks (Make was a bit easier here) - IDEs rarely handle them well - Tracking compile and runtime errors caused by generated code to the ultimate source isn't well supported and often painful I personally use ad-hoc generators mainly to bootstrap code, once the bulk of the code is stable, I abandon them. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Words - for 2.0
Stephen Colebourne wrote: WordWrapUtils is broken. ... This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) I have an implementation of Unicode TR14 for word wrapping almost ready. There are some fine points still to resolve though (Some width issues for east asean characters and how to handle combining markers. Well taking this into account the current class is even more broken.) Preparing the tables from the report was painful, I feel like a hero now. I'd vote for pulling the class and move it elsewhere. ... This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) Other features for [text] - parsing text into words - spell checking - character normalization (well, there is icu4j) - glyph shaping - hyphenation - word inflection - morphological analysis, grammatical analysis - various tools for handling data necessary for the tasks above I can contribute some code for most of the above. FOP would be the first user of a commons hyphenation component and and will probably also take advantage of character normalization in the long term. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Clover coverage report for Lang 2.0
Tetsuya Kitahata wrote: No, I think each subprojects should have own license. Again, it would be interesting to get http://hansel.sourceforge.net/ (recently released 1.0), or http://quilt.sourceforge.net/ working. Unfortunately, the latter had no activity for more than half a year. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] commons-lang-2.0-rc1 ready for complaints
Henri Yandell wrote: .tar.gz being CR. LF, I hope. CRs are for Macs (.sea) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
Henri Yandell wrote: Apple have a spell-checking api. It only works on OS X, but they supply a stubbed out API for deploying to other machines. Would be quite cool if your spell checker shared API with Apple's. Neat idea. The current API is for spell checking a single word, the Apple API is a somewhat higher level, with parsing words from text and dictionary management. I don't think however a com.apple.spell package would be tolerated in the ASF repository by either Apple ot the board. Is there an established procedure for creating new sandbox components (including voting and such), and if a [text] component was created could someone help bootstrap the component (Gump integration etc.)? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[lang] WordWrapUtils
Henri Yandell wrote: We also see the addition of more Utils classes: ... WordWrapUtils RT mode: It would be interesting if WordWrap would implement Unicode TR14. I, or better the FOP project, have also a hyphenator which would also fit with the word wrapping issue. Finally I have a spell chacker (a rewrite of MySpell in Java) which searches a home. Because it loads the whole dictionary into memory, I dont consider it ready for use in long running programs, like servers. Apart from this, is anybody interested in including this type of software into [lang], or perhaps in sponsoring a [text] project in the sandbox? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] WordWrapUtils
Henning P. Schmiedehausen wrote: +1 Ahem, +1 to what: [ ] Creating a sandbox [text] component, move WordWrapUtils there and [ ] implement TR14 [ ] add hyphenation including all utilities [ ] add spell checking [ ] improve/add stuff to WordWrapUtils in [lang] [ ] something else: However, as it was me who resurrected WordWrapUtils, I'd like to see them in a commons-proper package the sooner the better, because we're currently planning to remove our internal class from the Turbine code and we want to use it. Moving it to a commons-text package later would be really nice. Hmm, there are rules, I mean a developer community is required. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Mark R. Diggory wrote: Yes it is clearer, just for reference, my GC discussion at the beginning of this thread involved an article I read awhile back, this article suggested that objects that are created within a static method can get stronger references (or something along these lines) than their non-static counterparts and as such never actually get garbage collected over the life of the JVM. There are no stronger references than ordinary references. Except perhaps j.l.r.PhantomReference (somebody out there who knows what's this actually good for?) There are weaker references though. Perhaps it was meant said objects were referenced by static data, in which case they of course wont be GCd. Unless the object refers to further, perhaps continually growing data structures, this shouldn't cause problems even in a long running server. There are of course several other arguments against static methods and especially against using static data: enterprise java beans can't have static methods at all, and static data can easily become a headache in multithreaded environments. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
Brent Worden wrote: And with HotSpot, frequently executed pieces of code will actually start to increase in performance as a application runs longer, and in many occasions eclipse C or C++ performance. That's what the Java lobby wants you to believe since the introduction of the first JITC. You know, there are lies, damn lies and benchmarks. I can tell you from first hand experience that any well designed Java program which does some nontrivial processing on a dataset of nontrivial size is still two to three times slower than its well designed and optimized counterpart in C/C++ if compiled with gcc, and up to 5 times slower if compiled with Intel C, even with a =1.3 Java compiler and Hotspot on. Lets face it: Hotspot and modern Javac made Java performance acceptable, not superior. The reasons to stick to Java despite this: - Said well designed C/C++ program can easily take 10 times as much ressources in initial development and 5 times in maintenance. - Java is quite often fast enough. If network message turn-around is at 150ms, and the DB takes at least an additional 250ms to answer, then there is no point to get processing time from 60ms down to 20ms. - C/C++ libraries suck orders of magnitude more than Java RT - There is still some appeal in WORA. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
Brent Worden wrote: The only issues I have are with the UnivariateRealSolverFactory class. I feel there should be a separation of the factory method and the solve methods. I don't think the solve method belong on a factory. They are more appropriately placed (do I dare say) in a SolverUtils utility type class. Also, for the factory to provide its intended flexibility, I would reimplement it using the abstract factory design pattern. This allows the factory to be swapped in and out at the user's leisure. I'll take this into account when I'm rewriting the code. That makes sense. I would suggest moving ConvergenceException out of org.apache.commons.math.analysis because I think we'll eventually have a cyclical package dependency with org.apache.commons.math.util as ContinuedFraction depends on ConvergenceException. Well, cyclic dependencies are not the same headache in Java as in other programming environments, but it is usually a good idea to place basic stuff used across several packages into an own package. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
[EMAIL PROTECTED] wrote: I would steer away for primative as much as possible. Keep in mind that excessive object creation can and usually is a significant performance drain, both because it is slow in itself despite all kinds of optimization as well as causing more GC. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
Phil Steitz wrote: I agree. My preference would be to eliminate the original RootFinding.java and refactor the distribution inversion methods to use the new framework. Before taking that step, however, I would like to hear Brent's opinion on what might be improved in the new framework. I've taken a look at this and the other problems. If nobody objects until wendesday or so, I'll ask for karma and hopefully start work on it on weekend. Is this ok? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math][functor] More Design Concerns
Phil Steitz wrote: 3 Both MathException and ConvergenceException don't compile on Java 1.3 and nobody noticed. This is ugly: Ranks inserted (IMHO, of course) Agreed with rankings. However, I think in the long term either the recursive exception should be factored out of [lang] into a separate package for better reuse, or merge [math] with [lang] into a somewhat bigger package resembling a extension to the whole java.lang+java.util+java.text combo. Part of the reason for packing it all into RealMatrix was the need to keep the LU decomposition handy to avoid having to recompute it. I'd think so. Nevertheless, better modularization allows for people which can afford to dive into the more complex network of interfaces to more extensively customize the solving algorithm and, more important, discard the LU-data and other auxillary stuff quickly after it is no longer needed. I'd like to have both: small components for experts and convenient interfaces to allow unsophisticated users to have a quick shot at solving their problem. I have to confess, however, that I have never liked this.add(that) syntax Mee to: it runs counter to how the equations are printed in books for hundreds of years. From this point of view its a pity Java doesn't have user defined operators and operator overloading (this doesn't mean I'd like to have this in Java). I am interested in what others think about this -- especially others who might actually use real matrices in their programs. Whoever uses Java for extensive numerical calculations is soon tempted to abandon it and go either to FORTRAN (maximal performance and the most mature libraries) or C++ (near FORTRAN performance and much improved code maintainability). I see [math] mainly useful for descriptive and partly for analytical statistics, because this functionality is actually used in the business/web service environment where Java is a major player. For the same reason I support the idea of adding financial math functionality (Black-Scholes anyone? :-). Interpolation as it is currently implemented is only of limited use in this context, I guess it would be mostly used to draw a graph of the function (suggestions for adding Java2D integration welcome). There's obviously overlap with graphing/diagram packages like JFreeChart, but we don't have any such package at Apache anyway. Solving linear equation systems may have some use in this environment too, but I can't imagine that general matrix calculations are used on a regular basis. Nobody is going to solve economical networks or calculating magnetical fields in a web application. Well, there is bayesian and vector based text classification, as in statistical spam filtering, of course. Anyone out there willing team up to add graph and diagram layout to j-c-s-graph? The book is Battista et al: Graph Drawing, ISBN 0133016153. Note that to me, solve() is conceptually no different from add But it is. add() represents an operator, solve() represents a complex algorithm, depending on more data like accuracy concerns than add(). 6 Factorials and binominal coefficients Interesting perspective. The uses that I had in mind were for discrete probability distributions Ah, forgot about these. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21023] - [PATCH] [math] Natural splineinterpolation
[EMAIL PROTECTED] wrote: Not only does cvs diff generate patches directly against the cvs copies, assuring your diffing against whats presently in the cvs, but you can also add files using it. I didn't manage to do this, the new files were always noted as unknown and were not included in the diff. Should I have 'cvs add' them first? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Tasks remaining for initial release
Al Chou wrote: * Interpolation. Al is working on cubic spline interpolation. Right? Right. Sorry if I preempted your work, but I just posted cubic spline interpolation to bugzilla for general review. There are a few design questions, to be discussed separately, and the unit test still need work. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] design patterns (was Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java)
Phil Steitz wrote: The limitation on overriding is a serious concern and that is why in an earlier post, I suggested that we never use static methods for complex algorithms. An argument could be made that it would have been better to implement the methods in StatUtils as instance methods and to provide a (singleton) instance factory for users. Have a look at UnivariateRealSolverFactory and check whether you like my approach to cater for both simplicity and flexibility. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Math.pow usage was: Re: cvs commit: ...
Mark R. Diggory wrote: J.Pietschmann wrote: No. If you cast the base into a double there is not much risk of overflow: double x = n; y=x*x; or y=((double)n)*((double)n); or even y=n*(double)n; (but avoid y=(double)n*n). Double mantissa has IIRC 52 bits, this should be good for integers up to 2^26=67108864 without loss of precision. Is this correct, I've been reading (again, if I'm getting this correctly) the doubles mantissa is capable of supporting 15 -17 decimal places, 2^26 is only 8. I meant: you can square integers up to 2^26 without loss of precision (due to truncation). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Math.pow usage was: Re: cvs commit: ...
Mark R. Diggory wrote: (1) It is very important to also use ((double)x)*x instead of (double)(x*x), as the loss of precision starts to occur at far greater values than overflow occurs if one were doing integer arithmetic IIRC Java shares also the C behaviour in that n*n becomes negative instead of signalling an overflow. If this is embedded in a complicated expression you only notice strange results, or not even that. This can be quite hard to debug. I'm too lazy to run a test to confirm this right now, but I'm sure someone else will have done it when I wake up tomorrow :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons-sandbox/math/src/java/org/apache/commons/math/statUnivariateImpl.java
[EMAIL PROTECTED] wrote: - * This product includes software developed by the + * This sumLog includes software developed by the The traps of global sr, I guess... :-) J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Clover licenses
Tim O'Brien wrote: I have commons-math and commons-codec clover licenses which are available to any commons committer who asks, and are housed on apache infrastructure. I think it would be cleaner from a legal standpoint if someone like Robert asked for a commons-wide license, or better yet if the PMC asked for a Jakarta-wide clover license. One could try to get hansel http://hansel.sourceforge.net/ or quilt http://quilt.sourceforge.net/ up and running. Neither is as fancy as Clover, or will even run out of the box, but then, active work on an OSS code coverage tool for Java should be a good idea. Particularly, quilt seems almost dead, which is a pity. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Math.pow usage was: Re: cvs commit: ...
accum += Math.pow(values[i], 2.0); I think Math.pow should not be used for small integer exponents, in particular 2,3 and perhaps 5. You could do this in FORTRAN or other languages with a built-in power operator, because the compiler will optimize it, but languages without that usually rewrite pos(x,y) as exp(y*log(x)). This is bad for precision, in particular if x is very small, and somewhat bad for performance (taking time of one multiplication and two divisions, typically costing 3 to 20 times as much as a multiplication each). I'm not sure how Java handles it, but the loss of precision may be responsible for the unexpected negative values. I'd recommend to replace pow(x,2) by x*x, pow(x,3) by x*x*x and pow(x,4) by a=x*x, y=a*a. It doesn't matter much whether x is an expression because the compiler will take care of it and eliminate redundant computation, however code may be more redable if a temporary variable is used. If x is an integer, an explicit cast to double may be necessary to avoid integer overflow. Math.pow should only be used if the exponent is larger, not an integer, or not a constant. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Complex dilemmas
Al Chou wrote: Cool reference, thanks. Did you mean study the source code? Yes, last time I looked it contained some entertaining remarks in the comments, see http://www.mersenne.org/source.htm From memory, the story was like 1. Implement FFT straightforwardly. It's slow. 2. Leverage the CPU L1 cache: reshuffle the data so that the data access is localized despite the FFT access pattern, and break up loops so that half of the L1 cache can hold the source and the other half the result of the calculations in the loop. It's still slow. 3. Oops, there are the FFT constants which should fit in the L1 cache as well. Cut down and rearrange loops. It's still slow. 4. Take L1 cache organisation in account. If certain bits of the starting address of some data snippets are the same, the cache will allocate only a few lines for storing them, then start over with the first allocated line. Naturally, if a large continous array is loaded this will cause thrashing, even though there are still free lines. Introduce gaps to offset starts of cache lines so that the whole L1 cache can be leveraged. It's *still* slow. 5. Perhaps doing some tricks with early flushing dirty cache lines and other stuff, I don't quite remember. 6. Take L2 cache organization into account. Further reshuffling and introducing gaps. Write macros to generate the assembler code, because nobody can keep track of all the permutations without going insane. Beyond a certain size, it is *still* slow. 7. Remember the processor has a TLB, which maps the logical address space of the process into the physical RAM address space. As usual, thrashing happened, causing frequent reloads of mapping data from the main RAM which is both expensive in itself and swapped valuable data out of the L2 cache. Introduce large gaps in the data to avoid this. This was the *only* time I ever read about a non-kernel programmer having to take this into account. This was from 1998 or so, and somewhat specific for the Pentium architecture. More recent processors have larger caches and slightly different cache organizations, in particular a L2 cache on chip, there are changes in write back handling, there may be a L3 cache, RAM access has become more important, and processors aquired SIMD instructions which are now used. Note that professional numeric libraries have to deal with similar problems when it comes to handling large matrices. Have fun! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] proposed ordering for task list, scope of initial release
Al Chou wrote: So I pulled out Herr Pietschmann's Brent method class and tested it, and it threw an exception telling me, Possibly multiple zeros in interval or ill conditioned function. Caused by an incomplete and much too naive implementation. I have now a real implementation of Brent (Brent-Dekker) ready and could try to submit a patch over the weekend. - It's easy to outsmart yourself and create code that's too finicky for non-numericist users. Non-numericists (or whatever) tend to underestimate the traps in numericals calculation because the vast majority of the problems behave well with modern algorithms most of the time. Unfortunately, unforseen misbehaviour tends to come up at the worst possible time, often with the user barely noticing that something was wrong. In particular for root finding: - The function for which a zero is sought could be implemented badly, with excessive round-off error and/or bit-cancellation, like naive evaluation of dense high order polynominals. This may significantly displace the zero point, and it often leads to multiple numerical roots where only one was analytically expected. - The function may be inherently or numerically ill conditioned, like x*sin(1/x) near zero or ((x-1)^1000)*x^50 for a 50 bit mantissa. - It's hard to know in advance when to trade the performance for robustnesss. A criterium for root finders is how often the function is evaluated, and it is generally assumed this is a expensive compared to any calculation the solver could make. This can make a difference between bisection, which gives a bit per evaluation and needs ~53 iterations for an improvement of 10E-16 in accuracy, whether the function is well behaved or not, and Newton, which ideally doubles the correct bits per evaluation and needs ~5 iterations (evaluating of *two* functions) for a 10E-16 improvement. Obviously, if accuracy matters and function evaluation is slow, fast algorithms are hard to avoid but precisely defining the necessary accuracy and telling what is slow can be time consuming and hair-rising. - Detailed knowledge about the function (and other aspects of the problem) beats all kind of clever guesses by sophisitcated solving engines all the time. Most algorithms are only really robust if you can provide a bracket for the zero. For general functions, this is as hard or harder than nailing down the root itself. If you know the function has a smooth second derivative and no zero in the first derivative in a certain interval (like x1) just use newton, if necessary with a numerical derivative, or the secant method without bracketing and you'll get your root, if it exists. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] proposed ordering for task list, scope of initial release
Phil Steitz wrote: That's where I started, but then Tim and others convinced me that it was actually better/more convenient for users for us to behave more like java.Math and java's own arithmetic functions -- which use NaN all over the place. Uh, oh. That's probably because of IEEE 854 does so. Returning NaNs as well as throwing RuntimeExceptions is appropriate if checking for problems would unnecessarily clutter the whole program code, in particular if the exceptional conditions can potentially occure often in a small amount of source code while in reality occuring rerely. I mean, You certainly don't want to declare an ArrayOutOfBoundsException just because you want to make an array access, in particular if the index has already been checked elswhere for other reasons. Keep also in mind that NaNs had been invended before high level languages generally aquired reasonable mechanisms for handling exceptions, and that this means the hardware is designed to deal with NaNs rather than throwing exceptions. Java probably adopted NaNs mainly because checking every FP operation for a NaN would have been an utter performance killer. The question is: can the user be expected to provide more often valid input to commons-math methods than not? If so, will checking for a math exception clutter the user's routines too much? Also, from a usage standpoint, if we use checked exceptions everywhere, this is a bit inconvenient for users. We need to find the right balance. Exactly. It is, however, common for libraries to use checked exceptions. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] financial functions?
O'brien, Tim wrote: Alternatively, application areas should be separate modules entirely This could invite people to propose a jakarta-commons-sandbox-financial module... J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] proposed ordering for task list, scope of initial release
Al Chou wrote: I may have time to submit my Ridders' method implementation using J.'s framework before he returns 2 days hence. Should I bother to try, or should I wait until he submits his code as a patch via Bugzilla? I'm a bit short on spare time anyway. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] proposed ordering for task list, scope of initial release
Phil Steitz wrote: My philosophy on this is that whatever exceptions we define should be close to the components that throw them -- e.g. ConvergenceException. I do not like the idea of a generic MathException. As much as possible, I think that we should rely on the built-ins (including the extensions recently added to lang). Regarding ConvergenceException, I am on the fence for inclusion in the initial release, though I see something like this as eventually inevitable. Correct me if I am wrong, but the only place that this is used now is in the dist package and we could either just throw a RuntimeException directly there or return NaN. I do see the semantic value of ConvergenceException, however. There are several approaches to design a concept for exceptions, all of which have pros and cons. I personally would suggest to avoid returning NaNs and throwing RuntimeExceptions whereever possible and use a package specific hierarchy of declared exceptions instead. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] proposed ordering for task list, scope of initial release
Al Chou wrote: Finally, having used the Pietschmann root finder framework, I think it needs some modification to make it more user-friendly. As a lay user, I would have been much happier dealing with Brent W.'s interface than Herr Pietschmann's, which was kind of cumbersome. I think, though, with a little slimming down, it would be quite workable. I'm interested in hearung a few more details: what makes the framework cumbersome? Admittedly I didn't have time yet to look at Brent's framework. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
[EMAIL PROTECTED] wrote: Just because we the creators of the framework see no need for higher order derivates, the end users, whose needs no one can fully enumerate, may have a quite reasonable use for them. Well, I designed the interface as a helper for a variety of numerical algorithms, not for general use. It's the way the user supplies his function to solvers. Solvers rarely need higher derivatives. If a solver has to use a third or higher derivative, we can still extend the interface. If someone else wants to use an algorithm which needs higher derivatives, he can use his own mechanism or extend what is available on his own. If you create a function, you control the implementation for creating the derivative function object and is directly coupled to your object. The implementor, you, Not quite. I expect a variety of prebuild function objects and perhaps some mechanisms for more generic definition of functions, but if push comes to shove, it's the user of j-c-math who has to code a class for supplying his function to the solver. I want to think him of the calculations to be closely related. [rearranged] Why can't the domain of interest and explicit input be a single value? That's exactly how I did the CDF stuff using a root finding method which needs a bracket and it worked fine. And it's a generic process that could be incorporated into all the solvers. Nice, build a modular system: an interval(or bracket)-from-start-value builder and solvers which need an interval (or more likely a bracket). You can provide convenience objects which combines everything. When did I introduce finding all roots into this discussion? You didn't. A solver might not find the root closest to the start value, with no indication that there is a root closer to the start value than the reported root. I mean something like start value 0, expected root near 0.5, reported root 1E15. I wager a guess this will irritate a few people. OTOH, letting the solver do heavy checking every time just in case may be seen as an unnecessary overhead to more advanced users, and because this *will* be equivalent to the problem of finding *all* roots in general, it is often impossible. Note that the most difficult part in root finding is not finding the root, but detecting when you stray out of the domain of applicability of the algorithm and detecting ill conditioned problems. Having the user to supply an interval is no guarantee that he knows what he is doing, but if the interval size is much larger than the required accuracy suggests, implementations could just bail out. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
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 x0x2x1 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 -400,+40 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Priority
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 m.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
