quote:Original post by Samith Performance is really not much of an issue with what I''m doing. Since I just want to write a fractel viewer pretty much, so it''s not going to be fast anyway. This GMP thing actually looks pretty good, I might give it a try, considering the method Raptor85 posted could get pretty messy.
hehehe, i should write the code and post it here, i''ve done it with 32 byte integers before. (just as a toy, not in anything serious though)
quote:Original post by Magmai Kai Holmlor The x586 FPU has a 256bit floating point format. I think you''d have to write some FPU assembly to use them. This gives you a lot more precision than the typical float, double, or long double, but will come with a minimal performance penalty.
Hmmm.... I don''t think that''s right. IIRC, the i586 FPU represents floats internally with 80-bit precision, and offers the ability to load and store 32-, 64-, and 80-bit floats.
I was thinking of the SSE registers, which means x786; and I''m not certain you can use all 128bits for a single number. 256/2 = 128, carry the 2 + x586 -> x786... or something.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
I don''t know much about different methods for representing numbers with arbitrary precision or >80bit floats. However, I know the problem with rendering fractals, which has a few properties (I take the Mandelbrot set as an example here):
- You KNOW that your numbers will never be larger than a relatively small integer (e.g. 4 in the case of the Mandelbrot set). - Floating point representations are not very helpful, since you need N decimal points, regardless if the absolute value of a number is in the order 1.0 or 0.0000000000000001, for instance (floating point values only help where the numbers approach zero, which is the case for the least interesting part of the Mandelbrot set).
I think that it should be possible to device a pretty efficient fixed point format, where you only use very few bits for the integer part (e.g. 2-4 bits).
You may also consider the fact that you use complex numbers in your calculations, so perhaps a polar format may be more appropriate than a standard cartesian format (addition may be tricky though). I don''t know if it would buy you any advantage in terms of binary representation/computation.
marcus256: I can avoid having to implement it with polar coordinates by just calculating for the real part and calculating for the imaginary part. This is a lot easier, if you ask me.
