Hi everyone,
well the message below did not raise much of an interest... My apology, I
forgot to quote [math] in the title.
Anyway, I have a new proposal regarding this issue. I do not know what your
view on the subject is, but I tend to think that exceptions should return
references and not deep c
With my implicit +1 we have 4 binding votes (Simon, Mark, Jörg and I)
As such, Daemon 1.0.6 has been voted as stable.
I'll copy the files to the dist, and make ANN later today
when majority of mirrors pick up the release.
Thanks to all who helped testing!
Regards
--
^TM
---
AbstractMatrix
On Thu, Jul 7, 2011 at 8:06 PM, Sebastien Brisard wrote:
> Ted,
> Mahout seems to be fairly large (!). What classes should I look at more
> specifically?
> Thanks!
> Sebastien
>
> >The Colt package used a functional style to implement what you suggest.
> > This approach has been i
Ted,
Mahout seems to be fairly large (!). What classes should I look at more
specifically?
Thanks!
Sebastien
>The Colt package used a functional style to implement what you suggest.
> This approach has been inherited by Mahout.
> The basic idea is that there is an assign method that takes other a
Hi
GUI code is out of scope IMO.
Gary
On Jul 7, 2011, at 17:17, Marko Klopcic wrote:
> Hi,
>
> It is probably a bit late, but it is only these days I've checked
> javadoc of the commons-lang ver. 3 on the web, and found contexted
> exceptions. I found the context info useful already some time
Hi,
It is probably a bit late, but it is only these days I've checked
javadoc of the commons-lang ver. 3 on the web, and found contexted
exceptions. I found the context info useful already some time ago, so
I've implemented my own classes, which you can find at
http://www.trimah.com/eng/index.
Hi Hen,
Henri Yandell wrote:
> I think we're ready for another release candidate.
>
> Does anyone know of any remaining items? JIRA is clean, and I don't
> see anything in the email threads that implies more work needs to be
> done.
We have two failing unit tests with Java 7. At least one is du
Stephen Colebourne wrote:
> On 7 July 2011 11:48, Jörg Schaible wrote:
>> One last opinion about the output? Originally we had e.g.:
>>
>> [Handler = PersonConverter]
>> [Current Element = Person]
>> [Role = COO]
>> [Handler[1] = CompanyConverter]
>> [Current Element[1] = Company]
>>
>> The curre
On 03/07/2011 22:43, Phil Steitz wrote:
> On 7/3/11 12:32 PM, Mark Thomas wrote:
>> On 26/06/2011 01:05, Phil Steitz wrote:
>>> On 6/25/11 4:28 PM, Mark Thomas wrote:
On 17/06/2011 09:02, Mark Thomas wrote:
> On 17/06/2011 00:32, Gary Gregory wrote:
>> I think 2.0 is the opportunity to
It sounds similar to the trove approach, but I couldn't say with certainty.
On Thu, Jul 7, 2011 at 11:10 AM, Sebastien Brisard <
sebastien.bris...@polytechnique.org> wrote:
> That sounds interesting. I was thinking of something like mapping a
> bivariate
> function to two vectors, but was afraid
That sounds interesting. I was thinking of something like mapping a bivariate
function to two vectors, but was afraid of performance issues. Your feedback
on this is encouraging!
As for the approach used in Mahout, is it similar to the "Procedure"s in GNU
Trove? It takes a little bit of time to gra
The Colt package used a functional style to implement what you suggest.
This approach has been inherited by Mahout.
The basic idea is that there is an assign method that takes other arguments
and a function for combining the arguments. The function allows great
amounts of flexibility and promote
Hey,
On Thu, Jul 7, 2011 at 9:56 AM, Gary Gregory wrote:
> Hi All:
>
> I do like using NullArgumentException, but I find writing this over and over
> tedious:
>
> if (arg == null) {
> thrown new NullArgumentException(argName);
> }
> something(arg);
>
> How about this instead:
>
> NullArgumentExc
On Thu, Jul 7, 2011 at 1:17 PM, Gary Gregory wrote:
> On Thu, Jul 7, 2011 at 1:11 PM, Matt Benson wrote:
>
>> On Thu, Jul 7, 2011 at 11:56 AM, Gary Gregory
>> wrote:
>> > Hi All:
>> >
>> > I do like using NullArgumentException, but I find writing this over and
>> over
>> > tedious:
>> >
>> > if
On Thu, Jul 7, 2011 at 1:11 PM, Matt Benson wrote:
> On Thu, Jul 7, 2011 at 11:56 AM, Gary Gregory
> wrote:
> > Hi All:
> >
> > I do like using NullArgumentException, but I find writing this over and
> over
> > tedious:
> >
> > if (arg == null) {
> > thrown new NullArgumentException(argName);
>
I use an Assert class (similar to commons Validate):
Assert.notNull(argName, arg);
http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/base/util/Assert.html
The difference is it throws IllegalArgumentException.
-Adrian
On 7/7/2011 5:56 PM, Gary Gregory wrote:
Hi All:
I do like usin
On Thu, Jul 7, 2011 at 11:56 AM, Gary Gregory wrote:
> Hi All:
>
> I do like using NullArgumentException, but I find writing this over and over
> tedious:
>
> if (arg == null) {
> thrown new NullArgumentException(argName);
> }
> something(arg);
>
> How about this instead:
>
> NullArgumentExceptio
Hi All:
I do like using NullArgumentException, but I find writing this over and over
tedious:
if (arg == null) {
thrown new NullArgumentException(argName);
}
something(arg);
How about this instead:
NullArgumentException.check(arg, argName);
something(arg);
or:
something(NullArgumentException
On Thu, Jul 07, 2011 at 03:40:19PM +0200, Luc Maisonobe wrote:
> Le 07/07/2011 14:41, Gilles Sadowski a écrit :
> >Hi.
> >
> >>>We also do not have a clear separation between algorithms that take a
> >>>bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> >>>If the "solve" met
Hello.
> in Blas, the method DAXPY can lead to very compact code. As far as I know, it
> has no equivalent in RealVector. There are a few method called ToSelf,
> which modify the calling vector, instead of returning a new one, but these are
> restricted to scalars operating on vectors.
> In ot
Le 07/07/2011 14:41, Gilles Sadowski a écrit :
Hi.
We also do not have a clear separation between algorithms that take a
bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
If the "solve" methods called by the user contains more parameters than
needed by the algorithm imple
Le 07/07/2011 10:31, Sebastien Brisard a écrit :
Hi,
Hi Sébastien,
in Blas, the method DAXPY can lead to very compact code. As far as I know, it
has no equivalent in RealVector. There are a few method called ToSelf,
which modify the calling vector, instead of returning a new one, but thes
Hi.
> > We also do not have a clear separation between algorithms that take a
> > bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> > If the "solve" methods called by the user contains more parameters than
> > needed by the algorithm implemented in the instance, they will
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 7 July 2011 11:48, Jörg Schaible wrote:
> One last opinion about the output? Originally we had e.g.:
>
> [Handler = PersonConverter]
> [Current Element = Person]
> [Role = COO]
> [Handler[1] = CompanyConverter]
> [Current Element[1] = Company]
>
> The current output does no longer have the
Hi Stephen,
Stephen Colebourne wrote:
> On 7 July 2011 00:57, Jörg Schaible wrote:
>> Proposed changes done. Please review, especially also Javadoc as I'm a
>> non- native speaker.
>
> Done. I think you could remove the add/set methods taking a Pair. The
> other add/set methods taking two argum
On 7 July 2011 00:57, Jörg Schaible wrote:
> Proposed changes done. Please review, especially also Javadoc as I'm a non-
> native speaker.
Done. I think you could remove the add/set methods taking a Pair. The
other add/set methods taking two arguments is sufficient, and I can't
see when the Pair
Hi,
in Blas, the method DAXPY can lead to very compact code. As far as I know, it
has no equivalent in RealVector. There are a few method called ToSelf,
which modify the calling vector, instead of returning a new one, but these are
restricted to scalars operating on vectors.
In other words, the
Le 07/07/2011 09:35, Dennis Hendriks a écrit :
Hi Gilles,
> We also do not have a clear separation between algorithms that take a
> bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> If the "solve" methods called by the user contains more parameters than
> needed by t
Hi Gilles,
> We also do not have a clear separation between algorithms that take a
> bracket (e.g. "BrentSolver") and those that don't (e.g. "NewtonSolver").
> If the "solve" methods called by the user contains more parameters than
> needed by the algorithm implemented in the instance, they will
30 matches
Mail list logo
