![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gail Shaw <gsh### [at] monotix co za> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote in message <397d5fae@news.povray.org>...
>Gail Shaw <gsh### [at] monotix co za> 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] monotix co za * 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 25 Jul 2000 05:36:47 -0400, Warp wrote:
>Gail Shaw <gsh### [at] monotix co za> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Ron Parker wrote:
>
> On 25 Jul 2000 05:36:47 -0400, Warp wrote:
> >Gail Shaw <gsh### [at] monotix co za> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <397DA192.8DEDB5DF@videotron.ca>, pk <thi### [at] videotron ca>
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] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <397DA722.A87A6A01@peak.edu.ee>, Margus Ramst
<mar### [at] peak edu ee> 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] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |