Opened 15 years ago
Closed 15 years ago
#193 closed defect (fixed)
Serious flaw: matrix mutation functionality and view does not work properly
Reported by: | Jari Häkkinen | Owned by: | Jari Häkkinen |
---|---|---|---|
Priority: | blocker | Milestone: | yat 0.3 (Public release) |
Component: | utility | Version: | trunk |
Keywords: | Cc: |
Description
Several of the matrix mutable functions ignores the fact that a matrix can be a view. In many cases this is the desired effect but in some cases this is plain stupid.
One example: If a matrix is a view, then a transpose on that matrix will work (somewhat). It will not break the viewed matrix but the next operation on the transposed matrix will created unexpected results since the view is still active whereas the user probably expects to work on the transpose. The question is, should the effects on the transposed matrix be reflected on the underlying viewed matrix.
We need to discuss and define how we want treat view and operator*=, operator=, and more.
Change History (8)
comment:1 Changed 15 years ago by
comment:2 Changed 15 years ago by
We have decided:
- Copy constructor results in a normal vector/matrix - never a view
- in assignment operator underlying data are affected (in case LHS is a view), which implies view/normal-state is not assigned.
- in assignment dimensions must agree otherwise exception is thrown
comment:3 Changed 15 years ago by
Status: | new → assigned |
---|
comment:4 Changed 15 years ago by
comment:7 Changed 15 years ago by
comment:8 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
We took a decision look time ago (Dec 05) that calling operator= on a view (LHS) should not change the viewed matrix/vector. I have experienced some unexpected behaviour because of this and I'm not sure that was a wise decision.
On the contrary, I am more than open to consider a change of this decision. Most important is that we are consistent all trough the class(es), and thereby make it easier to the user to understand the behaviour. I can see three solutions
My gut feeling is that 1) is inferior to 2) and 3), simply because locking views to be const is not a restriction in the margin. Also I am not sure it technically is possible to implement without a HUGE amount of man months. If we go for 3), it is tempting to go for the full monthy and implement all copying as lazy copying. A copy is not deep copied until it is necessary. This might be misleading becasue what happens when the underlying data goes out of scope? Underlying GSL matrix cannot be destroyed in destructor but must be dealed in some other way. Ref Counter? With a significant risk of being shallow, I think 2) is the preferable option. Among other reasons it allows code like
which actually modifies m. This implies that a view is a view also after calling operator= in contrast to the implementation at time being. Should a normal vector/matrix be a normal vector/matrix also after calling operator=? I presume the answer is yes. More interestingly, what happens to those views that are looking in to this normal vector/matrix? They must be modified too, right? But what happens if the dimension of the normal vector/matrix is changed? A related issue is whether the view/normal-state should be copied in copy constructor, in other words , what is displayed from this code: