On Thu, Dec 13, 2012 at 11:42 AM, Konrad Hinsen
<[email protected]> wrote:
> --On 13 décembre 2012 10:45:42 -0500 Raul Miller <[email protected]>
> wrote:
>> Copying is an easy operation, and if you are doing any significant
>> work the cost of a copy is often trivial when compared with everything
>> else you are doing.
>
> Except for arrays that take up half of my machine's RAM.
Even then your dominant cost is reading the data off of disk. If the
data is converted on the way in from the disk to RAM, and most of your
CPU time is spent waiting for the disk, your conversion time might not
even be measurable.
>> The result of 3!:1 is very close to the internal representation. That
>> said, if you look in jtype.j in the j source, you'll see this:
>>
>> :typedef struct {I k,flag,m,t,c,n,r,s[1];}* A;
>>
>> along other supporting declarations (note especially the section
>> marked "Fields of type A") -- that's the internal representation of
>> J's arrays.
>
> OK, that looks quite close in spirit (though not in layout) to NumPy arrays.
> It should be possible to wrap a J array in a Python buffer object and create
> a NumPy array on top of that. Then we would have a J array and a NumPy array
> with shared data space, readable and writable (with care!) from both sides.
>
> That leaves the question of how to make Python and J live in the same
> address space. I am sure it can be done, but I suspect it's not trivial.
> Python embedded into the J interpreter is one option, but if the inverse is
> doable, it's probably easier.
Note that if your data structure occupies half of your physical
memory, J intermediate results might be expensive -- my rule of thumb
(just a guess based on raw data size, until I get real measurements)
is to expect 5x memory overhead from J.
That said, have you seen the pages linked from
http://www.jsoftware.com/help/user/dlls.htm?
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
