In article <405df651@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> When and where did I say something about "a simple ratio", and why should I?

Looking back on your message, you didn't mention fractions...I somehow 
thought you were talking about storing floats as dividend and divisor. 
Sorry about that...


> You are missing that fraction and exponent are integers, and "conversion" to
> a less precise representation either yields an overflow/underflow or a
> match.  Nothing else happens in hardware when dealing with single and double
> precision floats, in fact.  If you want to do no work at all, just define
> the fraction as 64 bit integer and the exponent as 16 bit integer.  Then you
> just shift to get your favorite floating-point representation.  Double both
> and you can even support 128 bit IEEE 754 floats easily!  Not to mention the
> old VAX float format uses exactly the same concept.

Right, but there's no built-in mechanism for handling this. If you want 
to use 128-bit IEEE754 floats, you have to write IEEE754 floats...


> All you did was fall for the pseudo benefits frequently mentioned by XML
> advocates. 

I didn't fall for anything. I'm simply explaining why text formats are 
so often used, in response to Warp's "Why not make a compact binary
format instead?": it's easier to just use existing functions than write 
new ones that do what you need. In other words, laziness...and harmless 
because the files are small. Sometimes it's just stupidity...that's the 
only reason I can think of for XML being what it is, and for things like 
SVG using it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

On 19 Mar 2004 18:15:39 -0500, Breton Slivka <Zen### [at] ZenPsychocom>
wrote:

>So, I know that there's been much talk about using XML for povray scene 
>description language, and a lot of sunk in povray purists will have none 
>of it!

Since I am the one to blame for the latest bringing up the issue, I
feel I should comment.

XML is definitely unsuitable for POV-Ray scene description. Most
people hand-code and the overhead of XML is a needless pain in the
behind. That's pretty much what most comments boil down to and my
personal opinion follows the same route.

However, ...

>This would also bring the advantages that XML brings, of easy 
>portability, parsing, and flexibility of presentation, eliminating the 
>difficulties involved in creating alternative rendering engines for quick 
>preview of povray scenes. 

...I personally believe XML might be worth a try (unofficially) as a
means to export already parsed POV-Ray scenes (prior to rendering) for
the purpose of converting to other formats -- at least the parts that
make sense. Surely it is not possible to convert the general POV-Ray
scene because basically everything is procedural - 99% of the
textures, and quite a lot of the objects (isos, julias, blobs to some
extent etc.) But there are definitely cases where one can benefit a
lot by some interoperation between POV and other packages, for example
by generating a city in POV using Chris Colefax' macros, then render
it in Terragen or even Radiance for the skies or lighting,
respectively.

>Suppose then that a patch in povray would allow the automatic translation 
>between these 3 formats, and the direct parsing of the formats into 
>internal tokens. 

In any case if one decides to try to implement something along these
lines, it should be in an unofficial version. First of all, the next
version of POV (as of current development plans 4.0, release date as
usually unknown :) ) plans some major rewrite. Who knows what state
XML will be in by then? It might not make sense at all to use it
because it might be practically dead by the time 4.0 is out.

>Anyways, I'd be interested in hearing why this is a stupid idea.

I don't think it's a stupid idea, but definitely one that needs a lot
of thought and planning to be taken seriously.


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

Post a reply to this message

In article <cjameshuff-FC25CE.17232321032004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

> Right, but there's no built-in mechanism for handling this. If you want
> to use 128-bit IEEE754 floats, you have to write IEEE754 floats...

I am not sure what this is supposed to say at all.  Nothing says that "
double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
currently offer 128 bit IEEE 754 floats as "long double".

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> I am not sure what this is supposed to say at all.  Nothing says that "
> double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
> currently offer 128 bit IEEE 754 floats as "long double".

  UltraSparc is an example of this. (Their problem is that long doubles
are considerably slower than doubles. Curiously doubles are often
faster than integers, believe it or not. Sparcs are odd. :) )

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> 
>>I am not sure what this is supposed to say at all.  Nothing says that "
>>double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
>>currently offer 128 bit IEEE 754 floats as "long double".
> 
> 
>   UltraSparc is an example of this. (Their problem is that long doubles
> are considerably slower than doubles. Curiously doubles are often
> faster than integers, believe it or not. Sparcs are odd. :) )
> 
Wasn't that because they have to convert integer to double, do the
arithmetic and convert back?

Post a reply to this message

In article <405f5d42@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>> I am not sure what this is supposed to say at all.  Nothing says that "
>> double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
>> currently offer 128 bit IEEE 754 floats as "long double".
>
>   UltraSparc is an example of this.

Not only there.  The first Sparc FPU defined this already.  Even funnier,
also unrelated, Sparc FPUs use two 64 bit float registers to store one 128
bit float.  Not very RISC-like.  Well, actually Sparc FPUs are not really
part of the CPU in the instruction set design.  Sparc rather closely follows
the 68K "extension" processor model.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Wasn't that because they have to convert integer to double, do the
> arithmetic and convert back?

  That would be a quite stupid way of doing it, so I would be quite surprised
if it indeed was so.

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

In article <405f412f$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > Right, but there's no built-in mechanism for handling this. If you want
> > to use 128-bit IEEE754 floats, you have to write IEEE754 floats...
> 
> I am not sure what this is supposed to say at all.  Nothing says that "
> double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
> currently offer 128 bit IEEE 754 floats as "long double".

But common languages, and none that I know of which it would be feasible 
to write POV in, have a standard, portable facility for writing 128 bit 
IEEE 754 floats. You would have to write your own code to do so, if you 
just write the floats directly, you will get different results on 
different platforms.

And I know it's an easy problem to fix, which is why I called the wide 
use of text for numeric values laziness.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

In article <cjameshuff-C61DD4.07112823032004@news.povray.org> , Christopher
James Huff <cja### [at] earthlinknet>  wrote:

>> > Right, but there's no built-in mechanism for handling this. If you want
>> > to use 128-bit IEEE754 floats, you have to write IEEE754 floats...
>>
>> I am not sure what this is supposed to say at all.  Nothing says that "
>> double " cannot be a 128 bit IEEE 754 float.  In fact, certain platforms do
>> currently offer 128 bit IEEE 754 floats as "long double".
>
> But common languages, and none that I know of which it would be feasible
> to write POV in, have a standard, portable facility for writing 128 bit
> IEEE 754 floats.

C and C++ have "long double".  Neither language specifies that "double"
implies 64 bit IEEE 754 float either.  Apart from C and C++, Fortran
supports more than 64 bit IEEE 754 floats as well.  Honestly, I am not aware
of any other languages that really matter in the scientific computing
community.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On 23 Mar 2004 05:51:36 -0500, Warp <war### [at] tagpovrayorg> wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Wasn't that because they have to convert integer to double, do the
>> arithmetic and convert back?
>
>   That would be a quite stupid way of doing it, so I would be quite 
> surprised
> if it indeed was so.
>


That is, in fact, the way Pentium4 processors do integer multiplication.
It has little to do with stupidity, and everything to do with saving space 
on the die.

___
FE

Post a reply to this message