>On 14/01/2022 21:01, Joe Gwinn wrote:
>> On Fri, 14 Jan 2022 18:12:43 +0000, Martin Brown
>> <'''
newspam'''@nonad.co.uk> wrote:
>>
>>> On 14/01/2022 16:50, Hul Tytus wrote:
>>>> There was once a math library in c, if memory serves, with the
>>>> basic functions, ie +, -, * and / and some others also. The resolution
>>>> was adjustable so changing a reference variable (or was that a #define?)
>>>> from 32 to 256 would change the size of the variables to 256 bits.
>>>> Anyone rember the name or location of that library?
>>>
>>> I don't recall that particular one but GCC can be fairly easily
>>> persuaded to go up to 128 bit reals which are usually good enough for
>>> all but the most insane of floating point calculations.
>>>
>>> I think your choices there are limited to 32, 64, 80, 128
>>>
>>> <
https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html>
>>>
>>> It includes the most common transcendental functions as well.
>>>
>>> Quad floating precision runs slowly so do as much as you can at a lower
>>> precision and then refine the answer using that as a seed value.
>>>
>>> I used to like having 80 bit reals available in the good old prehistoric
>>> days of MSC v6. Today it requires some effort to use them with MSC :(
>>
>> In the old days, only VAX/VMS had hardware support for 128-bit floats
>> (not IEEE format though). In the cited GCC list, which of these are
>> directly supported in hardware, versus software emulation?
>
>32, 64 are native x87 and full SSE floating point support
>80 x87 only but GCC does it fairly well
>128 emulated and slower
>
>Always work in the hardware supported ones to obtain an approximate
>answer unless and until you need that extra precision.
Yes.
>Preferably frame it so you refine an approximate starting guess.
If possible. Sometimes I use a coarse-fine two-step algorithm.
>> Most current machines directly support multi precision integer
>> arithmetic for power-of-2 lengths, but it is done in multiple
>> coordinated machine-code operations, so it's partly in software.
>
>32, 64 and 128 integer support are sometimes native at least for some
>platforms. +, - and * all execute in one nominal CPU cycle* too!
>(at least for 32, 64 bit - I have never bothered with 128 bit int)
Nor have I, although for such things as time, integers are preferred
because the precision does not vary with magnitude.
Depending on the hardware, a pair of 64-bit integers can be scaled
such that one integer is the integer part and the other integer is the
fractional part, the decimal point being between the two integers.
Depending on hardware and compiler, this may be faster than floating
point.
>* sometimes they can appear to take less than one cycle due to out of
>order execution and the opportunities to do work whilst divides are in
>progress. Divides are always best avoided or if that is impossible their
>number minimised. Divide is between 10-20x slower than all the other
>primitive operations and two divides close together can be *much*
>slower. Pipeline stalls typically cost around 90 cycles per hit.
>
>divide remains a PITA and worth eliminating where possible.
It's usually possible to reformulate to multiply by the reciprocal.
>I have an assembler implementation for a special case division that can
>be faster than the hardware divide for the situation it aims to solve.
>
>Basically 1/(1-x) = 1 + x + x^2 + x^3 + x^4 + ...
> (1 + x)*(1 + x^2)*(1 + x^4)*(1 + x^8)
>
>And for smallish x it converges faster than hardware FP divide.
Yes, that example comes up in practice a good bit.
>> Of course, when the word size goes up, the various approximations
>> polynomials must improve, which generally means to use higher-order
>> polynomials, so the slowdown isn't all due to slower computational
>> hardware.
>
>There aren't all that many that need it.
Later in this thread you did mention Pade approximations, which turned
out to be good enough for simulating planetary systems with chaos.
In ray-tracing problems, the big hitters are sine and cosine, and some
tangent. I have not needed to determine if the current approximations
are good enough, but I'm suspicious, given that a slight displacement
of the intersection point on a curved optical surface will deviate the
ray ever so slightly, most likely changing the ray segment length ever
so slightly, ...
>Most planetary dynamics can be done with 80 bit reals with a bit to spare.
>
>> The only real application of 128-bit floats that I am aware of was the
>> design of interferometers such as LIGO, where one is tracking very
>> small fractions of an optical wavelength over path lengths in the
>> kilometers, with at least two spare decimal digits to absorb numerical
>> noise from the ray-trace computations.
>
>That might be a genuine application.
I'm pretty sure that it was an actual application. Probably been
replaced by now.
>The only times I have played with them have been to investigate the
>weird constants that play a part in some chaotic equations. I was
>curious to see how much of the behaviour was due to finite mantissa
>length and how much was inherent in the mathematics. Doubling the length
>of the mantissa goes a long way to solving that particular problem.
>(but it is rather slow)
Yes, that would be the classic test, needed only once in a while.
Joe Gwinn