Heya -- two questions have reared their ugly heads as I mess around with
MegaPOV.  Firstly, there seems to be some portability problems with
respect to isosurfaces -- namely division by zero.  Rendering the
following scene produces two completely different results under Linux
and Windows.  Under the former, the result is pure black.  The latter
spits out a while circle...

#version unofficial MegaPov 0.5;
isosurface{
  function{1/0}
  contained_by {sphere{0,1}}
  threshold .5 pigment {rgb 1}
}
global_settings{ ambient_light 10}
camera {location <2,0,0> look_at <0,0,0>}

I would hesitantly put forth that the all-black version is the "more
correct" version, as the isosurface evaluates to +infinity at every
point -- and +infinity is never equal to 0.5 (the threshold) so there
should be no "surface" at all.

The other, unrelated, quirk is that of nested macro definitions.  Why
does MegaPOV specifically complain about them, and refuse to parse
them?  Is there a workaround?  Because otherwise Chris Colefax's
wonderful spline macro file is useless in MegaPOV..
Thank ye for any enlightenment,
-Alex V.

Post a reply to this message

In article <397CEDA2.548E2CA1@tiac.net>, Alex Vandiver 
<van### [at] tiacnet> wrote:

> Heya -- two questions have reared their ugly heads as I mess around with
> MegaPOV.  Firstly, there seems to be some portability problems with
> respect to isosurfaces -- namely division by zero.  Rendering the
> following scene produces two completely different results under Linux
> and Windows.  Under the former, the result is pure black.  The latter
> spits out a while circle...
...snip...
> I would hesitantly put forth that the all-black version is the "more
> correct" version, as the isosurface evaluates to +infinity at every
> point -- and +infinity is never equal to 0.5 (the threshold) so there
> should be no "surface" at all.

It isn't a very serious problem(you shouldn't expect a surface there 
anyway), and to catch these cases might take too much overhead...I don't 
know the isosurface code very well though. It might be possible to weed 
out functions resulting in these values.
And are you sure about it evaluating to +infinity? I thought it was 
NaN...


> The other, unrelated, quirk is that of nested macro definitions.  Why
> does MegaPOV specifically complain about them, and refuse to parse
> them?  Is there a workaround?  Because otherwise Chris Colefax's
> wonderful spline macro file is useless in MegaPOV..

It could have something to do with the macro speed enhancements...
I thought nested definitions weren't allowed in the official version 
either, but I couldn't find any mention of this restriction in the 
documentation...
Does that spline include require nested macro definitions? I can't think 
of a good reason to use them...I have never used that include, but maybe 
I will download it and try to get it to work.
Couldn't you just use one of the spline patches included in MegaPOV? Or 
are there specific features in Colfax's spline macros which you need?

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Alex Vandiver <van### [at] tiacnet> wrote...
> Firstly, there seems to be some portability problems with
> respect to isosurfaces -- namely division by zero.  Rendering the
> following scene produces two completely different results under Linux
> and Windows.  Under the former, the result is pure black.  The latter
> spits out a while circle...

Yes.  I've known about this problem for a while now, but I don't know
exactly how to fix it (or even how it should be fixed exactly).

> The other, unrelated, quirk is that of nested macro definitions.  Why
> does MegaPOV specifically complain about them, and refuse to parse
> them?  Is there a workaround?  Because otherwise Chris Colefax's
> wonderful spline macro file is useless in MegaPOV..

Nested macro definitions are not necessary (and really should be avoided).
Programmers tend to think that nesting macro definitions is necessary (to
keep the "scope" of variables), but you need to remember that POV-Ray
scripting uses dynamic scoping rules, so that whether or not a variable
exists depends on when and where the code is RUN, not where it is DECLARED.
You can declare macros apart from each-other, and then just use them in a
nested way.

This...

#macro a()
  #macro b()
    // do stuff for macro b
  #end // macro b
  // do stuff for macro a
#end // macro a

...means the same thing as this...

#macro a()
  // do stuff for macro a
#end // macro a

#macro b()
  // do stuff for macro b
#end // macro b

...except that you can't do the first one in MegaPov.  You can simply
un-nest the nested macros and everything should work perfectly.

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> Nested macro definitions are not necessary (and really should be avoided).

Except where "dynamic" macros are used.  Take the following snippet:

#macro a(foo)
  #if (foo)
    #macro b()
      // do one thing
    #end // macro b, first possibility
  #else
    #macro b()
      // do something else
    #end // macro b, second possibility
  #end // if statement
#end // macro a

..which unfortunatly can't be unrolled in the way you describe.  The above
method has the useful effect, because of the dynamic scoping rules you mention,
of making macro b() defined after macro a() ends, and available to the rest of
the program -- but with differing effects based on the value of foo!  Things
like the spline include use this to dynamically declare what a "segment" of the
spline is made of, so that the later call which actually creates the spilne is
oblivious to the type of spline it is creating.
-Alex V.

