David Fontaine <dav### [at] faricynet> wrote:
: Either way you need an extra comparison...

  The solution is much better than repeating code (I didn't think about that
solution), but it still looks like a kludge :)

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

Post a reply to this message

On 4 Sep 2000 05:23:20 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>: There is only one type, so the user doesn't have to think about whether
>: automatic type conversion will do the right thing or whether he must
>: insert casts. 
>
>  Not exactly.
>  Yes, the user defined numbers can only be doubles, but povray handles these
>numbers as integers in some places. When you give povray a non-integer value
>in one of these places, povray just converts it to an integer.

Yes. But that that behaviour is fixed and hopefully documented. The user
should be aware of the fact that the number will be rounded to an
integer, and he only needs to decide whether the default rounding
operation is the one he wants or whether he needs to round himself.

A plethora of numeric variable types, like C has (8 integers and 3 float
types) however, forces the user to decide on every variable what type it
should have. He has to think on every operation what happens when
operands are of different types, whether the result might overflow or
lose precision, etc. This may not be a problem for you and me, because
we are programmers (but accidents happen even to us, as you demonstrated
earlier in this thread), but I think the average povray user would be
overwhelmed by it. It also makes povray a lot more complicated
internally, and it gains very little. 

>: For some applications a double FP isn't precise enough. int_64 and long
>: double (80 bit on Intel, up to 128 bit on some other architectures) have
>: good HW support, but also finite precision and range.
>
>  It's not possible to define a hardware-supported int_64 in ANSI C if the
>default value of int is 32 bits long.

It is now (C99 added the "long long" type). Many compilers already
support it, although it will take several years before you can rely on
it.

However, this wasn't what I meant. 64 bit arithmetic can be implemented
on every architecture with just a few instructions for every operation.
Even if the compiler doesn't directly support them, 64 bit operations
can be easily and and reasonably efficiently implemented as functions
written in assembler or C.

Numbers with infinite precision on the other hand always need loops and
- even worse - you can't bound them. (1E1000+1)*(1E1000+1) gives a
result with a million digits and sqrt(2) one with an infinite number of
digits (so you would have to stop somewhere arbitrarily). Slow and
difficult to use, and only rarely useful.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message