Hi Ted,
I think we might have a misunderstanding. What I am discussing is not the
general implementation for a matrix, but the base interface that would be
required for input into optimizers. I was saying that there should not be a
burden of implementing visitor pattern for users creating a
Hi!
Not sure if this is worth doing, but could be nice from a usability pov.
Usually projects have a lot of blocks which need doPrivileged copied over from
one class to the other.
Using @Privileged makes this a lot easier. But you still need to add private
methods to all your classes...
Now
On 12/29/12 1:08 AM, Luc Maisonobe wrote:
Le 29/12/2012 04:09, Gilles Sadowski a écrit :
Hi.
Hi Gilles,
[...]
third is just bug-fix. Does the fix for the issue that started this
thread change the API? If so, we would need to cut 3.2 in any case.
The current fix does change the usage (one
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25611projectId=72
Build statistics:
State: Failed
Previous State: Ok
Started at: Sun 30 Dec 2012 18:20:07 +
Finished at: Sun 30 Dec 2012 18:21:46 +
Total time: 1m 39s
Build Trigger: Schedule
Hi,
In my opinion is that the whole weights fiasco is consequence of
improper design, as much as anything else. All components should be
as simple as possible, with any additional add ons, like weights,
not added to the base implementation, but instead done as an extension
of these classes. If
Dim has it exactly right here.
On Sun, Dec 30, 2012 at 10:38 AM, Dimitri Pourbaix pourb...@astro.ulb.ac.be
wrote:
In optimization, the user supplies the function to be minimised. In curve
fitting, the user supplies a series of observations and the model to be
fitted. Trying to combine both
Konstantin,
We are close then. Yes optimization should use vector methods as possible.
But visitor functions are very easy to add in an abstract class. They
impose very little burden on the implementor.
On Sun, Dec 30, 2012 at 8:52 AM, Konstantin Berlin kber...@gmail.comwrote:
I think we
Hello,
Using the visitor pattern as a way to implement in-place basic linear
algebra operations was only a suggestion, I am not sure it's the best
option, even if I do think it's a simple and elegant option. However...
I think we might have a misunderstanding. What I am discussing is not the
The GPU requires native code that is executed on the GPU. Standard linear
algebra libraries exist for this so if the API can express a standard
linear algebra routine concisely, then the GPU can be used. General Java
code usually can't be executed on a GPU.
There is some late breaking news on
On Dec 30, 2012, at 2:26 PM, Sébastien Brisard sebastien.bris...@m4x.org
wrote:
Hello,
Using the visitor pattern as a way to implement in-place basic linear
algebra operations was only a suggestion, I am not sure it's the best
option, even if I do think it's a simple and elegant option.
We should just move the non-development stuff (stuff that we'll run in
a CI environment, though) into a profile.
On Sat, Dec 29, 2012 at 7:28 PM, Olivier Lamy ol...@apache.org wrote:
2012/12/29 Oliver Heger oliver.he...@oliver-heger.de:
Am 29.12.2012 21:21, schrieb Phil Steitz:
On 12/29/12
On Sun, Dec 30, 2012 at 12:16 PM, Konstantin Berlin kber...@gmail.comwrote:
...
There would be no burden on the user's side: the visitor pattern has been
implemented for RealVectors in version 3.1. Besides, we could provide all
the relevant visitors (addition, scaling, …)
There is an
Hello.
[As Phil suggested, please stop extending this thread; and rather open new
ones on specific points in order to focus the discussion(s).]
Yes, abd I agree with that. However, I found the javadoc to be
ambiguous. It says The following data will be looked for: followed by
a list. There
On Sun, Dec 30, 2012 at 09:50:11PM -, pste...@apache.org wrote:
Author: psteitz
Date: Sun Dec 30 21:50:11 2012
New Revision: 1426997
URL: http://svn.apache.org/viewvc?rev=1426997view=rev
Log:
Documented commons.componentid ambiguiity and workaround.
Modified:
Hello.
Are there lessons to be drawn from the problem discovered just after the
recent release? Apart from pointing fingers, that is. :-}
I presume that people who voted for the release did as thorough a review as
they could.
And the problem is not primarily one of unit test coverage. Some use
On 12/30/12 2:45 PM, Gilles Sadowski wrote:
On Sun, Dec 30, 2012 at 09:50:11PM -, pste...@apache.org wrote:
Author: psteitz
Date: Sun Dec 30 21:50:11 2012
New Revision: 1426997
URL: http://svn.apache.org/viewvc?rev=1426997view=rev
Log:
Documented commons.componentid ambiguiity and
On 12/30/12 4:01 PM, Gilles Sadowski wrote:
Hello.
Are there lessons to be drawn from the problem discovered just after the
recent release? Apart from pointing fingers, that is. :-}
Most important point - don't do that (point fingers) :)
I presume that people who voted for the release did
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-dbcp has an issue affecting its community integration.
This issue
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-dbcp2 has an issue affecting its community integration.
This
Hi Gilles,
Gilles Sadowski wrote:
Hello.
Are there lessons to be drawn from the problem discovered just after the
recent release? Apart from pointing fingers, that is. :-}
I presume that people who voted for the release did as thorough a review
as they could.
And the problem is not
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-digester3 has an issue affecting its community integration.
This
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-net-test has an issue affecting its community integration.
This
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-chain2 has an issue affecting its community integration.
This
Looks like it could be - just need to explicitly set to null in
argumentless constructor. Also, do we really want / need the
degenerate case (no data)?
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
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-dbutils has an issue affecting its community integration.
This
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
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-scxml-test has an issue affecting its community integration.
This
27 matches
Mail list logo
