Re: [eigen] Malloc-free dynamic matrices |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Malloc-free dynamic matrices*From*: leon zadorin <leonleon77@xxxxxxxxx>*Date*: Thu, 4 Mar 2010 13:58:36 +1100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2/qZJI4agQQRQBMHf36DDjBsO9QONttHJph44r7DYz4=; b=qUsEU0uQ0qFRsr2Aw/NWSzrdQvq9EUiV5bq6ZpRl2Gx3DSGWS0SVNyjzYjkP2AUkab g6ODaIzu44gHp3NsNMtxPxJ3NkaktlG+y6iYTa6h7BFfFd0NmM5PwoHHfyd688C33So2 vPUSYTIlYf37eclLGQ0qoFpVzwQ+Ajk3U+vYE=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=I/hxPoS1lhdJC16RjRWwdEpAHSojpVSVUDOYPBGfBcY72/F9z6UTnZTDRRO//7Eiop CvuI+5LZl58gLqJ1BGarxdlVeHLYRF3nD/pqI5/Pe7lElEJ439jKLJIiQIjLBQSf+NXY lNKYbLpTDawXi8Fcf6oaPXT24wFSzXCEnf/sw=

On 3/4/10, Márton Danóczy <marton78@xxxxxxxxx> wrote: > On 3 March 2010 15:44, leon zadorin <leonleon77@xxxxxxxxx> wrote: >> double * reserved(aligned_alloc(8192)); >> >> // 3x3 >> Map<double> m(reserved, 3, 3); >> >> // 10x10 -- resize w/o reallocation -- equivalent to NeverRealloc w/o >> much repatching(?) >> m.remap(reserved, 10, 10); > [...] > Matrix<float, Dynamic, Dynamic, NoRealloc> A, B, C; > > A.reserve(16); A.resize(4,4); > B.reserve(25); B.resize(5,5); > C.reserve(81); C.resize(9,9); > > B=A; //this should work and resize B to 4x4 > B=C; //this should raise an assertion failure > > To achieve this behaviour, we do need a dedicated class -- or an > option, such as in the patch. Sure... but not quite -- if we are talking about adding extra "sanity-checking" in the debug builds of an app, and if current API has no such assertions, then some form of changes would be needed. But in such a case, still -- I don't think Benoit was arguing against any changes -- only in favor of smaller/more-elegant ones... Map<> obj. ctor could indeed have an additional arg denoting the max size of the (re)mappable mem (on which it is mapping)... or indeed, as others have alluded to, one could pass an 'array object' instead of just 'float/double *' (given that what you are really trying to 'sanity-check' is the boundary -- and such is not meant to auto-reallocate but to assert -- implying that this should not be happening 'by design') -- so a logical conclusion would be for Map<> to be able to map from a vector/array type (e.g. ::boost::array semantics), then: array a1(25); array a2(81); Map m1(a1, 5, 5); Map m2(a2, 9, 9); m1 = m2; // assertion due to boundary-checking of 'intelligent' arrays... or if constructing/mapping explicitly from "double/float *" double *a1(alloc(25)); Map m1(a1, 5, 5, 25); // i.e. additional arg denoting max mappable mem. double *a2(alloc(81)); Map m2(a2, 9, 9, 81); m1 = m2; // the same assertion... (ifndef NDEBUG of course) In fact, given that you are only requiring an assertion (not exception throwing), then the actual presence of the above fields (e.g. in the Map class, the 'bounds-keeping' variable could, itself, exist only #ifndef NDEBUG size_t max_mappable_size; #endif Alternatively, as you mentioned -- another class may be used... but, if such is to be the case, then what I was trying to say was that this class feels like being more of a facade design-pattern, not a patch to the existing class: struct blah { double * data; Map m; blah() : data(allocate), m(data, x, y) { } etc. etc. -- like op= with checking for memory-bounds violations... }; .... but only if one wants it... from your code-example it looks to me like it really should be subject to an "array" object... or a Map object... as memory-bounds checking is really a question of abstracting the c-style 'arrays' in the first place... ideally... kind regards Leon.

**Follow-Ups**:**Re: [eigen] Malloc-free dynamic matrices***From:*Gael Guennebaud

**References**:**[eigen] Malloc-free dynamic matrices***From:*Márton Danóczy

**Re: [eigen] Malloc-free dynamic matrices***From:*Benoit Jacob

**Re: [eigen] Malloc-free dynamic matrices***From:*leon zadorin

**Re: [eigen] Malloc-free dynamic matrices***From:*leon zadorin

**Re: [eigen] Malloc-free dynamic matrices***From:*Benoit Jacob

**Re: [eigen] Malloc-free dynamic matrices***From:*Gael Guennebaud

**Re: [eigen] Malloc-free dynamic matrices***From:*leon zadorin

**Re: [eigen] Malloc-free dynamic matrices***From:*Márton Danóczy

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Google Summer of Code** - Next by Date:
**Re: [eigen] Google Summer of Code** - Previous by thread:
**Re: [eigen] Malloc-free dynamic matrices** - Next by thread:
**Re: [eigen] Malloc-free dynamic matrices**

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