POV-Ray : Newsgroups : povray.binaries.images : Divide by negative zero Server Time
29 Mar 2024 04:20:02 EDT (-0400)
  Divide by negative zero (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: Divide by negative zero
Date: 28 Oct 2018 06:38:39
Message: <5bd591af$1@news.povray.org>
Am 26.10.2018 um 20:13 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 26.10.2018 um 05:41 schrieb Anthony D. Baye:
>>> It seems to me that the engine used to throw an error when this happened...
>> ...
>>> Version 3.8.0-alpha.9606898.unofficial
>>
>> That's on Linux, I presume?
>>
>> POV-Ray does produce a warning if the second operand compares /equal to
>> zero/.
>> [etc]
>>
> 
> For what it's worth, in POV-Ray for Windows v3.7.1 beta 9, I see the same
> results as Anthony's original image-- the misplaced orange dot and the missing
> hexagons at the top.

Maybe the value isn't even exactly negative zero - I do get a "Division 
by zero" warning with all the POV-Ray for Windows binaries I've 
currently within close reach whenever I try to divide by exact negative 
zero.


Post a reply to this message

From: JimT
Subject: Re: Divide by negative zero
Date: 30 Oct 2018 05:55:01
Message: <web.5bd82976a617eb51be7517870@news.povray.org>
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> What it should look like.
>
> Regards,
>
> A.D.B.

Anthony,

If you use the x(tVal1) = UI1 + Ud*tVal1 , y(tVal2) = VI1 + Vd*tVal2 formulation
for the lines then (x(tVal1)-y(tVal2)).Ud = 0 and
(x(tVal1)-y(tVal2)).Vd = 0 give 2 equations for tVal1 and tVal2. These would
give the nearest points of the pair of lines in 3D or the intersection point of
lines in 2D.

In the following, the only division is by detM, which will only be zero if the
lines are parallel. This will therefore not tread on the +-0 problem POV Ray
seems to have.

Thanks,

JimT

#macro IPoint(UI1, UI2, VI1, VI2)
  #local Ud      = vnormalize(UI2 - UI1);
  #local Vd      = vnormalize(VI2 - VI1);
  #local UddotVd = vdot(Ud,Vd);
  #if(UddotVd    = 1)
    #local rX    = 0;  // Parallel lines so no soln or infinite solns
    #local rY    = 0;
  #else
    #local UV1   = UI1 - VI1;
    #local b1    = vdot(-UV1,Ud);
    #local b2    = vdot( UV1,Vd);
    #local detM  = 1 - UddotVd*UddotVd;
    #local tVal  = (b1 + UddotVd*b2)/detM;
    #local Upt   = UI1 + Ud*tVal;
    #local rX    = Upt.x;
    #local rY    = Upt.y;
  #end
  #local retval  = <rX,rY, 0.0>;
  retval
#end


Post a reply to this message

From: dick balaska
Subject: Re: Divide by negative zero
Date: 1 Nov 2018 19:06:08
Message: <5bdb86e0$1@news.povray.org>
On 10/26/18 2:02 AM, clipka wrote:
> - BUT -
> 
> ...
>
> POV-Ray for Linux is usually compiled with `-ffast-math`.
> ...
> So if you want to be sure that you're not dividing by negative zero,
> either (a) explicitly test if the divisor is equal to zero in your scene
> code (this is reliable because POV-Ray's equality operator is
> implemented to use an error margin), or (b) re-compile POV-Ray without
> `-ffast-math`.

Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
package does not use -ffast-math.  So, "usually" might be a bit strong.

From debian/rules:
  CXXFLAGS += -O3

  # This is rumoured to give wrong results with zero-thickness boxes, so
  # disabled
  # CXXFLAGS += -ffast-math


and a compile line:
g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base
-I../source/frontend -I../unix -I../vfe -I../vfe/unix -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/OpenEXR -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -I/usr/include  -I/usr/include  -pipe
-Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
-Wno-non-template-friend -g -O2
-fdebug-prefix-map=/home/dick/povray/debian/povray-3.7.0.7=.
-fstack-protector-strong -Wformat -Werror=format-security -O3 -pthread
-c -o lightgrp.o lightgrp.cpp

-- 
dik
Rendered 1024 of 921600 pixels (0%)


Post a reply to this message

From: clipka
Subject: Re: Divide by negative zero
Date: 1 Nov 2018 21:08:36
Message: <5bdba394$1@news.povray.org>
Am 02.11.2018 um 00:06 schrieb dick balaska:
> On 10/26/18 2:02 AM, clipka wrote:
>> - BUT -
>>
>> ...
>>
>> POV-Ray for Linux is usually compiled with `-ffast-math`.
>> ...
>> So if you want to be sure that you're not dividing by negative zero,
>> either (a) explicitly test if the divisor is equal to zero in your scene
>> code (this is reliable because POV-Ray's equality operator is
>> implemented to use an error margin), or (b) re-compile POV-Ray without
>> `-ffast-math`.
> 
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math.  So, "usually" might be a bit strong.

Given that "out of the box" from the official repository POV-Ray's Unix 
build process defaults to `-ffast-math`, I stick with "usually" and call 
Debian's package a - laudable - exception.

(Also, since distro packages are not compiled by each end user but only 
by the package manager, technically my statement remains true either way ;))


