http://www.kevinbeason.com/smallpt/

Cute. Hard to read, but cute. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New wrote:
> http://www.kevinbeason.com/smallpt/
> 
> Cute. Hard to read, but cute. :-)

yes.  I wonder how it'd look like in Haskell. ;)

It was also the basis for SmallptGPU:

http://davibu.interfree.it/opencl/smallptgpu/smallptGPU.html

Post a reply to this message

nemesis wrote:
> It was also the basis for SmallptGPU:

Hey, I have an idea. Has anyone ever considered porting POV-Ray to the GPU? 
I bet it would be a lot faster.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New wrote:
> nemesis wrote:
>> It was also the basis for SmallptGPU:
> 
> Hey, I have an idea. Has anyone ever considered porting POV-Ray to the 
> GPU? I bet it would be a lot faster.
> 

Nice one! What a good idea. ;)

-- 

Best Regards,
	Stephen

Post a reply to this message

Stephen wrote:
> Darren New wrote:
>> nemesis wrote:
>>> It was also the basis for SmallptGPU:
>>
>> Hey, I have an idea. Has anyone ever considered porting POV-Ray to the
>> GPU? I bet it would be a lot faster.
>>
> 
> Nice one! What a good idea. ;)
> 

Hey, I bet it couldn't take more than a few minutes to move all the code
that direction. I mean, it can't be too much larger than 99 lines of code.

Post a reply to this message

Sabrina Kilian wrote:
> Stephen wrote:
>> Darren New wrote:
>>> nemesis wrote:
>>>> It was also the basis for SmallptGPU:
>>> Hey, I have an idea. Has anyone ever considered porting POV-Ray to the
>>> GPU? I bet it would be a lot faster.
>>>
>> Nice one! What a good idea. ;)
>>
> 
> Hey, I bet it couldn't take more than a few minutes to move all the code
> that direction. I mean, it can't be too much larger than 99 lines of code.

Not being a coder myself I will have to take your word on that. I’m sure 
Chris could do it standing on his head or at least upside down ;)

-- 

Best Regards,
	Stephen

Post a reply to this message

nemesis wrote:

> yes.  I wonder how it'd look like in Haskell. ;)

In any language, I suspect the answer will depend on:

- Which libraries are you allowed to use? [Get a ray tracing library and 
the program surely becomes trivial...]

- How fast does it have to be? [A highly-efficient program is likely to 
be a lot bigger than a program written specifically to demonstrate how 
terse you can be.]

Post a reply to this message

Darren New wrote:

> Cute. Hard to read, but cute. :-)

Wait... THE WALLS ARE GIANT SPHERES?! o_O

Well that's *one* way to cut down the code size... No ray/plane 
intersection test to code.

44:  double n=sizeof(spheres)/sizeof(Sphere);

Well... that's... one way to figure out how big an array is. :-.

Evidently my C++ is weak, but... how is

53:  Vec nl=n.dot(r.d)<0?n:n*-1;

different from "nl = -abs(n.dot(r.d))"?

Also, where THE HELL is "Xi" defined? I can see it *used* in several 
places, but I can't find a definitions.

Line 79 means each row of pixels is computed in parallel, right?

Post a reply to this message

> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
> 
> different from "nl = -abs(n.dot(r.d))"?

a?b:c evaluates to b if a is true, or c otherwise.

> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
> places, but I can't find a definitions.

Line 82, after the x=0 definition.

> Line 79 means each row of pixels is computed in parallel, right?

I guess so.

Post a reply to this message

>> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
>>
>> different from "nl = -abs(n.dot(r.d))"?
> 
> a?b:c evaluates to b if a is true, or c otherwise.

Ah, wait, I misread that as calculating something, assigning it to n, 
and then checking whether n is negative and if not negating it. On 
closer inspection, that's not what this does...

>> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
>> places, but I can't find a definitions.
> 
> Line 82, after the x=0 definition.

Wait - you can define MORE THAN ONE variable in a loop initialisation??

Post a reply to this message

