"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:
> > But is that what you would do if it had been years since an official
version
> > was released, the users were getting restless, and 4.0 was probably still
> > years away?
> Do users really need an official version every few years?  I'm happy with
unofficial
> patches, as long as they work the way I expect :)
>

AFAIK: Yes! Just consider the use of POV as a benchmark...
Although this is probably not, what POV was invented for, and where it's
real powers are, it's still used as an official benchmark...

You can't think, that people are using "unofficial patches" for doing serious
benchmarks ...


--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

probably it would have been enough, to look at IEEE 754 ?

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

> AFAIK: Yes! Just consider the use of POV as a benchmark...
> Although this is probably not, what POV was invented for, and where it's
> real powers are, it's still used as an official benchmark...
>
> You can't think, that people are using "unofficial patches" for doing serious
> benchmarks ...
What I meant was: of course we need official versions of POV-Ray, but I'm not
gonna complain because there hasn't been an official POV-Ray for over a year (or
even 2 years).

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Alf Peake wrote:

> Why do I never see anyone mention 2.1?

I haven't a clue :)

-- 
Ken Tyler

Post a reply to this message

Alan Kong wrote in message ...
>
>  I am feeding coins through the ventilation slots in my computer. Are they
>coming through at your end? :)


// --------8<--------8<-----------8<----------8<-----------8<--------8<-----
#version 3.5;
#declare MoneyAmount=30;

#include "colors.inc"
#include "rand.inc"
#declare Coin=
  union
  { difference
    { cylinder
      { 0,y*.3,2
        pigment { Copper }
        normal
        { radial 1 slope_map { [0 <0,1>][.5 <1,0>][1 <0,-1>] }
          frequency 120
        }
        finish { specular .5 metallic reflection .1 }
      }
      cylinder { -y*.01,y*.05,1.9 }
      cylinder { y*.31,y*.25,1.9 }
    }
    union
    { difference
      { cylinder { <0,.2,.8><0,.35,.8>,1 }
        cylinder { <0,.2,.8><0,.36,.8>,.6 }
        box { <.001,.2,-.2><1,.36,.8> }
      }
      difference
      { cylinder { <0,.2,-.8><0,.35,-.8>,1 }
        cylinder { <0,.2,-.8><0,.36,-.8>,.6 }
        box { <0,.2,.2><-1,.36,-.8> }
      }
      scale <1,1,.8>
    }
    box { <-.08,.2,-1.7><.08,.35,1.7> translate -x*.25 }
    box { <-.08,.2,-1.7><.08,.35,1.7> translate x*.25 }
    pigment { Copper }
    normal { bumps .2 scale .1 }
    finish { specular 1 roughness .002 metallic reflection .1 }
    scale .5

  }

camera { location <0,1,-1>*(sqrt(MoneyAmount)*2+5) look_at 0 angle 35 }
light_source { <50,200,-100> 1 }
plane { y,0 pigment { granite scale 5 } }

#declare Loc=array[MoneyAmount]
#declare R=seed(2);
#declare Ind=0;
#while(Ind<MoneyAmount)
  #declare Dist=Rand_Gauss(0,1,R)*sqrt(Ind)*1.5;
  #declare Ang = rand(R)*pi*2;
  #declare Loc[Ind] = <Dist*sin(Ang),0,Dist*cos(Ang)>;
  #declare Ind2=0;
  #while(Ind2<Ind)
    #declare cx=Loc[Ind2].x-Loc[Ind].x;
    #declare cz=Loc[Ind2].z-Loc[Ind].z;
    #if(cx*cx+cz*cz<4 & Loc[Ind2].y=Loc[Ind].y)
      #declare Loc[Ind]=Loc[Ind]+y*.15;
      #declare Ind2=0;
    #else
      #declare Ind2=Ind2+1;
    #end
  #end
  object {
    Coin
    #if(rand(R) > .5)
      scale <1,-1,1>
      translate y*.15
    #end
    rotate y*rand(R)*360
    translate Loc[Ind]
  }
  #declare Ind=Ind+1;
#end

Post a reply to this message

On Thu, 31 Jan 2002 01:36:45 -0500 Mark Wagner wrote:

>#version 3.5;
>#declare MoneyAmount=30;
<snip..>

  Oh, there they are. Nice placement of coins.

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message