Post a reply to this message

From: William F Pokorny
Subject: Re: Divide by negative zero
Date: 2 Nov 2018 10:20:31
Message: <5bdc5d2f$1@news.povray.org>
On 11/1/18 7:06 PM, dick balaska wrote:
> On 10/26/18 2:02 AM, clipka wrote:
> 
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math.  So, "usually" might be a bit strong.
> 
>  From debian/rules:
>    CXXFLAGS += -O3
> 
>    # This is rumoured to give wrong results with zero-thickness boxes, so
>    # disabled
>    # CXXFLAGS += -ffast-math
> 
> 
> and a compile line:
> g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base
> -I../source/frontend -I../unix -I../vfe -I../vfe/unix -I/usr/include/SDL
> -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/OpenEXR -Wdate-time
> -D_FORTIFY_SOURCE=2 -pthread -I/usr/include  -I/usr/include  -pipe
> -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs
> -Wno-non-template-friend -g -O2
> -fdebug-prefix-map=/home/dick/povray/debian/povray-3.7.0.7=.
> -fstack-protector-strong -Wformat -Werror=format-security -O3 -pthread
> -c -o lightgrp.o lightgrp.cpp
> 

Interesting. I see too -fstack-protector-strong which off the top of my 
head the default compile does not use. Oh, and there is no -march=native 
so expect quite a few other optimizations not done. -D_FORTIFY_SOURCE=2 
added too.

Suppose compile differences like these something to keep in mind when 
someone reports a bug or performance concern where they might be using a 
pre-compiled package with different defaults than POV-Ray 'publishes.'

Aside: I've never done comparisons with and without -ffast_math. Wonder 
what the performance (result?) difference is...

Aside: Zero thickness boxes I'd think problematic in any case. Not 
opaque, differing inside/outside textures etc. Perhaps to the point the 
parser should complain on seeing such a box. Maybe something else 
meant...

Bill P.


Post a reply to this message

From: Kenneth
Subject: Re: Divide by negative zero
Date: 2 Nov 2018 18:35:01
Message: <web.5bdcd07da617eb5143b397d0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

>
> Aside: Zero thickness boxes I'd think problematic in any case. Not
> opaque, differing inside/outside textures etc. Perhaps to the point the
> parser should complain on seeing such a box. Maybe something else
> meant...
>

I use a fair amount of zero-thickness boxes-- for 'billboard' images and such
like-- and haven't encountered any problems so far. But not placed right up
against another object (re: coincident surface problems).


Post a reply to this message

From: dick balaska
Subject: Re: Divide by negative zero
Date: 3 Nov 2018 04:36:36
Message: <5bdd5e14@news.povray.org>
On 11/2/18 10:20 AM, William F Pokorny wrote:

> 
> Interesting. I see too -fstack-protector-strong which off the top of my
> head the default compile does not use. 



> Oh, and there is no -march=native
> so expect quite a few other optimizations not done. -D_FORTIFY_SOURCE=2
> added too.

-march=native is interesting.  "Up to 60% performance increase" [1].
Well that's a hell of a thing if true.  But, you have to know which
Intel arch you are compiling for.  Skylake/Haswell/Cannonlake/etc are
all different.

