In article <405dfd16$1@news.povray.org>, Darren New <dne### [at] sanrrcom> 
wrote:

> Christopher James Huff wrote:
> > Hmm...yes it is. To write "1.5" in a portable way in text only requires 
> > writing those three characters.
> 
> Along with a flag that says it's three characters.

No. You just have to say "write this float". The C and C++ standard 
libraries already have the capability of doing this. "strm << floatVal;" 
is a lot easier than writing your own function or tracking down some 
library to do it.


> And how do you think you get a floating-point 1.5 into those three 
> characters? :-)

By calling the appropriate standard function.


> The fact that it's built into the language doesn't make 
> it easier. It just makes it built in.

It does make it easier. If it's already there, you don't have to write 
it.


> I disagree. See above. Text formatting of integers is built into the 
> language. Try to output that 1.5 using nothing but putc() and knowing 
> nothing about the internal representation of floats, and you'll find 
> it's not as simple as you think. You tend to get things like 
> 1.499999999978 and you have to know the actual binary size of your 
> floating point numbers anyway in order to stop at the right place.

Of course it's harder if you do it the hard way. My point is that 
there's an existing easy way, which doesn't exist for binary data. And 
you lose information in the base conversion...but there's no guarantee 
the native format on a foreign machine will be the same anyway. You get 
something that works for almost everything with very little effort, and 
most people stop there.


> Well, actually, there is. ntoh() and hton(), Sun's XDR libraries, any 
> ASN.1 library, etc etc. Plus, move to any language that's actually been 
> invented in the last 20 years or so, and it probably has libraries for 
> doing this.

ntoh() and hton() don't appear to be standard. Sun's XDR libraries are 
Sun's, you gotta go get them. I know it's a pretty much solved problem, 
and was never very difficult, but it is still one more hurdle to go 
over. And many projects (like POV) use C or C++, moving to a language 
that has standard support is not always practical. This is one of my 
peeves about C/C++...any language I design that has file I/O will be 
able to read and write floats and integers in a platform independent way.

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