Post a reply to this message

Chris Huff wrote:

> And are you sure about it evaluating to +infinity? I thought it was
> NaN...

No, I'm not at all sure. It's quite possible that it's NaN.

> It could have something to do with the macro speed enhancements...
> I thought nested definitions weren't allowed in the official version
> either, but I couldn't find any mention of this restriction in the
> documentation...

Nested definitions are apparently perfectly happy in the official version.

> Does that spline include require nested macro definitions? I can't think
> of a good reason to use them...

See my reply to Nathan in this thread, about "dynamic" macros.

> Couldn't you just use one of the spline patches included in MegaPOV? Or
> are there specific features in Colfax's spline macros which you need?

Partially.  the spline macros allow for such interesting beasts as blob
splines, as well as several very handy tweaking parameters.  However, if the
"no nested macros" rule is set in stone, it would probably be possible to
re-write it in terms of "keyword" splines.  Just wondering if there was any
great reason that I did not know of that was swaying the decision either way..

-Alex V.

Post a reply to this message

>It isn't a very serious problem(you shouldn't expect a surface there
>anyway), and to catch these cases might take too much overhead...I don't
>know the isosurface code very well though. It might be possible to weed
>out functions resulting in these values.
>And are you sure about it evaluating to +infinity? I thought it was
>NaN...
>
>

Depends. If you play with the mathematics it can be proved that
x/0 = infinity where x!= 0 and that 0/0 can equal any number.

Generally however division by zero is undefined.

Gail
********************************************************************
* gsh### [at] monotixcoza              * Reality.dat not found         *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2      *
********************************************************************

Post a reply to this message

In article <397D11B1.18DE50F5@tiac.net> , Alex Vandiver <van### [at] tiacnet>
wrote:

> #macro a(foo)
>   #if (foo)
>     #macro b()
>       // do one thing
>     #end // macro b, first possibility
>   #else
>     #macro b()
>       // do something else
>     #end // macro b, second possibility
>   #end // if statement
> #end // macro a
>
> ..which unfortunatly can't be unrolled in the way you describe.

Yes it can:

#macro b_version1()
  // do one thing
#end // macro b, first possibility

#macro b_version2()
  // do something else
#end // macro b, second possibility

#macro a(foo)
  #if (foo)
    // call b_version1
  #else
    // call b_version2
  #end // if statement
#end // macro a

Post a reply to this message

Alex Vandiver <van### [at] tiacnet> wrote:
: Firstly, there seems to be some portability problems with
: respect to isosurfaces -- namely division by zero.  Rendering the
: following scene produces two completely different results under Linux
: and Windows.

  Actually it's not a portability problem. As far as I know, the C standard
says that if a division by 0 occurs, the compiler is free to do whatever
it wants. It can return some value, it can terminate the program with an
error, it can draw a nude woman on your screen... whatever it wants.
  So you can't expect anything if you make a division by 0.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: Yes.  I've known about this problem for a while now, but I don't know
: exactly how to fix it (or even how it should be fixed exactly).

  I don't think there's any portable way of detecting whether the FPU (or
the CPU for that matter) made a division by 0 or not.
  Since we are handling real numbers here (the set or real numbers does not
have +infinity nor -infinity), a division by 0 is undefined, so there's no
"correct" behaviour if it happens.
  Even if we had +infinity and -infinity, the value of 1/x when x is 0 is
undefined. You can't actually say whether it's +infinity or -infinity since
it depends on which side of the y-axis you are looking from (ie. if x
approaches 0 from the positive values, the result will approach +infinity,
but if it approaches from negative values it will be -infinity).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Gail Shaw <gsh### [at] monotixcoza> wrote:
: Depends. If you play with the mathematics it can be proved that
: x/0 = infinity where x!= 0

  Nope:

-1/0 = -infinity

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote in message <397d5fae@news.povray.org>...
>Gail Shaw <gsh### [at] monotixcoza> wrote:
>: Depends. If you play with the mathematics it can be proved that
>: x/0 = infinity where x!= 0
>
>  Nope:
>
>-1/0 = -infinity


picky :-)

Ok x/0 = infinity where x>0 and x/0 = -infinity where x<0

Gail
********************************************************************
* gsh### [at] monotixcoza              * Reality.dat not found         *
* http://www.rucus.ru.ac.za/~gail/ * Attempting to reboot universe *
********************************************************************
* The best way to accelerate Windows NT is at 9.8 m/s^2      *
********************************************************************

Post a reply to this message

Thorsten Froehlich wrote:

> Yes it can:
>
> #macro b_version1()
>   // do one thing
> #end // macro b, first possibility
>
> #macro b_version2()
>   // do something else
> #end // macro b, second possibility
>
> #macro a(foo)
>   #if (foo)
>     // call b_version1
>   #else
>     // call b_version2
>   #end // if statement
> #end // macro a

No -- you're missing the point.  The version I wrote leaves a macro, b(),
defined after a(foo) closes, which is dependant on what foo was at the time
a(foo) was called.  What you've got above will _call_ a version once, dependent
on foo, but macros etc after the fact will not themselves be able to call b()
and get a "dynamic" macro.
-Alex V.

Post a reply to this message

On 25 Jul 2000 05:36:47 -0400, Warp wrote:
>Gail Shaw <gsh### [at] monotixcoza> wrote:
>: Depends. If you play with the mathematics it can be proved that
>: x/0 = infinity where x!= 0
>
>  Nope:
>
>-1/0 = -infinity

This is a question of geometry. Some would claim that -infinity == infinity.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> 
> On 25 Jul 2000 05:36:47 -0400, Warp wrote:
> >Gail Shaw <gsh### [at] monotixcoza> wrote:
> >: Depends. If you play with the mathematics it can be proved that
> >: x/0 = infinity where x!= 0
> >
> >  Nope:
> >
> >-1/0 = -infinity
> 
> This is a question of geometry. Some would claim that -infinity == infinity.
Lol.... especially computers ;-)
And, uh, where can i find Colefax's Macros?? I sorta lost the link, i
think 8(
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

Post a reply to this message

In article <397DA192.8DEDB5DF@videotron.ca>, pk <thi### [at] videotronca> 
wrote:

> And, uh, where can i find Colefax's Macros?? I sorta lost the link, i
> think 8(

Let's see if I can beat The Ken. :-)
http://www.geocities.com/ccolefax/

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Alex Vandiver wrote:
> 
> No -- you're missing the point.  The version I wrote leaves a macro, b(),
> defined after a(foo) closes, which is dependant on what foo was at the time
> a(foo) was called.

Then how about this:

#macro a(foo)
   #if (foo)
     #declare Switch=1;
   #else
     #declare Switch=0;
   #end
#end

#if(Switch)
   #macro b()
      // do one thing
   #end
#else
   #macro b()
      // do another thing
   #end
#end

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Warp wrote:
> 
> It can return some value, it can terminate the program with an
> error, it can draw a nude woman on your screen...

... it can empty your bank account, format your HD, run away with your wife...
You've lost all your privileges now, boy.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <397DA722.A87A6A01@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> #macro a(foo)
>    #if (foo)
>      #declare Switch=1;
>    #else
>      #declare Switch=0;
>    #end
> #end
> 
> #if(Switch)
>    #macro b()
>       // do one thing
>    #end
> #else
>    #macro b()
>       // do another thing
>    #end
> #end

In that case, you have to use that #if() statement after every time you 
call a(). Not very user-friendly...a better solution would be this:

// set a "default" macro
#declare Switch = 1;

#macro B1(foo)...#end
#macro B2(foo)...#end

#macro A(Foo)
    #if(Foo)
        #declare Switch = 1;
    #else
        #declare Switch = 2;
    #end
#end


// Code which would be calling B() if nested declarations were allowed.
#if(Switch == 1)
    B1(Foo)
#else
    B2(Foo)
#end

And of course, for more than two versions of the macro, you simply use a 
#switch() statement. You could even put this in yet another macro, to 
hide the fact that one of several macros is being picked, like this:
#macro B(Bar)
    #if(Switch == 1)
        B1()
    #else
        B2()
    #end
#end

Another possible workaround would be to put the macros in separate 
include files, and have a macro include different files depending on 
which one you want. You can't nest a #macro within a #macro, but maybe 
you can nest a #macro within an #include within a #macro...I haven't 
actually tried it, though, and it seems like a messy way to code.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Tue, 25 Jul 2000 17:41:38 +0300, Margus Ramst wrote:
>Alex Vandiver wrote:
>> 
>> No -- you're missing the point.  The version I wrote leaves a macro, b(),
>> defined after a(foo) closes, which is dependant on what foo was at the time
>> a(foo) was called.
>
>Then how about this:
>
>#macro a(foo)
>   #if (foo)
>     #declare Switch=1;
>   #else
>     #declare Switch=0;
>   #end
>#end
>
>#if(Switch)
>   #macro b()
>      // do one thing
>   #end
>#else
>   #macro b()
>      // do another thing
>   #end
>#end

Still not the same.  Something like this would be, though:

#macro a(foo)
  #declare Switch=foo;
#end

#macro b()
  #if (Switch)
    // do one thing
  #else
    // do another thing
  #end
#end

but, perversely, I find the nested macro solution somehow more elegant.
For one thing, it uses one less entry in the global symbol table.  For
another, it parses more quickly, particularly if you'll be calling b a
lot.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Tue, 25 Jul 2000 12:36:01 -0700, Alex Vandiver wrote:
> But what I'm wondering is if we need to do this
>workaround -- so far I've not heard anyone explain WHY nested calls are
>explicitly outlawed in MegaPOV.  If the official verion can do it, why
>can't Mega?  

Just hazarding a guess, I'd suspect it has something to do with the "fast
macro" patch, which caches the macro for later use rather than seeking back
to where it's defined each time it gets called.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> Something like this would be, though:
> 
> #macro a(foo)
>   #declare Switch=foo;
> #end
> 
> #macro b()
>   #if (Switch)
>     // do one thing
>   #else
>     // do another thing
>   #end
> #end

Yes, that would work -- though it would have a large impact on parsing
time in the case of the spline include, where b() is called once for
every segment of the spline.  But what I'm wondering is if we need to
use this workaround -- so far I've not heard anyone explain WHY nested
calls are explicitly outlawed in MegaPOV.  If the official verion can do
it, why can't Mega?  Especially if, as Ron says (and I agree), the
nested macro calls are "cleaner"?  If there was no reason from the
parsing standpoint to limit nested macros, and it was merely to coerce
people to unroll them, then perhaps a warning rather than an error would
be more appropriate?
-Alex V.

Post a reply to this message

On Tue, 25 Jul 2000 12:40:21 -0700, Alex Vandiver wrote:
[something I obviously foresaw through my advanced precognitive powers]

No fair canceling and reposting the article after I already replied.
Even if you did misspell a word. :)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> No fair canceling and reposting the article after I already replied.
> Even if you did misspell a word. :)

