[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: matrix sizes

From: Paul Kienzle
Subject: Re: matrix sizes
Date: Wed, 15 Sep 2004 20:53:54 -0400


I see from the malloc manpage that it accepts size_t type, which
presumably means the underlying system can allocate hunks
greater than 2Gb.

So then it is simply a matter of converting all array size and index
variables everywhere in liboctave and liboctinterp to use
octave_size_t, defined as octave_uint64 for your purposes.
Simple enough, but time consuming.

Next you will need to go through libcruft and make sure all the
supporting libraries can handle size_t for array sizes and
indices.  Others have done this in the past for atlas and fftw
which are the most important ones.

This should give you a working system with 53-bit indexing
which should last you a little bit longer.

Pushing it to full 64-bit indexing will require fiddling with the
range type and completing arithmetic ops on uint64.  I don't
know what the compatibility implications are of such a

- Paul

On Sep 15, 2004, at 8:31 PM, Darrick Edward Chang wrote:

Sorry for this follow-up, but in response to some emails I have already
gotten, perhaps I should clarify the conditions I am working under. I am
running octave 2.1.57 on a server with 20GB of RAM.  Thus I can use
the zeros command to create multiple matrices of size 16000 x 16000, for
example, with no problem.
Trying to create a single matrix of size 16384 x 16384, however, or a
complex matrix of size 16384 x 8192, is where octave spits out the error
messages that I noted in my previous message.

Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:
How to fund new projects:
Subscription information:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]