Thorsten Froehlich wrote:

> ?!?!?
> 
> I don't understand what you want to do or what you are up to.  Or what
> supposedly now takes exponential time.

Sorry Thorsten - it's nothing to do with PoV really. I started to reply 
to this a couple of days ago, when I had another look at the way I'd 
re-written the algorithm I was using in MegaPoV to work with PoV3.5.

Basically I'd done a real p*ss-poor job of it and that was what was 
causing the slow down.

All I really needed to do was separate the three colours, warp each one 
and then average the results at the end.

<sigh> Why is it I only notice I've put my foot in my mouth when I'm 
chewing on the knee ... </sigh>

Apologies again,
	Mike Andrews.

Post a reply to this message

On 2002-01-30 15:58, Warp <war### [at] tagpovrayorg> wrote:
> Tom Melly <tom### [at] tomandlucouk> wrote:
> : Just out of curiousity, why does this surprise you?
> 
>   I knew that doubles are inaccurate, but it surprised me that they are *that*
> inaccurate. The inaccuracy is "only" in the 18th decimal.

"That" inaccurate? 18 decimal places is enough to locate anything
between here and Alpha Centauri with an inaccuracy of less than two
inches. 

>   On the other hand, 18 decimals starts to sound like the maximum number of
> digits (when converted to decimal) that the base of a double can hold...

More like 16, actually. An IEEE-754 double precision floating point
number is 64 bits long: 1 for the sign, 11 for the exponent, which
leaves 52 bits for the exponent. So the precision is log(2^52) = 15.6
decimal places.

	hp


-- 
   _  | Peter J. Holzer    |
|_|_) | Sysadmin WSR       | In case of emergency break laws of physics.
| |   | hjp### [at] hjpat         |
__/   | http://www.hjp.at/ | 	-- Stephen Baxter

Post a reply to this message

"Peter J. Holzer" <hjp### [at] hjpat> wrote in message
news:slr### [at] tealhhjpat...
> On 2002-01-30 15:58, Warp <war### [at] tagpovrayorg> wrote:
> > Tom Melly <tom### [at] tomandlucouk> wrote:
> > : Just out of curiousity, why does this surprise you?
> >
> >   I knew that doubles are inaccurate, but it surprised me that they are
*that*
> > inaccurate. The inaccuracy is "only" in the 18th decimal.
>
> "That" inaccurate? 18 decimal places is enough to locate anything
> between here and Alpha Centauri with an inaccuracy of less than two
> inches.
>
> >   On the other hand, 18 decimals starts to sound like the maximum number
of
> > digits (when converted to decimal) that the base of a double can hold...
>
> More like 16, actually. An IEEE-754 double precision floating point
> number is 64 bits long: 1 for the sign, 11 for the exponent, which
> leaves 52 bits for the exponent. So the precision is log(2^52) = 15.6
> decimal places.
>
> hp

I thought they were 80 bits - at least, on x87 chips they are (which doesn't
mean anything about the standard!).  Floats are 32bits (with an additional 8
bit mantissa), and doubles are 64 bits (with an additional 16 bit mantissa),
making them 40 and 80 bits, respectively.

...Chambers

Post a reply to this message

Ben Chambers <bdc### [at] yahoocom> wrote:
: I thought they were 80 bits - at least, on x87 chips they are (which doesn't
: mean anything about the standard!).  Floats are 32bits (with an additional 8
: bit mantissa), and doubles are 64 bits (with an additional 16 bit mantissa),
: making them 40 and 80 bits, respectively.

  The x87 chip (AFAIK) internally handles only 80-bit floats.
  When it reads a 32-bit or 64-bit float, it converts it to a 80-bit float
for its internal representation. When it writes a float to a 32-bit or 64-bit
variable (ie. to RAM), it makes the conversion the other way around.

  x86 code can have 32-bit floats (the 'float' type in C), 64-bit floats
(the 'double' type in C) and 80-bit floats (the 'long double' type in C,
although some compilers might make those 128-bit long for alignment
optimization purposes, with the extra 48 bits just being unused).
  A float takes exactly 32 bits (ie. 4 bytes) and a double takes exactly
64 bits (ie. 8 bytes), no more, no less.

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