On Fri, 29 Mar 2002 17:47:32 -0500, "Timothy R. Cook"
<tim### [at] scifi-fantasycom> wrote:

>Er, if you can test if a point is inside or outside the object, you
>can test if it's exactly on the surface (i.e. point is neither
>inside nor outside the object, or both, it must be coinciding)

No you can not. There's such a thing as limited floating point
precision. You may *assume* a point is on a surface but there is no
guarantee. For you, acos(sqrt(2)/2) may be equal to pi/4, but for a
computer it is not. Computers just can't deal with infinitely long
numbers.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> Computers just can't deal with infinitely long numbers.

Where's the fun in that?  *sigh*  I want a computer that can
handle infinitely long numbers...
-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> Er, if you can test if a point is inside or outside the object, you
> can test if it's exactly on the surface (i.e. point is neither
> inside nor outside the object, or both, it must be coinciding)

  Nope. I'm not talking about theory here, but about how it is implemented
in the POV-Ray source code.
  Functions which tell whether a point is inside a specific primitive or
not (these are necessary for CSG) return just two values: Either the point
is inside or it isn't.

  And as someone else already said, also floating point accuracy doesn't
allow telling whether a point is exactly on a surface, even if we have
a simple surface where this test would be trivial (eg. a sphere).
  For example, suppose that we have a sphere of radius 10 and we want to
test whether the point <10,0,0> is exactly on its surface. We would make
a test like: (sqrt(10^2+0^2+0^2) == 10)
  However, the test (sqrt(100) == 10) will most probably return false due
to floating point inaccuracies (you can test it if you want if you know C
and have a compiler).
  Equality is usually done with an epsilon value (ie.
abs(sqrt(100)-10) < epsilon), but this doesn't tell you whether the
point is exactly on the surface, outside it, or inside it. Using this
kind of test can tell you if the point is extremely close to the surface
but it won't tell you that if it isn't, if it is inside or outside it.


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

Warp wrote:
>   However, the test (sqrt(100) == 10) will most probably return false due
> to floating point inaccuracies (you can test it if you want if you know C
> and have a compiler).
>   Equality is usually done with an epsilon value (ie.
> abs(sqrt(100)-10) < epsilon), but this doesn't tell you whether the
> point is exactly on the surface, outside it, or inside it. Using this
> kind of test can tell you if the point is extremely close to the surface
> but it won't tell you that if it isn't, if it is inside or outside it.

Well that sucks.  Intel/AMD need to severly upgrade their FPUs.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> Intel/AMD need to severly upgrade their FPUs.

  To what?

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

Warp wrote:
> > Intel/AMD need to severly upgrade their FPUs.

>   To what?

To something that can correctly evaluate sqrt(100)==10.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Timothy R. Cook <tim### [at] scifi-fantasycom> wrote:
> To something that can correctly evaluate sqrt(100)==10.

  Any suggestion (which is not 1000 times slower than the current system)?

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

Warp wrote:
> > To something that can correctly evaluate sqrt(100)==10.

>   Any suggestion (which is not 1000 times slower than the current system)?

I'm an illustration major, not compsci.

-- 
Tim Cook
http://empyrean.scifi-fantasy.com

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

"Timothy R. Cook" wrote:
> 
> I'm an illustration major, not compsci.

So then let the compscis decide what's feasible and what not.

Markus

Post a reply to this message

Markus Becker <bec### [at] aicossde> wrote:
> So then let the compscis decide what's feasible and what not.

  Yeah. We know what you need and what you don't. ;)

  Seriously, sometimes something can look pretty simple and obvious and one
tends to think "how come they never have thought of this?". However, usually
when you care to find out about the issue you discover that it's one of
the things first considered and usually quickly discarded as completely
unfeasible. The reasons for discarding it may not always be obvious, but
they are usually very justifiable.

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