> Wait - you can define MORE THAN ONE variable in a loop initialisation??

Don't see why not, would be a pointless limitation to put in on purpose that 
just reduced the flexibility, should anyone want it.

Post a reply to this message

Invisible wrote:

> Evidently my C++ is weak

Anybody got any theories on line 55?

   if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p);} else return obj.e;

   if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}

I can't decide which "if" the "else" belongs to. o_O

(I also have approximately no idea whatsoever what f=f*(1/p) is in aid 
of...)

Post a reply to this message

Invisible wrote:
> I can't decide which "if" the "else" belongs to. o_O

The else always belongs to the closest if at the same scope level... 
Which means it's:
if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}

I think it's part of the Russian Roulette method (which is what the 
comment R.R. stands for I suppose). I don't remember the details but you 
can probably look it up by yourself...

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:

> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}

Ouch. This isn't going to be pretty...

> I think it's part of the Russian Roulette method (which is what the 
> comment R.R. stands for I suppose). I don't remember the details but you 
> can probably look it up by yourself...

Clearly it flips a coin to decide whether to process further [all of the 
code paths beyond this point involve sending out a new ray] or just stop 
here. However, "f" is the object colour, and I have absolutely no idea 
why it's being scaled by the reciprocol of the brightest component...

Post a reply to this message

scott wrote:
>> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
>>
>> different from "nl = -abs(n.dot(r.d))"?
> 
> a?b:c evaluates to b if a is true, or c otherwise.

LPC might be a little different, but can't you negate a variable by 
saying a=-a;?  Saves a little CPU cost.

--
Tim Cook
http://empyrean.freesitespace.net

Post a reply to this message

> LPC might be a little different, but can't you negate a variable by saying 
> a=-a;?  Saves a little CPU cost.

I think he would have to define the unary minus operator for the vector 
class before he could write -n instead of n*-1.

Post a reply to this message

Invisible wrote:
> Vincent Le Chevalier wrote:
> 
>> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
> 
> Ouch. This isn't going to be pretty...

What do you mean?

> Clearly it flips a coin to decide whether to process further [all of the 
> code paths beyond this point involve sending out a new ray] or just stop 
> here. However, "f" is the object colour, and I have absolutely no idea 
> why it's being scaled by the reciprocol of the brightest component...

I think that it's the part that makes the method unbiased. You have to 
scale the rays that you keep in order to account for the fact that you 
don't keep them all, or something like that.

-- 
Vincent

Post a reply to this message

>>> if (++depth>5) {if (erand48(Xi)<p) f=f*(1/p); else return obj.e;}
>>
>> Ouch. This isn't going to be pretty...
> 
> What do you mean?

