![](/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) |
Warp <war### [at] tag povray org> wrote in news:3d4b2513@news.povray.org
>> #ifndef max
>> #define max(a,b) ( a > b ? a : b )
>> #endif
>> #ifndef min
>> #define min(a,b) ( a < b ? a : b )
>> #endif
>> This is easier than searching & prefacing all max
>> and min calls with std:: , eh? ;-)
> How is it easier than writing 'using namespace std;' instead?
> Besides, your solution is very bad. Do you know why?
<rot13>
fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
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) |
Rafal 'Raf256' Maj <raf### [at] raf256 com> wrote:
> fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
Eh... I don't think *any* min/max implementation will allow it to
perform them at compile-time, no matter how advanced... :)
No, that's not the problem.
--
#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
|
![](/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 2 Aug 2002 23:11:04 -0400, Warp wrote:
> Rafal 'Raf256' Maj <raf### [at] raf256 com> wrote:
>> fbzr rkcerfvbaf jvyy abg or pnyphyngrq ng pbzcvyr-gvzr ?
>
> Eh... I don't think *any* min/max implementation will allow it to
> perform them at compile-time, no matter how advanced... :)
> No, that's not the problem.
Actually, there are two problems with that implementation. Which one
are you looking for, or will you give partial credit for either one?
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
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 2 Aug 2002 22:11:13 -0400, Warp <war### [at] tag povray org> wrote:
> But you are a professional. You can't participate. ;)
I know! I know! And I ain't no pro, buddy.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vip bg
TAG e-mail : pet### [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:
>
> Bob Jamison <rja### [at] lincom-asg com> wrote:
> > #ifndef max
> > #define max(a,b) ( a > b ? a : b )
> > #endif
> > #ifndef min
> > #define min(a,b) ( a < b ? a : b )
> > #endif
>
> > This is easier than searching & prefacing all max
> > and min calls with std:: , eh? ;-)
>
> How is it easier than writing 'using namespace std;' instead?
>
> Besides, your solution is very bad. Do you know why?
>
Well, i'm no expert in c, but i guess
max(++x, y)
would cause problems.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______
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) |
Christoph Hormann <chr### [at] gmx de> wrote:
> Well, i'm no expert in c, but i guess
> max(++x, y)
> would cause problems.
Yes, that's the big problem.
Another minor problem is caused by the exact same reason: If you have
complicated statements as parameters to that "function", they will be
evaluated twice, thus producing inefficient code.
If you want to make the min() and max() functions in C++, the correct
way is to use templates. The result will be the same, but without the
mentioned problems (yes, compilers do a very good job when inlining this
type of functions and all temporary local variables will simply be gone).
template<typename T>
inline T max(const T& a, const T& b)
{
return a > b ? a : b;
}
(This is most probably how it's implemented in the STL, although there
*might* be some optimization as well...)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - 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) |
Christoph Hormann <chr### [at] gmx de> wrote in
news:3D4B8CF7.90B5D011@gmx.de
> Well, i'm no expert in c, but i guess
> max(++x, y)
ofcourse :) but I wrong understand question, I thounght question was, why
sometimes #define is better then std::
with define something like
const int size_a = 100;
const int size_b = 500;
...
void fun() { int max_size = max(size_a,size_b); // <-- this will be changed
// to int max_size=500 at compile-time
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
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 Sat, 03 Aug 2002 09:57:43 +0200, Christoph Hormann wrote:
>
>
> Warp wrote:
>>
>> Bob Jamison <rja### [at] lincom-asg com> wrote:
>> > #ifndef max
>> > #define max(a,b) ( a > b ? a : b )
>> > #endif
>> > #ifndef min
>> > #define min(a,b) ( a < b ? a : b )
>> > #endif
>>
>> > This is easier than searching & prefacing all max
>> > and min calls with std:: , eh? ;-)
>>
>> How is it easier than writing 'using namespace std;' instead?
>>
>> Besides, your solution is very bad. Do you know why?
>>
>
> Well, i'm no expert in c, but i guess
>
> max(++x, y)
>
> would cause problems.
The other problem is precedence. If a or b are expressions, they'll be
substituted directly into the other expression above. Some expressions
might not take the substitution so well. For example, what if you did
max( c==d?c:d, b )
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] 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) |
"Ron Parker" <ron### [at] povray org> wrote in message
news:slr### [at] fwi com...
>
> The other problem is precedence. If a or b are expressions, they'll be
> substituted directly into the other expression above. Some expressions
> might not take the substitution so well. For example, what if you did
> max( c==d?c:d, b )
>
Which you can fix with brackets (which also fixes all other problems,
other than the efficiency issue (which'll more often than not get handled by
an optimising compiler anyway)).
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
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) |
Pandora <pan### [at] pandora-software com> wrote:
> Which you can fix with brackets (which also fixes all other problems,
Wrong. It doesn't fix the max(i++, j++) problem.
> the efficiency issue (which'll more often than not get handled by
> an optimising compiler anyway)).
Wrong. For example if you call a function to get the value of the
parameter, eg. max(function1(), function2()), the compiler can't optimize
that double call away unless it can inline the function in question. If
it can't inline the function, it can't know if the function will return
a different value at the second call. If it takes a considerable amount of
time to execute these functions, time will be wasted in calling them twice.
(And if the function *does* return a different value when called again, the
whole max() macro will simply give the wrong result for the exact same reason
as the max(i++, j++) gives a wrong result.)
Using the template solution fixes all problems.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - 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) |