I'm sorry. Coming up to work, I've realized that my previous
suggestion was silly.
>
> Instead of having a method
> RealVector getSolution()
> how about specifying
> RealVector getSolution(boolean deep)
> if deep is true, it returns a deep copy, if not it MIGHT (but the
> contract of the method doe
On 8/11/11 8:41 PM, Sébastien Brisard wrote:
> Hi,
> it's clear I think that there is no really fool-proof solution, but
> that's OK I think. The idea would be to avoid accidental modifications
> which could be catastrophic. But nothing could prevent an evil
> programmer to do its evil job. I like
Hi,
it's clear I think that there is no really fool-proof solution, but
that's OK I think. The idea would be to avoid accidental modifications
which could be catastrophic. But nothing could prevent an evil
programmer to do its evil job. I like what was earlier pointed out:
Javadoc should be very de
On 8/11/11 4:22 AM, Gilles Sadowski wrote:
> Hello Sébastien.
>
>>> Well, in fact I would very much like to have immutable vectors too.
>>> Immutability is really a way to simplify implementations. Surprisingly it
>>> sometimes also decrease time and memory consumption, because defensive
>>> copies
Le 11/08/2011 13:29, Sébastien Brisard a écrit :
You can also have a common interface without modification methods, and two
implementations, an immutable one and a mutable one (I think this is how
Scala containers are designed).
Luc
That is I suppose the cleanest approach, but within the solv
Am Donnerstag, den 11.08.2011, 10:55 +0200 schrieb Sébastien Brisard:
> 2011/8/11 Arne Ploese :
> > So you not only want to observe the result, but you want a read only
> > RealVector.
> >
> That's right. I'm sorry, my first message was not clear, especially if
> you did not follow the thread on i
On Thu, Aug 11, 2011 at 01:16:32PM +0200, Luc Maisonobe wrote:
> Le 11/08/2011 12:24, Sébastien Brisard a écrit :
> >>
> >>Well, in fact I would very much like to have immutable vectors too.
> >>Immutability is really a way to simplify implementations. Surprisingly it
> >>sometimes also decrease ti
>
> You can also have a common interface without modification methods, and two
> implementations, an immutable one and a mutable one (I think this is how
> Scala containers are designed).
>
> Luc
>
That is I suppose the cleanest approach, but within the solver's loop,
I need the current solution to
Le 11/08/2011 13:10, Sébastien Brisard a écrit :
2011/8/11 sebb:
2011/8/11 Sébastien Brisard:
OK, this I also think would be useful. But my initial question
remains, if the object I want to protect is not a RealVector, what do
you think of my solution ?
Sébastien
If you create the read-only v
Hello Sébastien.
> >
> > Well, in fact I would very much like to have immutable vectors too.
> > Immutability is really a way to simplify implementations. Surprisingly it
> > sometimes also decrease time and memory consumption, because defensive
> > copies littering user code can be avoided.
> >
>
Le 11/08/2011 12:24, Sébastien Brisard a écrit :
Well, in fact I would very much like to have immutable vectors too.
Immutability is really a way to simplify implementations. Surprisingly it
sometimes also decrease time and memory consumption, because defensive
copies littering user code can be
2011/8/11 sebb :
> 2011/8/11 Sébastien Brisard :
>> OK, this I also think would be useful. But my initial question
>> remains, if the object I want to protect is not a RealVector, what do
>> you think of my solution ?
>> Sébastien
>
> If you create the read-only version by subclassing the writable
2011/8/11 Sébastien Brisard :
> OK, this I also think would be useful. But my initial question
> remains, if the object I want to protect is not a RealVector, what do
> you think of my solution ?
> Sébastien
If you create the read-only version by subclassing the writable
version, then you have to
>
> Well, in fact I would very much like to have immutable vectors too.
> Immutability is really a way to simplify implementations. Surprisingly it
> sometimes also decrease time and memory consumption, because defensive
> copies littering user code can be avoided.
>
Luc, I have a silly question. W
OK, this I also think would be useful. But my initial question
remains, if the object I want to protect is not a RealVector, what do
you think of my solution ?
Sébastien
PS : the problem is likely to occur when listening to other Iterative
Processes (not only linear solvers). For example, in o.a.c
Le 11/08/2011 10:55, Sébastien Brisard a écrit :
2011/8/11 Arne Ploese:
So you not only want to observe the result, but you want a read only
RealVector.
That's right. I'm sorry, my first message was not clear, especially if
you did not follow the thread on iterative solvers.
I want to observe
2011/8/11 Arne Ploese :
> So you not only want to observe the result, but you want a read only
> RealVector.
>
That's right. I'm sorry, my first message was not clear, especially if
you did not follow the thread on iterative solvers.
I want to observe the *solver*, and the current state of the solv
So you not only want to observe the result, but you want a read only
RealVector.
A "clean" solution would be split RealVector in a base interface, which
not modifies any internal Data and a inherited interface which adds
xxxToSelf and setEnty(...). ??? I think this could lead to some
unforseeable
2011/8/11 Arne Ploese :
> What methods do you need?
>
> Maybe an interface with:
> public interface SimpleRealVector {
> double getEntry(int i);
> int getDimension();
> }
> will do?
>
No, I'd like to have *all* methods of the o.a.c.m.linear.RealVector
interface, *except* those which modify the ca
What methods do you need?
Maybe an interface with:
public interface SimpleRealVector {
double getEntry(int i);
int getDimension();
}
will do?
Am Donnerstag, den 11.08.2011, 05:36 +0200 schrieb Sébastien Brisard:
> Hello,
> this is an idea I've had while thinking about Iterative Linear
> So
Hello,
this is an idea I've had while thinking about Iterative Linear
Solvers, but I think it is much more general. I don't know whether
what I'm going to describe is a known pattern, or a very dirty trick I
should forget about. So any advice would be greatly appreciated.
For the sake of the argum
21 matches
Mail list logo
