Thanks James.
I wanted to pull the comparator classes over from Collections as I
wanted to still be able to support them (and use internally as I
already had ComparableComparator hidden away) without having to deal
with all of Collections.
Maybe the answer though is to ignore them in favour of Or
Thank you Henri.
Somehow I missed the JCS project, which looks to be superior to cache.
-Greg
On Fri, Aug 26, 2011 at 11:49 PM, Henri Yandell wrote:
> Very, very dead.
>
> You have to dig deeper to get the real dates, 2007 is when it moved
> out of being inside Jakarta.
>
>
> http://svnsearch.
Very, very dead.
You have to dig deeper to get the real dates, 2007 is when it moved
out of being inside Jakarta.
http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fjakarta%2Fcommons%2Fsandbox%2Fcache
Looks like it was an import of code by rwaldhoff in May 2001, and that
was pretty much it.
Hello,
I was poking around commons and noticed the dormant project Commons Cache.
The subversion history shows the last push occurred in 2007. What is the
story with the project? Has other java technology supplanted this project?
Thanks,
-Greg
In Mahout, all of this works pretty well without needing the information
that you are suggesting.
Inversion is not supported, of course, but a solve method on Diagonal can
definitely know what to do. See CholeskyDecomposition for an example.
Addition of a diagonal matrix to a normal matrix works
Okay, here we go!
Yes, every matrix can be written or considered sparse. My point is that
knowing the sparsity obeys a pattern (say diagonal) makes your life easier.
Maybe my muddled discussion has added more confusion, an example is in order
(to maximize the entropy, of course). If I was going t
Hi,
On 26 August 2011 20:06, Simone Tripodi wrote:
> Hi Matt,
> sorry for the late and for (maybe) silly question, but what's your PoV
> about making classes Vs methods as 'final'?
>
If I lived in a world without dependency injection, then I'd favour final
classes where I wanted to prevent sub-
Hi Matt,
sorry for the late and for (maybe) silly question, but what's your PoV
about making classes Vs methods as 'final'?
Many thanks in advance, have a nice day!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Aug 25, 2011 at 6:11 PM, Matt Benson wrote:
> On W
On Fri, Aug 26, 2011 at 7:38 AM, Greg Sterijevski wrote:
> Ted,
>
> When you say
>
> "Functions are good, but giving a tiny bit
> more information to the function is also a great idea"
>
> do you mean information on indexing and shape of the data?
>
I meant the location of the element. For inst
Hello everyone,
>
> 0) key/value pairs that are "consistently used by everyone throwing
> such an exception" should be named properties of the exception. So
> in your example of the offending linear operator in
> NonPositiveDefiniteLinearOperatorException, the exception should
> expose a getOffen
On Fri, Aug 26, 2011 at 2:50 AM, Luc Maisonobe wrote:
> Thanks, Ted. That does look very flexible and approachable too. ...
>>
>
> I like the view approach, but wonder how it scales ... down for small data.
>
I doubt that it does scale all the way down. But then again, I doubt that
it matters
On 8/26/11 9:22 AM, Honton, Charles wrote:
> I recommend reviewing Chapter 9 "Exceptions" of Joshua Bloch's "Effective
> Java". In particular, look at Item 63, "Include Failure-Capture
> Information in Detail Messages".
Yes, +1 to that. We do a decent job of that now with exception
messages in [
I recommend reviewing Chapter 9 "Exceptions" of Joshua Bloch's "Effective
Java". In particular, look at Item 63, "Include Failure-Capture
Information in Detail Messages".
Chas
On 8/26/11 8:59 AM, "Phil Steitz" wrote:
>On 8/25/11 11:15 PM, Sébastien Brisard wrote:
>> Hi,
>>
>>> One thing that
On 8/25/11 11:15 PM, Sébastien Brisard wrote:
> Hi,
>
>> One thing that I think we all agree on; however, is that we should not be
>> designing exceptions or APIs that throw exceptions with the intent that
>> applications catching exceptions should parse the messages or search
>> the message conten
Ted,
When you say
"Functions are good, but giving a tiny bit
more information to the function is also a great idea"
do you mean information on indexing and shape of the data?
One thought I had, I am not sure if this is 100% applicable is the
following:
1. You have two types of data (in matrix
Hello.
>
> 2011/8/26 Sébastien Brisard
>
> >
> > In other words, having this kind of context with documented keys would
> > help the end-user debug his own code. I hope I'm making my point
> > clearly, there.
> >
>
> More info attached to exceptions is great. I often find that the first half
>
Hi,
2011/8/26 Sébastien Brisard
>
> In other words, having this kind of context with documented keys would
> help the end-user debug his own code. I hope I'm making my point
> clearly, there.
>
More info attached to exceptions is great. I often find that the first half
of fixing a bug is adding
>
> Do you mean that the context info for a (hyptohetical) method like
> doSomething(LinearOperator a, LinearOperator b)
> would be like
> offending operator: a
> or
> offending operator: b
> ?
>
> If so, is it not enough to just throw the exception? Won't it be obvious
> which operator is "offe
Hi.
> > I am assuming that the main difference between using the "ExceptionContext"
> > and passing information in the exception's constructor is that in the
> > latter, the information will unconditionally appear in the string returned
> > by "getMessage". The contents of the "ExceptionContext" m
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 Gilles,
thanks for this answer.
>
> I am assuming that the main difference between using the "ExceptionContext"
> and passing information in the exception's constructor is that in the
> latter, the information will unconditionally appear in the string returned
> by "getMessage". The contents of
Hello Sébastien.
> >
> > One thing that I think we all agree on; however, is that we should not be
> > designing exceptions or APIs that throw exceptions with the intent that
> > applications catching exceptions should parse the messages or search
> > the message content for specific strings.
> >
Le 26/08/2011 07:45, Phil Steitz a écrit :
On 8/25/11 8:11 AM, Ted Dunning wrote:
> 2011/8/25 Sébastien Brisard
>
>> Hi Ted,
>>
>>> You missed my suggestion.
>>>
>> are you referring to the thread named "New method: "addToEntry" in
>> "RealVector""?
>> If yes, I initially thought that what you su
Google Guava has Ordering:
http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Ordering.html
It is an incredibly useful class. Some random example of how it's awesome:
http://www.polygenelubricants.com/2010/10/elegant-comparison-logic-with-guava.html
Recommend that
Looking at the Collections ComparatorChain class, I think it's overcomplicated.
The current API is:
public class ComparatorChain implements Comparator, Serializable {
public ComparatorChain() {
public ComparatorChain(Comparator comparator) {
public ComparatorChain(Comparator comparato
25 matches
Mail list logo