If that is true, it's too bad there isn't a switch in packages based on
arch.
(This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
on "Hey, it runs on any x64 hardware, even AMD".
Which made me think of Jr; "If I was still running Slackware, I'd have
built my own Intel Clear Linux kernel with clang" ;)  )


[1]
https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
-- 
dik
Rendered 1024 of 921600 pixels (0%)


Post a reply to this message

From: jr
Subject: Re: Divide by negative zero
Date: 3 Nov 2018 05:15:01
Message: <web.5bdd6647a617eb516427f7f90@news.povray.org>
hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;)  )

but..  it /is/ 2018 and there's /no/ gui..   ;-)


regards, jr.


Post a reply to this message

From: Jim Holsenback
Subject: Re: Divide by negative zero
Date: 3 Nov 2018 06:43:20
Message: <5bdd7bc8$1@news.povray.org>
On 11/1/18 7:06 PM, dick balaska wrote:
> On 10/26/18 2:02 AM, clipka wrote:
>> - BUT -
>>
>> ...
>>
>> POV-Ray for Linux is usually compiled with `-ffast-math`.
>> ...
>> So if you want to be sure that you're not dividing by negative zero,
>> either (a) explicitly test if the divisor is equal to zero in your scene
>> code (this is reliable because POV-Ray's equality operator is
>> implemented to use an error margin), or (b) re-compile POV-Ray without
>> `-ffast-math`.
> 
> Most humbly, I would like to point out that the Debian POV-Ray 3.7.0.x
> package does not use -ffast-math.  So, "usually" might be a bit strong.

i've been using various flavors of opensuse for over 10 years now and 
have never had to do anything /special/ during build process. just 
simply configure and make has always worked just fine for me... 
fast-math, march and even boost have /never/ been an issue for me. i've 
always thought that rolling your own is way better than using one of the 
pre-built distributions... /not/ an expert just personal observations


Post a reply to this message

From: William F Pokorny
Subject: Re: Divide by negative zero
Date: 3 Nov 2018 11:06:45
Message: <5bddb985$1@news.povray.org>
On 11/3/18 4:36 AM, dick balaska wrote:
> On 11/2/18 10:20 AM, William F Pokorny wrote:
> 
...
> 
> -march=native is interesting.  "Up to 60% performance increase" [1].
> Well that's a hell of a thing if true. 

If your talking about not using say AVX2 and AVX512 instructions, the 
performance can easily be 2-4x worse than best possible for some code.

> But, you have to know which
> Intel arch you are compiling for.  Skylake/Haswell/Cannonlake/etc are
> all different.
> 

Christoph earlier this year suggested to me I think about enabling 
solver code optimized for different architectures as I work on solver 
fixes/updates. I found the gcc/g++ compilers have a cool feature called 
Function Multi-Versioning (FMV). The linux kernel has been using the 
feature for a long while. In addition to letting you hard code 
CPU-specific optimizations, it lets you optimize for a collection of 
processors/features with a one line modification to code:

#define MAX 1000000
int a[256], b[256], c[256];

__attribute__((target_clones("avx2","arch=atom","default")))
void foo(){
     int i,x;
     for (x=0; x<MAX; x++){
         for (i=0; i<256; i++){
             a[i] = b[i] + c[i];
         }
     }
}

The compiler creates target versions of the function for each 
architecture clone and at run time the best version (by some priority) 
of a function gets used. For later gcc versions and 'gnu' dynamically 
loaded code the resolution happens once during the load - the pointer to 
the function gets fixed to the 'best' compiled version for the CPU's 
feature set.

Unfortunately not yet gotten time to play with the feature. The FMV 
compiler feature isn't standardized across compilers though others seem 
to have something like it.

> If that is true, it's too bad there isn't a switch in packages based on
> arch.
> (This took me down a rabbit hole lamenting that debian/Ubuntu is stuck
> on "Hey, it runs on any x64 hardware, even AMD".
> Which made me think of Jr; "If I was still running Slackware, I'd have
> built my own Intel Clear Linux kernel with clang" ;)  )
> 
> [1]
> https://www.phoronix.com/scan.php?page=news_item&px=GCC-8-march-native-Skylake
> 

Bill P.


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.