I mean implementing this in a language where the else-part is 
*mandatory* for all if-blocks makes this slightly tricky to do. (But not 
as tricky as I thought; I've found a clean way to do it.)

>> However, "f" is the object colour, and I have 
>> absolutely no idea why it's being scaled by the reciprocol of the 
>> brightest component...
> 
> I think that it's the part that makes the method unbiased. You have to 
> scale the rays that you keep in order to account for the fact that you 
> don't keep them all, or something like that.

Well, we'll see I guess...

Post a reply to this message

Invisible escreveu:
> nemesis wrote:
> 
>> yes.  I wonder how it'd look like in Haskell. ;)
> 
> In any language, I suspect the answer will depend on:
> 
> - Which libraries are you allowed to use? [Get a ray tracing library and 
> the program surely becomes trivial...]
> 
> - How fast does it have to be? [A highly-efficient program is likely to 
> be a lot bigger than a program written specifically to demonstrate how 
> terse you can be.]

That's what I'm willing to know.  That piece of code is not using a 
"raytracing library", just implementing algorithms from well-known papers.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:

> yes.  I wonder how it'd look like in Haskell. ;)

I had a go at implementing this, but I have clearly screwed up the math 
somewhere, because the program is behaving very strangely.

(I've turned off all the fancy stuff until it's just a normal depth-1 
ray tracer, and the image still just consists of a few bent lines.)

So far I've found at least a dozen bugs in the ray/intersection code, a 
typo in the cross-product (typed an X instead of a Z), and I'm still 
finding more. What can I say? I fail at math! o_O

Post a reply to this message

Invisible escreveu:
> nemesis wrote:
> 
>> yes.  I wonder how it'd look like in Haskell. ;)
> 
> I had a go at implementing this, but I have clearly screwed up the math 
> somewhere, because the program is behaving very strangely.
> 
> (I've turned off all the fancy stuff until it's just a normal depth-1 
> ray tracer, and the image still just consists of a few bent lines.)
> 
> So far I've found at least a dozen bugs in the ray/intersection code, a 
> typo in the cross-product (typed an X instead of a Z), and I'm still 
> finding more. What can I say? I fail at math! o_O

perhaps you just fail at translating crazy C++ code, which is perfectly 
fine.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> perhaps you just fail at translating crazy C++ code, which is perfectly 
> fine.

I don't find it really crazy, actually I was expecting far worse before 
opening the file...

It uses some tricks to achieve compactness but it's still mostly 
legible. I've seen far worse as far as variables names are concerned, 
for instance :-\

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier wrote:
> I don't find it really crazy, actually I was expecting far worse before 
> opening the file...

Me too, honestly.  You can see what it's doing, and you could probably 
translate it by hand into some other OO imperative language without even 
knowing what it's trying to do.  It's not obfuscated as much as terse.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Invisible wrote:
> 44:  double n=sizeof(spheres)/sizeof(Sphere);
> 
> Well... that's... one way to figure out how big an array is. :-.

That's the usual way to figure out how big an array is in C and C++.

> Evidently my C++ is weak, but... how is
> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
> different from "nl = -abs(n.dot(r.d))"?

In the lack of needing to define the abs() function?

> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
> places, but I can't find a definitions.

Line 48. It's an argument to the function. Note that text search will 
usually answer that sort of question on a C program, and often on a C++ 
program too.

Not always, mind, but usually.


> Line 79 means each row of pixels is computed in parallel, right?

Got me. It looks like someone is asking the compiler to do that if it can.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> Line 79 means each row of pixels is computed in parallel, right?
> 
> Got me. It looks like someone is asking the compiler to do that if it can.

http://en.wikipedia.org/wiki/Openmp#Work-sharing_constructs

Post a reply to this message

Darren New wrote:
>> Line 79 means each row of pixels is computed in parallel, right?
> 
> Got me. It looks like someone is asking the compiler to do that if it can.
> 

It's using the OpenMP directives 
(http://en.wikipedia.org/wiki/OpenMP)... I discovered that last year, 
can be pretty useful and makes it quite easy to take advantage of 
multiple cores when the algorithms are already mostly suited to being 
run in parallel.

-- 
Vincent

Post a reply to this message

>> I don't find it really crazy, actually I was expecting far worse 
>> before opening the file...
> 
> Me too, honestly.  You can see what it's doing, and you could probably 
> translate it by hand into some other OO imperative language without even 
> knowing what it's trying to do.  It's not obfuscated as much as terse.

It's just shoved together into a very small space, so it's a big awkward 
to read.

What I've probably done is got a plus sign instead of a minus somewhere, 
or something equally trivial, which has none the less completely screwed 
up the math. And damn, it's going to take a while to find it! :-/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> 44:  double n=sizeof(spheres)/sizeof(Sphere);
>>
>> Well... that's... one way to figure out how big an array is. :-.
> 
> That's the usual way to figure out how big an array is in C and C++.

It is surprising to me that this actually works. I was under the 
impression that C does not actually distinguish between pointers and 
arrays (and integers and booleans and...)

>> Evidently my C++ is weak, but... how is
>> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
>> different from "nl = -abs(n.dot(r.d))"?
> 
> In the lack of needing to define the abs() function?

No, I misread the code. It's actually deciding whether to negate n based 
on a function of n, not n itself.

>> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
>> places, but I can't find a definitions.
> 
> Line 48. It's an argument to the function.

No, it's an argument in the radiance() function, I meant where is it 
defined in main().

> Note that text search will 
> usually answer that sort of question on a C program, and often on a C++ 
> program too.
> 
> Not always, mind, but usually.

Yeah, I tried that too...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Tim Cook <z99### [at] gmailcom> wrote:
> scott wrote:
> >> 53:  Vec nl=n.dot(r.d)<0?n:n*-1;
> >>
> >> different from "nl = -abs(n.dot(r.d))"?
> > 
> > a?b:c evaluates to b if a is true, or c otherwise.

> LPC might be a little different, but can't you negate a variable by 
> saying a=-a;?  Saves a little CPU cost.

  Yes, but since 'nl' is of type struct Vec, he would have to define
operator-() for it for that to work. Maybe he wanted to save one line
of code.

-- 
                                                          - Warp

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> Darren New wrote:
> >> Line 79 means each row of pixels is computed in parallel, right?
> > 
> > Got me. It looks like someone is asking the compiler to do that if it can.
> > 

> It's using the OpenMP directives 
> (http://en.wikipedia.org/wiki/OpenMP)... I discovered that last year, 
> can be pretty useful and makes it quite easy to take advantage of 
> multiple cores when the algorithms are already mostly suited to being 
> run in parallel.

  The advantage of OpenMP is that the routine will run in parallel if
the compiler supports it, but if the compiler doesn't support OpenMP,
it doesn't matter: The program will still compile and work properly
(it will just be single-threaded). Compilers ignore #pragmas they don't
recognize (per the standard), so the addition #pragma openmp's don't
matter.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://www.kevinbeason.com/smallpt/

  A small pitty that it's not 100% standard C++, as erand48() is not part of
the standard (it's a glibc extension). OTOH, better use erand48() than rand(),
as the latter is just plain horrible in quality.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> 44:  double n=sizeof(spheres)/sizeof(Sphere);
> >>
> >> Well... that's... one way to figure out how big an array is. :-.
> > 
> > That's the usual way to figure out how big an array is in C and C++.

> It is surprising to me that this actually works. I was under the 
> impression that C does not actually distinguish between pointers and 
> arrays (and integers and booleans and...)

  There is a big difference between a pointer and an array in C (and hence
in C++).

  Basically each array is a type of its own, defined by the element type
and the number of elements. What makes an array distinctly a type of its
own is that sizeof() always returns the number of bytes that a type
requires when allocated in memory, and an array is no different: sizeof()
for an array returns the amount of bytes taken by the entire array. This
is drastically different from a sizeof() of a pointer, which will always
return 4 or 8 (depending on whether you are compiling a 32-bit or 64-bit
program).

  Since sizeof() of an array returns the total amount of bytes taken by
an array, if you divide it by the amount of bytes of one element, you get
the total number of elements.

  For example if in C++ you instantiate a template using an array as a
template parameter, a distinct instanstiation will be made for each specified
type and size of array.

  Of course what makes this confusing is that an array implicitly casts to
a pointer of the element type. In other words, wherever a pointer of the
element type is required, you can give an array of that type instead (there
will be an implicity cast to the pointer type).

  Also the syntax of indexing an array and indexing memory using a pointer
is identical, adding to the confusion.

  It can sometimes be difficult to distinguish between an array and a
const pointer (a pointer which cannot be changed to point somewhere else).
sizeof() is one thing which makes the distinction.

> >> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
> >> places, but I can't find a definitions.
> > 
> > Line 48. It's an argument to the function.

> No, it's an argument in the radiance() function, I meant where is it 
> defined in main().

  Line 82.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   There is a big difference between a pointer and an array in C (and hence
> in C++).

Really?

>   Since sizeof() of an array returns the total amount of bytes taken by
> an array, if you divide it by the amount of bytes of one element, you get
> the total number of elements.

This is plain. What surprises me is that sizeof() can give you an 
accurate size in the first place.

>   Of course what makes this confusing is that an array implicitly casts to
> a pointer of the element type. In other words, wherever a pointer of the
> element type is required, you can give an array of that type instead (there
> will be an implicity cast to the pointer type).

Ah. I didn't know that. All the books I've seen claim that they are *the 
same type*.

This makes more sense now...

>>>> Also, where THE HELL is "Xi" defined? I can see it *used* in several 
>>>> places, but I can't find a definitions.
>>> Line 48. It's an argument to the function.
> 
>> No, it's an argument in the radiance() function, I meant where is it 
>> defined in main().
> 
>   Line 82.

Yes, we've established that now. I wasn't aware that you could actually 
define more than one variable in a loop initialiser...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >   Since sizeof() of an array returns the total amount of bytes taken by
> > an array, if you divide it by the amount of bytes of one element, you get
> > the total number of elements.

> This is plain. What surprises me is that sizeof() can give you an 
> accurate size in the first place.

  Why wouldn't it? The compiler has to know the size of the array if it
wants to allocate it in memory.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Also the syntax of indexing an array and indexing memory using a pointer
> is identical, adding to the confusion.

Plus, you can't pass an array to a function, at least in C.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

>>>   Since sizeof() of an array returns the total amount of bytes taken by
>>> an array, if you divide it by the amount of bytes of one element, you get
>>> the total number of elements.
> 
>> This is plain. What surprises me is that sizeof() can give you an 
>> accurate size in the first place.
> 
>   Why wouldn't it? The compiler has to know the size of the array if it
> wants to allocate it in memory.

All that stuff about "C does not know the size of an array at run-time, 
and does not check array bounds". But then, this is from the same books 
that claim that pointers *are* arrays... Certainly if you asked for 
sizeof() on a pointer, you wouldn't get the size of the array it points to.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >>>   Since sizeof() of an array returns the total amount of bytes taken by
> >>> an array, if you divide it by the amount of bytes of one element, you get
> >>> the total number of elements.
> > 
> >> This is plain. What surprises me is that sizeof() can give you an 
> >> accurate size in the first place.
> > 
> >   Why wouldn't it? The compiler has to know the size of the array if it
> > wants to allocate it in memory.

> All that stuff about "C does not know the size of an array at run-time, 
> and does not check array bounds".

  That talks about dynamically allocated arrays, not statically allocated
ones. They are different.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Also the syntax of indexing an array and indexing memory using a pointer
> > is identical, adding to the confusion.

> Plus, you can't pass an array to a function, at least in C.

  Not directly, but you can do it indirectly if you enclose the array inside
a struct (in that case the array (inside the struct) is truly passed by
value rather than by-pointer).

-- 
                                                          - Warp

Post a reply to this message

>> Plus, you can't pass an array to a function, at least in C.
> 
>   Not directly, but you can do it indirectly if you enclose the array inside
> a struct (in that case the array (inside the struct) is truly passed by
> value rather than by-pointer).

...you really have been doing this for a long time, haven't you?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> Plus, you can't pass an array to a function, at least in C.
> > 
> >   Not directly, but you can do it indirectly if you enclose the array inside
> > a struct (in that case the array (inside the struct) is truly passed by
> > value rather than by-pointer).

> ...you really have been doing this for a long time, haven't you?

  Well, it's rather basic C.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>>>>>   Since sizeof() of an array returns the total amount of bytes taken by
>>>>> an array, if you divide it by the amount of bytes of one element, you get
>>>>> the total number of elements.
>>>> This is plain. What surprises me is that sizeof() can give you an 
>>>> accurate size in the first place.
>>>   Why wouldn't it? The compiler has to know the size of the array if it
>>> wants to allocate it in memory.
> 
>> All that stuff about "C does not know the size of an array at run-time, 
>> and does not check array bounds".
> 
>   That talks about dynamically allocated arrays, not statically allocated
> ones. They are different.

He's right, tho. C doesn't know the size of an array at run time. sizeof() 
is a compile-time operator.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>   Also the syntax of indexing an array and indexing memory using a pointer
>>> is identical, adding to the confusion.
> 
>> Plus, you can't pass an array to a function, at least in C.
> 
>   Not directly, but you can do it indirectly if you enclose the array inside
> a struct (in that case the array (inside the struct) is truly passed by
> value rather than by-pointer).

And in the original versions of C, you couldn't pass a struct by value 
either. :-)

But yah, that's a good point I hadn't considered.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> He's right, tho. C doesn't know the size of an array at run time. sizeof() 
> is a compile-time operator.

  If it knows it at compile time, it knows it at runtime. It's not like
it forgets somewhere in between... :P

-- 
                                                          - Warp

Post a reply to this message

Out of curiosity I changed the location of the light to see that it really
renders it properly:

http://warp.povusers.org/images/smallpt.jpg

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> He's right, tho. C doesn't know the size of an array at run time. sizeof() 
>> is a compile-time operator.
> 
>   If it knows it at compile time, it knows it at runtime. It's not like
> it forgets somewhere in between... :P

Well, no, I disagree. How do you find the size of an array at runtime? 
That's exactly why you have to pass it around along with the pointer.

OK, I'll grant you that the generated code has that available, in the sense 
that the loader avoids overwriting that space with other stuff, but it's not 
available to the C-level program in any way at runtime.

You can take sizeof(x) at compile time, and store that somewhere that 
runtime can find it, but there's nothing like Ada's myvariable'size 
expression that would tell you at runtime what the size is for an arbitrary 
array. There's no way to apply sizeof() to a non-array-name and find out the 
size of an array (i.e., no way to say "what's the size of the array this 
pointer points to").

Hmmm... If you put an array in a struct, can you ask 
"sizeof(myrecord.thearray)" and get an appropriate size? I suppose you 
could, but still I wouldn't count that as such.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Well, no, I disagree. How do you find the size of an array at runtime? 

  It's a constant integral value, hence known at runtime.

> That's exactly why you have to pass it around along with the pointer.

  Now you are confusing dynamically allocated arrays with static arrays.
They are not the same thing.

  The size of dynamically allocated arrays cannot be resolved either at
runtime nor at compile time (eg. you cannot use the size of a dynamically
allocated array somewhere where a compile-time constant is expected).

> Hmmm... If you put an array in a struct, can you ask 
> "sizeof(myrecord.thearray)" and get an appropriate size?

  Yes, actually.

> I suppose you 
> could, but still I wouldn't count that as such.

  "As such"? What? Runtime? sizeof() always works at compile time.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
>   Out of curiosity I changed the location of the light to see that it really
> renders it properly:
> 
> http://warp.povusers.org/images/smallpt.jpg

did you make it coincident with the surface?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> >   Out of curiosity I changed the location of the light to see that it really
> > renders it properly:
> > 
> > http://warp.povusers.org/images/smallpt.jpg

> did you make it coincident with the surface?

  I have hard time deciding whether that was humorous or a serious question.

-- 
                                                          - Warp

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> Warp escreveu:
>>>   Out of curiosity I changed the location of the light to see that it really
>>> renders it properly:
>>>
>>> http://warp.povusers.org/images/smallpt.jpg
> 
>> did you make it coincident with the surface?
> 
>   I have hard time deciding whether that was humorous or a serious question.

serious.  Did you put right where the left sphere surface would hit?

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Warp escreveu:
> > nemesis <nam### [at] gmailcom> wrote:
> >> Warp escreveu:
> >>>   Out of curiosity I changed the location of the light to see that it really
> >>> renders it properly:
> >>>
> >>> http://warp.povusers.org/images/smallpt.jpg
> > 
> >> did you make it coincident with the surface?
> > 
> >   I have hard time deciding whether that was humorous or a serious question.

> serious.  Did you put right where the left sphere surface would hit?

  Unbiased monte-carlo rendering sends rays in a random fashion. It starts
extremely grainy, but the graininess gets reduced over time as the number
of samples gets increased. That image is the result of 30 minutes of
rendering in my computer (a virtually grainless result would have taken
days).

-- 
                                                          - Warp

Post a reply to this message