Well, I was also fixing my email address.  And it was only posted for
under a minute -- and before I'd seen you reply to it.  Sheesh -- stop
being so Ken-like! ;>
-Alex V.

Post a reply to this message

Warp wrote:
> 
> Gail Shaw <gsh### [at] monotixcoza> wrote:
> : Depends. If you play with the mathematics it can be proved that
> : x/0 = infinity where x!= 0
> 
>   Nope:
> 
> -1/0 = -infinity
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

 So,  -infinity*0 = -1 ?

Alberto.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote...
> On Tue, 25 Jul 2000 12:36:01 -0700, Alex Vandiver wrote:
> > But what I'm wondering is if we need to do this
> >workaround -- so far I've not heard anyone explain WHY nested calls are
> >explicitly outlawed in MegaPOV.  If the official verion can do it, why
> >can't Mega?
>
> Just hazarding a guess, I'd suspect it has something to do with the "fast
> macro" patch, which caches the macro for later use rather than seeking
back
> to where it's defined each time it gets called.

This is true.  I haven't found a way to pull a nested macro out of a
pre-parsed macro.  I didn't spend a lot of time trying to do it, though, so
it might not be too difficult.

-Nathan

Post a reply to this message

Alberto wrote in message <397E3931.861014D8@usb.ve>...
> So,  -infinity*0 = -1 ?


Depends on how you got your -infinity and your 0 :-)

Mark

Post a reply to this message

Alberto <jac### [at] usbve> wrote:
:> -1/0 = -infinity

:  So,  -infinity*0 = -1 ?

  Nope. You are thinkin here "I translate the 0 from the left hand side to
the right hand side".
  This way of thinking is mathematically incorrect.
  When you have this:

  a/b = c

and you convert to this:

  a = c*b

you are not "translating" the 'b' from lhs to rhs, but you are multiplicating
both sides with 'b'. That is, if we put an extra step in between, we can see
what's really happening:

  a/b = c  <=>  (a/b)*b = c*b  <=>  a = c*b

  It's mathematically correct to multiply both sides with the same value.

  Now, in this case we have:

  -1/0 = -infinity

  What you are trying to do is to multiply both sides with 0:

<=>  (-1/0)*0 = -infinity*0  <=>  0/0 = -infinity*0

  Both, 0/0 and -infinity*0 are undefined. And 0/0 certainly is NOT the
same as -1.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Alex Vandiver <van### [at] tiacnet> wrote...
> The other, unrelated, quirk is that of nested macro definitions.  Why
> does MegaPOV specifically complain about them, and refuse to parse
> them?  Is there a workaround?  Because otherwise Chris Colefax's
> wonderful spline macro file is useless in MegaPOV..

I had a brainstorm and figured out how to implement nested macros.  I guess
it wasn't that hard after all.  I just ran a test and my idea works!  :-)

-Nathan

Post a reply to this message

I think that the problem here is trying to give a meaning to the
expression -1/0 :-)

Alberto

Post a reply to this message