POV-Ray : Newsgroups : povray.programming : array question Server Time
22 Dec 2024 22:00:41 EST (-0500)
  array question (Message 1 to 7 of 7)  
From: Ricky Reusser
Subject: array question
Date: 19 Sep 2003 15:47:54
Message: <3f6b5d6a@news.povray.org>
Hi,
        I've been away for a while but now I'm trying to get back into it and am
trying to do some pov-relevant programmingin C.  Well, C++ I guess, but
without all of the fancy complex stuff.  I'm basically writing code pov-ray
style, just with output for each frame of an animation since it's a lot
quicker.  
        So here's the question.  How do I create a large array without getting a
signal 11 (sigsegv) error?  It makes sense that there are size limitations
on arrays, but if I wanted to create a 100x100x100 array of floats, how
would I do that?  I seem to remember something like an array of 100
pointers to 100x100 arrays, but I don't remember it well enough to
duplicate it.

Thanks in advance,
Ricky


Post a reply to this message

From: Warp
Subject: Re: array question
Date: 20 Sep 2003 06:42:58
Message: <3f6c2f32@news.povray.org>
Ricky Reusser <ple### [at] emailcom> wrote:
>         So here's the question.  How do I create a large array without getting a
> signal 11 (sigsegv) error?  It makes sense that there are size limitations
> on arrays, but if I wanted to create a 100x100x100 array of floats, how
> would I do that?  I seem to remember something like an array of 100
> pointers to 100x100 arrays, but I don't remember it well enough to
> duplicate it.

  You failed to provide vital information about your system:

  - Your computer type (PC? Mac? Sparc? Another?) and OS.
  - The compiler you are using.
  - A short piece of code you are trying but is causing the problem.


  100*100*100*4 is only 3.8 megabytes so it shouldn't be any problem in
any current OS with any current compiler. Your code is probably just buggy.

  Btw, there's no need to use an array of pointers to arrays of pointers
to arrays. That will only consume lots of memory for no useful purpose
and will be extremely error-prone with regard to memory
allocation/deallocation (unless you do it in an object-oriented way,
but as you said that you are not really coding in C++...).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -


Post a reply to this message

From: Ricky Reusser
Subject: Re: array question
Date: 20 Sep 2003 10:20:02
Message: <3f6c6211@news.povray.org>
Warp wrote:
>   You failed to provide vital information about your system:
> 
>   - Your computer type (PC? Mac? Sparc? Another?) and OS.
>   - The compiler you are using.
>   - A short piece of code you are trying but is causing the problem.
> 
> 
>   100*100*100*4 is only 3.8 megabytes so it shouldn't be any problem in
> any current OS with any current compiler. Your code is probably just
> buggy.

Sorry.  I should have known I should provide info by now.  I just assumed
this might be a standard C thing.  I'm using mac os x on a G4 with the most
current version of their Project Developer.  (It did the same thing back on
the old G3)  The only code I'm using is:

float u_x[ncx+1][ncy][ncz];

All of the variables are correctly defined as int's and it does the same
thing if I type float u[100][100][100]; or with other data types.  It works
just fine with smaller numbers, but once I get to somewhere in the area of
30-40 ^3, I just get an error.  I thought there might be a limit on how
much memory you can allocate at once, but then this would seem to be a more
common issue.  My searches online have turned up nothing, so I'm probably
missing something.

Thanks.

 - Ricky


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: array question
Date: 20 Sep 2003 10:52:16
Message: <3f6c69a0$1@news.povray.org>
In article <3f6c6211@news.povray.org> , Ricky Reusser 
<ple### [at] emailcom>  wrote:

> float u_x[ncx+1][ncy][ncz];

I bet you do this on the stack, right?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Warp
Subject: Re: array question
Date: 20 Sep 2003 13:59:07
Message: <3f6c956b@news.povray.org>
Ricky Reusser <ple### [at] emailcom> wrote:
> All of the variables are correctly defined as int's and it does the same
> thing if I type float u[100][100][100];

  Actually according to the standard the dimensions of an array must be
compile-time constants (even though some compilers support allocating
such arrays at runtime), but I believe this is besides the point in this
case.

> or with other data types.  It works
> just fine with smaller numbers, but once I get to somewhere in the area of
> 30-40 ^3, I just get an error.  I thought there might be a limit on how
> much memory you can allocate at once

  This depends a lot on the compiler (and sometimes the OS) you are using.
There's nothing in the C standard which would limit the size of an array.

  In some systems compilers allocate a fixed amount of space for certain
things (such as the stack). I wonder if the compiler you are using has
some odd type of limit for statically allocated arrays.

  This simple code worked ok for me (gcc 3.3.1 in a Sparc Solaris system).
Does it cause a segmentation fault for you?

-------8<------------8<-----------8<-------------8<-----------8<--------
#include <iostream>

int main()
{   
    float u[100][100][100];
    u[50][60][70] = 5;
    std::cout << u[50][60][70] << std::endl;
}
-------8<------------8<-----------8<-------------8<-----------8<--------

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: array question
Date: 20 Sep 2003 14:49:49
Message: <3f6ca14d$1@news.povray.org>
In article <3f6c956b@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   In some systems compilers allocate a fixed amount of space for certain
> things (such as the stack).

Or the OS properly limits the stack size of applications by default ...
which is the case on Mac OS X, whose Mach-O kernel will limit an application
stack size to 512 KB unless it has been otherwise specified when building
the application (the stack itself only grows a (4 KB) page at a time, of
course).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Ricky Reusser
Subject: Re: array question
Date: 20 Sep 2003 16:26:22
Message: <3f6cb7ee@news.povray.org>
Thorsten Froehlich wrote:
>>   In some systems compilers allocate a fixed amount of space for certain
>> things (such as the stack).
> 
> Or the OS properly limits the stack size of applications by default ...
> which is the case on Mac OS X, whose Mach-O kernel will limit an
> application stack size to 512 KB unless it has been otherwise specified
> when building the application (the stack itself only grows a (4 KB) page
> at a time, of course).

Thanks!  (To Warp also.)  This led me to a workaround, but not really a full
solution.  Apple's Project Builder is a pretty nice program and works fine,
but isn't really made for simple c programming.  I did get gcc to work
though and just typing "limit stacksize unlimited" into my .cshrc solves
the problem.  I can still use Project Builder to type a nice-looking
formatted and syntax-colored file, but I'll just have to use gcc to compile
instead.  Took me a while to do the research and figure this out.  I guess
there just isn't room for programming newbies...  Thanks though.  I've
worked out the details of the rest of the program, but the most basic part
has been holding me up for a while.  And for Warp, straight out of the
Konsole:

5

Thanks again!
- Ricky


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.