Hi Stephen,
Stephen Colebourne wrote:
> On 6 July 2011 21:45, Jörg Schaible 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(...);
>>
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 inte
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 ("AN
On 6 July 2011 21:45, Jörg Schaible 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(...);
> getContextValues(...);
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
cla
Am 06.07.2011 12:11, schrieb Jörg Schaible:
Stephen Colebourne wrote:
On 6 July 2011 09:52, Jörg Schaible 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 infor
Indeed.
On Wed, Jul 6, 2011 at 11:36 AM, Phil Steitz wrote:
> Up to whoever is doing
> the patching :)
>
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
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 could be augmented and then whatever form
exist
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 Decompositi
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
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 wha
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 A
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
__
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
wou
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.
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 AM
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 [gil...@harfang.ho
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
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.
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_
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
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 process
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
htt
Stephen Colebourne wrote:
> On 6 July 2011 09:52, Jörg Schaible 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
>
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
--
On 6 July 2011 09:52, Jörg Schaible 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
> list above I can see quite
Hi Stephen,
Stephen Colebourne wrote:
> On 4 July 2011 23:13, Jörg Schaible 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.
May be I am simply bia
On 4 July 2011 23:13, Jörg Schaible 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 scheme is wrong. It
shou
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
30 matches
Mail list logo
