re: [eigen] API change proposal

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


I have a problem which I believe is related to this question.
Right now the solve() method does not accept a temporary as a result type
(like a block type):
- resize() is not defined for temporaries. See the half-done patch to Block.h
that addresses that.
- gcc (at least my version: 4.3.1) warns about "taking the address of a
temporary".
Using the patch I can store the result of LU::solve() in a matrixXd::block()
but I am not sure if this behavior is conforming to the standard... Would
passing a reference help in that case?

Best regards

Tim Hunter

On Thursday 23 July 2009 07:31:41 Kenneth Riddile wrote:
> I'll chime in here...When I see a function that takes any type of pointer
> (const/non-const) as a parameter, this signals to me that null is a valid
> value to pass to the function.  If null is not a valid value, then the
> argument should be passed by reference.  As far as whether or not it's
> obvious from the call site whether the argument may be modified, one has to
> assume that a user/maintainer will look at the signature of the function
> when trying to understand its purpose.  A function's signature is its
> public interface after all.
>
> --- On Thu, 7/23/09, Markus Fröb <grey_earl@xxxxxx> wrote:
>
> From: Markus Fröb <grey_earl@xxxxxx>
> Subject: Re: [eigen] API change proposal
> To: eigen@xxxxxxxxxxxxxxxxxxx
> Date: Thursday, July 23, 2009, 5:37 AM
>
>
> I agree with Patrick; as in what I have encountered so far, const
> (reference/pointer) always meant the object won't be modifed, non-const
> (reference/pointer) meant the object is potentially modified, thereby
> signaling this is an output argument. Insofar there is (for me) no
> difference between pointer and reference.
>
> Markus
>
> > Von: "Patrick Mihelich" <patrick.mihelich@xxxxxxxxx>
> > I agree with Markus. Even ignoring the naming (ResultType, result),
> > the fact that the reference is non-const signals that it is an output
> > of the function.
> >
> > Patrick
> >
> > On Wed, Jul 22, 2009 at 3:30 PM, Andrea Arteaga <yo.eres@xxxxxxxxx>
> > wrote:
> > In principle, I'm agree with Markus, since pointers in C++ can be
> > considered as low-level concept
> > and Eigen allows a high-level manipulation of objects; that pointers
> > could be "out of place".
> >
> > But: when a method of LU (or QR) takes a reference as argument, is it
> > clear to users that the
> > function will modify that argument? Pointers are the classical system
> > to output something, which
> > cannot be the return value. In spite of the practicality of
> > references, pointers make clear that the
> > argument is a "output argument", not an input one.
> >
> > However, Eigen could also provide both behaviours by overloading the
> > method.
> >
> > Andrea Arteaga
>
> ________________________________________________________________
> Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
> für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

--
Timothy Hunter
Master Student
Electrical Engineering
Stanford University
http://ai.stanford.edu/~tjhunter/
T. 404 421 3075



-- 
Timothy Hunter
Master Student
Electrical Engineering
Stanford University
http://ai.stanford.edu/~tjhunter/
T. 404 421 3075

-------------------------------------------------------
diff -r 434246481ea3 Eigen/src/Core/Block.h
--- a/Eigen/src/Core/Block.h	Tue Jul 14 23:00:53 2009 +0200
+++ b/Eigen/src/Core/Block.h	Fri Jul 31 23:32:00 2009 -0700
@@ -145,6 +145,11 @@
 
     inline int rows() const { return m_blockRows.value(); }
     inline int cols() const { return m_blockCols.value(); }
+    
+    void resize(int r, int c)
+    {
+	ei_assert((rows()==r)&&(cols()==c)&&"You cannot resize a temporary");
+    }
 
     inline Scalar& coeffRef(int row, int col)
     {
@@ -270,6 +275,11 @@
     }
 
     inline int stride(void) const { return m_matrix.stride(); }
+    
+    void resize(int r, int c)
+    {
+	//FIXME: how to access the block shape?
+    }
 
   #ifndef __SUNPRO_CC
   // FIXME sunstudio is not friendly with the above friend...


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/