|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |