The comments for ot_index_box() in octree.c contain the following text:

*   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
floating
*   point format to work.  This is true of most common systems except VAXen,
*   Crays, and Alpha AXP in VAX compatibility mode.  Local "float" variables
*   can NOT be made double precision "double" or "DBL".

-Nathan

Robert Alan Byer <bye### [at] mailourserversnet> wrote...
> I thought I had everything working in my POV-Ray v3.1g port for OpenVMS
> UNTIL I tried the radiosity demo scene.
>

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
: floating
: *   point format to work.

  Why?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> 
>   I don't understand. How can you have all these problems with the core
> source of povray in VMS when nobody else has the same problems? It looks like
> you don't have the same source codes as anyone else has.
>

I'm using the stock "povuni_s.tgz" from the Unix Download page at the
POV-Ray site.

Plus the fact that I'm NOT Unix or Linux of any kind, I'm porting
the Unix code over to OpenVMS which is slightly different.
 
-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

> 
> The comments for ot_index_box() in octree.c contain the following text:
> 
> *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
> floating
> *   point format to work.  This is true of most common systems except VAXen,
> *   Crays, and Alpha AXP in VAX compatibility mode.  Local "float" variables
> *   can NOT be made double precision "double" or "DBL".
> 
> -Nathan

(Doing best Homer Simpson impersonation)  DOOOOOOHHHHHH

Might help if I actually read :}~

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

Nieminen Juha <war### [at] sarakerttunencstutfi> wrote...
> Nathan Kopp <Nat### [at] koppcom> wrote:
> : *   PORTABILITY WARNING:  this function REQUIRES IEEE single precision
> : floating
> : *   point format to work.
>
>   Why?

Later in the code you'll run across these two cryptic operations and
comments that describe them.

First,

  /*
   * This hex operation does a floor to next lower power of 2, by clearing
   * all of the mantissa bits.  Works only on IEEE single precision floats
   */
  convert.f = maxdel;
  convert.l &= 0xff800000;
  bsized = (DBL) convert.f;

And later,
  /*
   * This magic hex operation extracts the exponent, which gives us an
   * integer number suitable for labelling a range of a power of 2.  In IEEE
   * format, value = pow(2,exponent-127). Therefore, if our index is, say,
   * 129, then the item has a maximum extent of (2 to the (129-127)), or
   * about 4 space units.
   */
  convert.f = (float) bsized;
  base_id.Size = (convert.l & 0x7f800000) >> 23;


The variable "convert" is defined as follows:
  union
  {
    float f;
    long l;
  }
  convert;


A portable version of these operations could be written, using logrithms and
fractional powers, but it would be significantly slower.  I suggest #ifdef
blocks so that VAX and other non-IEEE-compliant systems will be able to run
this code, even if it does have to run slowly.

-Nathan

Post a reply to this message

>
> fractional powers, but it would be significantly slower.  I suggest #ifdef
> blocks so that VAX and other non-IEEE-compliant systems will be able to run
> this code, even if it does have to run slowly.
>

This is what so far has been done to keep compatibility.  I'm looking
into this
more as I have been told that the newer compiler has a IEEE float
compliant
setting.

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

Eeew, what a horrid way to treat floats.

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: A portable version of these operations could be written, using logrithms and
: fractional powers, but it would be significantly slower.  I suggest #ifdef
: blocks so that VAX and other non-IEEE-compliant systems will be able to run
: this code, even if it does have to run slowly.

  I definitely agree. Optimizations are ok, but there should always be the
possibility of compiling it in any system.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> 
> Nathan Kopp <Nat### [at] koppcom> wrote:
> : A portable version of these operations could be written, using logrithms and
> : fractional powers, but it would be significantly slower.  I suggest #ifdef
> : blocks so that VAX and other non-IEEE-compliant systems will be able to run
> : this code, even if it does have to run slowly.
> 
>   I definitely agree. Optimizations are ok, but there should always be the
> possibility of compiling it in any system.
> 

I agree also...

Currently, here's the situation...

OpenVMS on Alpha platforms does have IEEE float mode (using the compiler
switch
"/FLOAT=IEEE_FLOAT") and using that without the modifications to
"octree.c"
allows radiosity to work just fine.

OpenVMS on VAX platforms don't have a IEEE float mode so I have to use
the
modifications for "octree.c" to make radiosity work.

What I've done is put in an "#ifdef" for OpenVMS VAX in "octree.c" so
that
only OpenVMS VAX will use that modification.

I did some testing between using IEEE float and the modification in
"octree.c"
on the Alpha plat form and this is what I found.

Using the "RAD2.POV" radiosity file and using the following POV
command...

   povray +IRAD2.POV +ORAD2.TGA +FT +Q9 +QR +V1 +D +A0.300 +W640 +H480
+B1000

using the modified "octree.c" and not using IEEE float it took 7
minutes, 54 seconds.  Using IEEE float and not useing the modified
"octree.c" it took
4 minutes, 47 seconds, a definate improvement.  (Note the Alpha platform
was a AlphaStation 500/333, a 333MHz system).

-- 

 +--------------------------+----------------------------------------+
 | Robert Alan Byer         | "I don't want to take over the world,  |
 | bye### [at] mailourserversnet |  just my own little part of it."       |
 | Phone: (317)357-2724     | http://www.ourservers.net/~byer        |
 +--------------------------+----------------------------------------+
 | Send an E-mail request to obtain my PGP key.        ICQ #65926579 |
 +-------------------------------------------------------------------+

Post a reply to this message

Nathan Kopp wrote:
>   /*
>    * This hex operation does a floor to next lower power of 2, by clearing
>    * all of the mantissa bits.  Works only on IEEE single precision floats
>    */
[...]
>   /*
>    * This magic hex operation extracts the exponent, which gives us an
>    * integer number suitable for labelling a range of a power of 2.  In IEEE
>    * format, value = pow(2,exponent-127). Therefore, if our index is, say,
>    * 129, then the item has a maximum extent of (2 to the (129-127)), or
>    * about 4 space units.
>    */
[...]
> A portable version of these operations could be written, using logrithms and
> fractional powers, but it would be significantly slower.

These operations can be easily implemented using the standard C
functions ldexp and frexp, which should be reasonably fast (although 
probably not as fast as the integer operations above) on any base2
system.

	hp 

-- 
   _  | Peter J. Holzer             | Think of it as evolution in action
|_|_) | Sysadmin WSR                |
| |   | hjp### [at] wsracat               |   -- Tony Rand in "Oath of Fealty"
__/   | http://wsrx.wsr.ac.at/~hjp/ | 	   by Niven & Pournelle

Post a reply to this message