Good morning,
my proposal for the implementation of linear iterative solvers (JIRA MATH-581)
has raised some comments from Gilles and Luc, but I think no consensus has
been reached on one issue raised by Gilles. Before submitting a new version of
the corresponding classes, I'd like to make a new
Hi,
can you add the patch to svn?
[ ] yes
[ ] no, because ...
Arne
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 4 July 2011 23:13, Jörg Schaible joerg.schai...@gmx.de wrote:
Sorry, why is setValue more vague - isn't it the other way round?
As a method name, replace is explicit, set slightly less so. Either
work here, so if you want to change it go ahead.
More generally, I now think the index suffix
On 6 July 2011 09:52, Jörg Schaible joerg.schai...@scalaris.com wrote:
I can traverse now the set of keys to get this list when it is internally
implemented with a LinkedHashMap. Remember, one important element of a
contexted exception is a more informational and structured message. In the
On Tue, Jul 05, 2011 at 07:45:47PM -0700, Ted Dunning wrote:
Why?
On Tue, Jul 5, 2011 at 2:34 PM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
By the way, shouldn't EITHER_SIDE be renamed to ANY_SIDE?
Because there are more than two sides.
Gilles
Stephen Colebourne wrote:
On 6 July 2011 09:52, Jörg Schaible joerg.schai...@scalaris.com wrote:
I can traverse now the set of keys to get this list when it is internally
implemented with a LinkedHashMap. Remember, one important element of a
contexted exception is a more informational and
Thanks a lot for the review Joerg, much more than appreciated!!!
I have definitively to add those infos on the site, the guide is not
so explicit on that topic :P
No idea why that test hanged :/ I'll investigate anyway which could
cause a starvation.
Thanks once again, have a nice day!
Simo
Hi all guys,
The Digester 3.0 release passes with 3 +1 binding votes from
* Luc Maisonobe
* Simone Tripodi
* Joerg Schaible
no other votes have been casted.
I'll proceed with moving binaries, maven artifacts, closing issues,
deploying site.
Thanks everybody who took part to the review
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On 04/07/2011 15:07, Mladen Turk wrote:
The proposed Apache Commons Daemon 1.0.6 release is now available for
voting.
It can be obtained from:
http://people.apache.org/~mturk/daemon-1.0.6/
The svn tag is:
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6_RC1/
At Ted's suggestion I looked at LSMR in mahout. In general, I have no
complaints about the algorithm or how it is coded up. I have seen the
algorithm in the PrimalDual solver that Micheal Saunders et al cooked up. I
believe the solver is part of the COIN project. I have nothing but praises
for it.
The other way that regression is done at scale is with a linear operator.
This linear operator is often defined by the behavior of some external
system that is not susceptible to incremental construction. A good example
is a large text retrieval system.
It would be useful to support that style
I agree that since we now have LEFT_SIDE, RIGHT_SIDE, ABOVE_SIDE, and
BELOW_SIDE, it makes sense to rename it to ANY_SIDE. Previously, when we only
had the first two, it made more sense to have EITHER_SIDE.
Dennis
Van: Gilles Sadowski
I see. Why would it be a good reason to commingle functionality? Aside from
diagnostics like condition numbers and maybe eigenvalues, these approaches
don't seem to share much commonality. I could be wrong since my knowledge of
Mahout style problems is a bit spotty.
On Wed, Jul 6, 2011 at 11:34
It isn't really necessary to commingle approaches at all. It is just nice
to think about the alternatives at once to get better designs.
It is conceivable that the interface you designed could be a facade over a
lower level linear operator interface where that makes sense. If so, that
is great.
Hi all,
Here are my personal opinions on this entire discussion:
I'm not sure I like the auto-magic under the hood conversion from unbracketed
solver to bracketed solver. I think the BracketingWrapperSolver that was
proposed would keep the clear distinction between the two. This new classs
Also, maybe we would like to add combinations of the four posibilities, to get
LEFT_ABOVE_SIDE, RIGHT_ABOVE_SIDE, LEFT_BELOW_SIDE, and RIGHT_BELOW_SIDE? This
would not only allow for splitting the solution on a single axis, but also on a
combination of both axes.
Dennis
The Apache Commons team is pleased to announce the Apache Commons
Digester 3.0 release!
The Apache Commons Digester package lets you configure an XML to Java
object mapping module which triggers certain actions called rules
whenever a particular pattern of nested XML elements is recognized.
The
I like the following:
It is conceivable that the interface you designed could be a facade over a
lower level linear operator interface where that makes sense. If so, that
is great.
Looking through commons there is public interface DecompositionSolver.
Perhaps an extension of this interface is
Mladen Turk wrote:
The proposed Apache Commons Daemon 1.0.6 release is now available for
voting.
It can be obtained from:
http://people.apache.org/~mturk/daemon-1.0.6/
The svn tag is:
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6_RC1/
Generated
On 7/6/11 10:37 AM, Greg Sterijevski wrote:
I like the following:
It is conceivable that the interface you designed could be a facade over a
lower level linear operator interface where that makes sense. If so, that
is great.
Looking through commons there is public interface
On 7/6/11 11:12 AM, Ted Dunning wrote:
In the simplest instance, an operator based solver might be able to
advertise an incremental accumulation interface if it maintains an internal
representation that could be used as a linear operator. As more data is
added, the internal representation
Indeed.
On Wed, Jul 6, 2011 at 11:36 AM, Phil Steitz phil.ste...@gmail.com wrote:
Up to whoever is doing
the patching :)
Am 06.07.2011 12:11, schrieb Jörg Schaible:
Stephen Colebourne wrote:
On 6 July 2011 09:52, Jörg Schaiblejoerg.schai...@scalaris.com wrote:
I can traverse now the set of keys to get this list when it is internally
implemented with a LinkedHashMap. Remember, one important element of a
I need another advice about the method names of the ExceptionContext.
Currently the interface defines methods like
interface ExceptionContext {
addValue(...);
setValue(...);
getValues(...);
...
};
Looks fine at first glance. However, if I create a ContextedNamingException
I will have
On 6 July 2011 21:45, Jörg Schaible joerg.schai...@gmx.de wrote:
Since the ExceptionContext is especially designed for an exception mix-in, I
wonder if we better use more qualifying names for this use case:
interface ExceptionContext {
addContextValue(...);
setContextValue(...);
Hello.
Here are my personal opinions on this entire discussion:
I'm not sure I like the auto-magic under the hood conversion from unbracketed
solver to bracketed solver.
It's not really under the hood, as the user must specify an enum value to
get the bracketing. The default (ANY_SIDE)
While there is a discussion of solvers going on I thought I would point out
that I have done a Java translation of Dario Bini's implementation of Aberth's
method. I've attached the header of the original Fortran file below. I'd be
happy to donate my translation to Commons Math if there is
Hi Stephen,
Stephen Colebourne wrote:
On 6 July 2011 21:45, Jörg Schaible joerg.schai...@gmx.de wrote:
Since the ExceptionContext is especially designed for an exception
mix-in, I wonder if we better use more qualifying names for this use
case:
interface ExceptionContext {
29 matches
Mail list logo
