search

BIDData / BIDMat

A CPU and GPU-accelerated matrix library for data mining
BSD 3-Clause "New" or "Revised" License
265 stars 73 forks source link

Sum with Offset #45

Closed kjameslubin closed 8 years ago

kjameslubin commented 9 years ago

I am implementing a sum method for TMat's as it appears frequently and seems useful. The plan is to iterate over tiles and to apply the sum individually on them, and then aggregate the result in a single vector, likely an FMat or GMat. I am tempted to allocate sum vectors of size matching the result vector for each of the constituent tiles, which is a waste of memory. To be memory efficient, this method could sum the (sum of the) tiles with the running result vector, in place. The problem is tracking the indices within the result vector - it is much easier to just sum vectors of a uniform size - and I'm not sure if the existing vector sum methods support smart sub-indexing. Thus I propose a sum with offset function - it would be quite similar to tileMult, in spirit.

kjameslubin commented 9 years ago

On second thought it may not be such a big deal as we can reuse a temporary vector for holding the intermediate tile sums. But an inplace solution would be ideal

jcanny commented 9 years ago

Well its easy for GMats which use wrapped pointers which can have an arbitrary offset. Its also pretty easy for CPU matrices which use vector helper functions which have offsets. But it still has to be written (hint).

kjameslubin commented 9 years ago

I rolled a part of it on the TMat branch, to support the sum function: [https://github.com/BIDData/BIDMat/blob/tmat/src/main/scala/BIDMat/TMat.scala#L357-L415]. I can definitely do it in general but might require a bit of guidance - perhaps let's pick this up on Friday. I am not sure of the level of generality - it seems that any of the reducing operations could be done with an offset, so it could be implemented that way, or more specifically. But more generality probably means more testing, and odd performance degradation when we haven't 'type-specialized' to the scala compiler's liking