From: Aaron F. <fr...@us...> - 2014-11-20 22:56:19
|
Hi Scott, I am not an expert on the reference counting in blitz++, but I'm fairly certain the point of the reference counting in blitz++ is to alleviate any worry about leaving large chunks of data unclaimed and unusable. For the moment, let's assume that it works and you don't have to do anything special to decrement reference counts when moving a subarray. If that is the case, there is support for statements of the following form: blitz::Range I(0,9); blitz::Range J(0,9); blitz::Array<int, 2> original(200,100); blitz::Array<int, 2> cropped; cropped.reference(original(I+10, J+20)); So, if you could write a thin wrapper for the cropped array, the wrapper could then track the current offset and the maximum offset per dimension, given the size of the Range object. If you need to specify offsets that would push part of your subarray off the end of the original you will have to be more clever. Aaron On Thu, Nov 20, 2014 at 1:45 PM, Scott Houchin <sco...@ae...> wrote: > Hi all, > > I am looking to use Blitz++ for a project where using subarrays will be > essential. The one piece of functionality that appears to be missing is the > capability to slide a subarray. > > For example, consider a case where I allocate a 200x100 array, and then > generate a cropped subarray: > > Array<int,2> original(200,100); > Array<int, 2> cropped = original(Range(0, 9), Range(0, 4)); > > What I now want to do is to walk that cropped array across the original > array. > > cropped.shift(10, 8); > cropped.shift(-5, 3); > cropped.shiftTo(0, 5); > > The result of these functions is that the array cropped still looks like > an array of 10x5 elements, but is pointing to different portions of > original. > > I started looking at trying to add this, but what appears to be missing in > the actual Array class member variables is specific knowledge of the bounds > of the original array, which is making it difficult to perform the check > whether the adjustment I make to the data_ and zeroData_ members, is still > valid in light of the original valid index range for each rank of cropped; > did my shift walk off the end of one dimension? After a bit of work, I am > also not seeing any way to implement shiftTo; it's not clear that I even > have the original data_ pointer, or even a link to the original object > itself. > > The obvious workaround is that I can maintain a TinyVector that specifies > the offset of cropped into original up in my algorithm code, and then just > create a new cropped each time, ensuring that either cropped goes out of > scope (and thus the refcount gets decremented) or that I explicitly free it > and thus again decrement the refcount). However, I am concerned about > performance in this application and would prefer to not go through the > entire object construction and initial population of all of the member > variables in cropped. For this new shift function, it appears I can do > something like the slice(int rank, Range r) protected function for each > dimension, just adjusting the data pointer, if I'm willing to gamble that > my algorithm code can be sure to implement the limits such that I don't > walk off the array. > > Any ideas? > > Scott Houchin > Senior Engineering Specialist, The Aerospace Corporation > 15049 Conference Center Dr, CH3/310, Chantilly, VA 20151 > 571-307-3914, sco...@ae... > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > Blitz-support mailing list > Bli...@li... > https://lists.sourceforge.net/lists/listinfo/blitz-support > > |