Chief:
Local variables (and parameters passed by value) go on the stack, which is typically very small. You can increase it in some unix systems. Everything else (AFAIK) goes on the heap - which, put simply (As far as I understand) is as big as all the memory available to the program (installed RAM + virtual memory on the system).
Ok, I thought it might be on the heap but I had understood the heap contained pointer structures.
Yes, the heap does - but you did not declare a pointer.
Ok, got it.
I get segmentation faults when I run with the numbers too big (trimax=2003001). I'm somewhat puzzled by this since I have 26G free Physical memory ... I calculate that for that size it should only take 32048096 = 32,048,096 = 32M integers. What's happening?
[...]
So my structure is still only 128Mb. I have a lot more free than that!
Are you still using a local variable, or a global variable? If you are using a global variable, there should be no problem at all. If you are still using a local variable, it would still overflow the stack. It is unusual to have stack space that is bigger than a few kilobytes, so 128mb is still far too big. To check the size of your stack (assuming it supports plain unix commands), run "ulimit -a" at a command prompt.
I am currently using a global variable and passing by var. with trimax at 501502 it compiles and runs.
When I set it to 2003001 it compiles but gives a segmention fault even though it's global. Maybe there's a limitation to allocating that way?
Then I switched dataprism to be a pointer using 'dataprism: ^trisquare;' as you suggested and changed the calls to be 'dataprism^' (a rather cute trick!) and ... it compiles but still gives me a segmentation fault!
Tom
Thomas D. Schneider, Ph.D. Senior Investigator National Institutes of Health National Cancer Institute Frederick National Laboratory for Cancer Research Gene Regulation and Chromosome Biology Laboratory Molecular Information Theory Group Frederick, Maryland 21702-1201 schneidt@mail.nih.gov http://alum.mit.edu/www/toms