On Tue, 13 Jul 2021 09:59:58 +1000, Clifford Heath
<no.spam@please.net> wrote:

>On 13/7/21 1:56 am, jlarkin@highlandsniptechnology.com wrote:
>> On Mon, 12 Jul 2021 08:46:33 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 11/07/2021 16:57, Joe Gwinn wrote:
>>>> On Sun, 11 Jul 2021 08:56:05 +0100, Martin Brown
>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>
>>>>> On 10/07/2021 21:38, Phil Hobbs wrote:
>>>>>> jlarkin@highlandsniptechnology.com wrote:
>>>
>>>>>>> We're doing a timing project now and sometimes switch between cycles
>>>>>>> and radians, to about 1 PPB resolution.
>>>>>>
>>>>>> Sure, plus frequency synthesis and all sorts of DSP things.  (I only
>>>>>> ever memorized pi to REAL*8 accuracy---for higher precision it's
>>>>>> 4*ridiculous_precision_atan(1.).) ;)
>>>>>
>>>>> 6*ridiculous_precision_asin(0.5) converges a lot faster.
>>>>>
>>>>> These days it isn't such a problem since hardware support for floating
>>>>> point is much better. Some older implementations struggled with atan(1).
>>>>>
>>>>> My supervisor used to use 4*atan(1) until someone pointed out to him
>>>>> that was the most difficult to converge point of the atan function.
>>>>> Some older FORTRAN compilers did not get it right to full precision!
>>>>
>>>> Later DEC VAX hardware implemented 128-bit floats in hardware.
>>>
>>> That seems more than a bit overkill - no wonder they got into trouble.
>>>
>>> I can count on the fingers of one hand the times when I have actually
>>> *needed* to use quad precision (mostly for checking a double precision
>>> algorithm) and most physics problems can be solved in single precision.
>>> You seldom have 6 meaningful significant digits in real experimental
>>> data (although mass spectrometry is one place where you sometimes do).
>>
>> We need double floats to do some numeric-ratio frequency synthesizer
>> math.
>
>I thought I needed 64-bit division to calculate frequency delta words
>for the AD9959 DDS chip, but wound up implementing reciprocal division.
>If done correctly, you get better than PPB accuracy using only a
>32x32->64 multiply:
>
><https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L251-L256>
>
><https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L282>
>
>Yes, I know, Arduino, urk. But that's what was called-for in this case.
>
>Even the little AVR can do "64-bit division" in about 70us using this
>method.
>
>> Number theory, primes and relative primes and common divisor sorts of
>> stuff, pop up now and then. The people who make frequency synth chips
>> obviously have code to drive them (as in eval kits) but won't reveal
>> it. PITA.
>
>Indeed. One wonders what business they think they're in.
>
>Clifford Heath.

We had to grunt out the math for the LMX2571 synthesizer chip. It's a
matter of finding the best N/M to scale the clock to the target
frequency, with a bunch of other divisors somewhere, and some rules
about selecting VCOs and spurs and stuff.

Once it's working, it's very good.

On 12/07/2021 20:49, Phil Hobbs wrote:
> Martin Brown wrote:
>> On 12/07/2021 14:38, Phil Hobbs wrote:
>>> Martin Brown wrote:
>>>> On 11/07/2021 16:57, Joe Gwinn wrote:
>>>>
>>>>> Mathematica handles arbitrary precision quite well.  See the N[]
>>>>> operator.
>>>>
>>>> I prefer Maxima through the wxMaxima GUI since it is free.
>>>>
>>>> It isn't quite as powerful as Mathematica but it can still do the
>>>> job if used carefully. It is easy to end up with mismatched brackets
>>>> but apart from that it is fine and you really can't beat the price!
>>>>
>>>
>>> I've been wanting to switch from my current 20-year-old copy of
>>> Mathcad to something like Maxima running in a Jupyter notebook, but
>>> there's no supported way to do that at the moment.
>>
>> Mathcad - now that is a blast from the past! Does it still work on Win7?
>> More of a scratchpad but pretty good for trying out engineering ideas.
>
> It's still sold by PTC, I think.  Mine is version 2001i, which is Win32,
> so it works fine on Win 7 and under Wine in Linux.  (You do need a few
> native DLLs for Wine.)
>
>> I found Maxima with the GUI much less difficult to get to grips with
>> than the text interface even though it was less powerful that way.
>> I'm using the Windows port but Linux and Mac iOS is also supported.
>
> I mostly use Mathcad for what I call 'photon budgets', which are
> actually first-principles feasibility calculations for instruments or
> measurement schemes in general.  If you don't do the theory, there's no
> way of knowing how good your gizmo _could_ be, so you have no idea how
> well you're doing.
>
> I need to be able to make nice printed documents with a lot of
> properly-formatted text and plots to send to clients.  Mathcad is nice
> that way because they can all be 'live' for me, but few of my clients
> use it, so they get the PDFs.

If what you have now will do what you want well enough then I would
recommend sticking with it until you run into something that forces a
change to solve a problem. The learning curve to make full use of Maxima
is pretty steep and it does have some rough edges here and there.

I only jumped ship because I had a horrible expression that I needed to
differentiate and it defied my existing tools and all manual efforts.
Maxima got it and could solve the resulting quartic to a closed form. -
incredibly ugly messy expression but to my surprise it could do it.

--
Regards,
Martin Brown

On 12/07/2021 20:22, bitrex wrote:
> On 7/12/2021 3:32 AM, Martin Brown wrote:
>> On 11/07/2021 14:06, Jeroen Belleman wrote:
>>> On 2021-07-11 09:56, Martin Brown wrote:

>>>> We were allowed pi^2 = g in physics calculations at university.
>>>
>>> The trouble with that is that it makes no physical sense. It's
>>> a coincidence, and not even a very accurate one. It's numerology.
>>>
>>> <https://xkcd.com/1047/>
>>
>> Oh yes, but at that level it is allowable. Physics undergraduates by
>> that stage know perfectly well that it is a coincidence. Not a good
>> idea to use that crude an approximation in a practical exam though!
>>
>> We were also allowed seconds in a year = pi x 10^7 in theory papers.
>>
>> Which isn't in your teacher trolling table and is good to 0.5% or so.
>
> G = 1, c = 1, h_bar = 1, k = 1, Q_e = whatever.

I was reading a paper not that long ago with pi = 1

It was most confusing...

--
Regards,
Martin Brown

bitrex wrote:
>
> Everything about the history of your life is written in the digits of
> pi! And all the alternate histories too. And every other irrational
> number. And a library that contains everything, contains nothing :(

Although it's possible that some sequences never occur.

It's interesting to note that sequences do repeat but, even if the
sequence is a gogolplex long, the next digit will be different each
time.

Maybe the latter disproves the former.

--
Defund the Thought Police

On Tue, 13 Jul 2021 09:59:58 +1000, Clifford Heath
<no.spam@please.net> wrote:

>On 13/7/21 1:56 am, jlarkin@highlandsniptechnology.com wrote:
>> On Mon, 12 Jul 2021 08:46:33 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 11/07/2021 16:57, Joe Gwinn wrote:
>>>> On Sun, 11 Jul 2021 08:56:05 +0100, Martin Brown
>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>
>>>>> On 10/07/2021 21:38, Phil Hobbs wrote:
>>>>>> jlarkin@highlandsniptechnology.com wrote:
>>>
>>>>>>> We're doing a timing project now and sometimes switch between cycles
>>>>>>> and radians, to about 1 PPB resolution.
>>>>>>
>>>>>> Sure, plus frequency synthesis and all sorts of DSP things.  (I only
>>>>>> ever memorized pi to REAL*8 accuracy---for higher precision it's
>>>>>> 4*ridiculous_precision_atan(1.).) ;)
>>>>>
>>>>> 6*ridiculous_precision_asin(0.5) converges a lot faster.
>>>>>
>>>>> These days it isn't such a problem since hardware support for floating
>>>>> point is much better. Some older implementations struggled with atan(1).
>>>>>
>>>>> My supervisor used to use 4*atan(1) until someone pointed out to him
>>>>> that was the most difficult to converge point of the atan function.
>>>>> Some older FORTRAN compilers did not get it right to full precision!
>>>>
>>>> Later DEC VAX hardware implemented 128-bit floats in hardware.
>>>
>>> That seems more than a bit overkill - no wonder they got into trouble.
>>>
>>> I can count on the fingers of one hand the times when I have actually
>>> *needed* to use quad precision (mostly for checking a double precision
>>> algorithm) and most physics problems can be solved in single precision.
>>> You seldom have 6 meaningful significant digits in real experimental
>>> data (although mass spectrometry is one place where you sometimes do).
>>
>> We need double floats to do some numeric-ratio frequency synthesizer
>> math.
>
>I thought I needed 64-bit division to calculate frequency delta words
>for the AD9959 DDS chip, but wound up implementing reciprocal division.
>If done correctly, you get better than PPB accuracy using only a
>32x32->64 multiply:
>
><https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L251-L256>
>
><https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L282>
>
>Yes, I know, Arduino, urk. But that's what was called-for in this case.
>
>Even the little AVR can do "64-bit division" in about 70us using this
>method.

This would be integer division, not IEEE floating-point (which can do
integer arithmetic only to 52 bits)..

Most modern instruction set architectures support multi precision
integer arithmetic in (assembly code) software.

Joe Gwinn

On 13/07/2021 16:36, Joe Gwinn wrote:

> This would be integer division, not IEEE floating-point (which can do
> integer arithmetic only to 52 bits)..

Depends really. The most common x87 implementation can do a 64 bit
mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
it and makes a hash of consistent rounding to 53 bits for good measure.

I haven't tried it but I expect the chip can handle 64 bit integer loads
and arithmetic perfectly well but the compiler will only let you store a
53 bit mantissa and 11 bit exponent result (unless you knobble it).

ISTR MSC v6.0 was the last with proper long double support included.

> Most modern instruction set architectures support multi precision
> integer arithmetic in (assembly code) software.

High precision integer arithmetic isn't all that hard.

--
Regards,
Martin Brown

On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 13/07/2021 16:36, Joe Gwinn wrote:
>
>> This would be integer division, not IEEE floating-point (which can do
>> integer arithmetic only to 52 bits)..
>
>Depends really. The most common x87 implementation can do a 64 bit
>mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
>it and makes a hash of consistent rounding to 53 bits for good measure.
>
>I haven't tried it but I expect the chip can handle 64 bit integer loads
>and arithmetic perfectly well but the compiler will only let you store a
>53 bit mantissa and 11 bit exponent result (unless you knobble it).
>
>ISTR MSC v6.0 was the last with proper long double support included.
>
>> Most modern instruction set architectures support multi precision
>> integer arithmetic in (assembly code) software.
>
>High precision integer arithmetic isn't all that hard.

PowerBasic allows quad integer and extended float (10 byte) variables.

We've used that when c was not good enough, or too slow.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On 7/13/2021 8:48 AM, Martin Brown wrote:
>> Most modern instruction set architectures support multi precision
>> integer arithmetic in (assembly code) software.
>
> High precision integer arithmetic isn't all that hard.

No -- and need not be implemented in ASM.

But, it is considerably slower. And, things like transcendental
functions get *really* expensive (as there is no hardware assist).

OTOH, you often don't need that sort of range/precision for
run-of-the-mill calculations.

On 7/13/2021 4:28 AM, Martin Brown wrote:
> On 12/07/2021 20:22, bitrex wrote:
>> On 7/12/2021 3:32 AM, Martin Brown wrote:
>>> On 11/07/2021 14:06, Jeroen Belleman wrote:
>>>> On 2021-07-11 09:56, Martin Brown wrote:
>
>>>>> We were allowed pi^2 = g in physics calculations at university.
>>>>
>>>> The trouble with that is that it makes no physical sense. It's
>>>> a coincidence, and not even a very accurate one. It's numerology.
>>>>
>>>> <https://xkcd.com/1047/>
>>>
>>> Oh yes, but at that level it is allowable. Physics undergraduates by
>>> that stage know perfectly well that it is a coincidence. Not a good
>>> idea to use that crude an approximation in a practical exam though!
>>>
>>> We were also allowed seconds in a year = pi x 10^7 in theory papers.
>>>
>>> Which isn't in your teacher trolling table and is good to 0.5% or so.
>>
>> G = 1, c = 1, h_bar = 1, k = 1, Q_e = whatever.
>
> I was reading a paper not that long ago with pi = 1
>
> It was most confusing...
>
>

>

Roundabout way of showing pi is a constant, an n-ball in an
n-dimensional Euclidean space is a set of points equidistant from a
central point. A circle is a 2-ball. Without assuming pi is a constant
you can derive a recurrence relation:

<https://en.wikipedia.org/wiki/Volume_of_an_n-ball#The_one-dimension_recursion_formula>

and use the functional equation for the gamma function to derive an
expression for the volume of an n-ball, and take the factor of
gamma(1/2) to be some unknown constant.

Then pi is defined by the value of gamma(1/2) needing to be sqrt(pi),
the unique constant such that the volume of the n-ball V_n(R) is always
maximal with respect to its surface area for all permutations of n, R
from the set of reals (Euler-Lagrange equations.)

I think...

On 13/07/2021 17:38, jlarkin@highlandsniptechnology.com wrote:
> On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 13/07/2021 16:36, Joe Gwinn wrote:
>>
>>> This would be integer division, not IEEE floating-point (which can do
>>> integer arithmetic only to 52 bits)..
>>
>> Depends really. The most common x87 implementation can do a 64 bit
>> mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
>> it and makes a hash of consistent rounding to 53 bits for good measure.
>>
>> I haven't tried it but I expect the chip can handle 64 bit integer loads
>> and arithmetic perfectly well but the compiler will only let you store a
>> 53 bit mantissa and 11 bit exponent result (unless you knobble it).
>>
>> ISTR MSC v6.0 was the last with proper long double support included.
>>
>>> Most modern instruction set architectures support multi precision
>>> integer arithmetic in (assembly code) software.
>>
>> High precision integer arithmetic isn't all that hard.
>
> PowerBasic allows quad integer and extended float (10 byte) variables.
>
> We've used that when c was not good enough, or too slow.

GCC can do quad FP precision OK. It is the MickeySoft compiler that has
had its extended floating point support almost completely hobbled.

--
Regards,
Martin Brown

Martin Brown wrote:
> On 13/07/2021 17:38, jlarkin@highlandsniptechnology.com wrote:
>> On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 13/07/2021 16:36, Joe Gwinn wrote:
>>>
>>>> This would be integer division, not IEEE floating-point (which can do
>>>> integer arithmetic only to 52 bits)..
>>>
>>> Depends really. The most common x87 implementation can do a 64 bit
>>> mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
>>> it and makes a hash of consistent rounding to 53 bits for good measure.
>>>
>>> I haven't tried it but I expect the chip can handle 64 bit integer loads
>>> and arithmetic perfectly well but the compiler will only let you store a
>>> 53 bit mantissa and 11 bit exponent result (unless you knobble it).
>>>
>>> ISTR MSC v6.0 was the last with proper long double support included.
>>>
>>>> Most modern instruction set architectures support multi precision
>>>> integer arithmetic in (assembly code) software.
>>>
>>> High precision integer arithmetic isn't all that hard.
>>
>> PowerBasic allows quad integer and extended float (10 byte) variables.
>>
>> We've used that when c was not good enough, or too slow.
>
> GCC can do quad FP precision OK. It is the MickeySoft compiler that has
> had its extended floating point support almost completely hobbled.
>

BITD the Intel C++ compiler could do that too, and plugged into Visual
Studio.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 7/13/2021 10:36 AM, Tom Del Rosso wrote:
> bitrex wrote:
>>
>> Everything about the history of your life is written in the digits of
>> pi! And all the alternate histories too. And every other irrational
>> number. And a library that contains everything, contains nothing :(
>
> Although it's possible that some sequences never occur.

Yes, I should've said _almost_ every irrational number, you can
construct irrational numbers that are non-terminating non-repeating that
don't contain any particular sequence by design.

> It's interesting to note that sequences do repeat but, even if the
> sequence is a gogolplex long, the next digit will be different each
> time.
>
> Maybe the latter disproves the former.
>
>

On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 13/07/2021 16:36, Joe Gwinn wrote:
>
>> This would be integer division, not IEEE floating-point (which can do
>> integer arithmetic only to 52 bits).
>
>Depends really. The most common x87 implementation can do a 64 bit
>mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
>it and makes a hash of consistent rounding to 53 bits for good measure.

MS is famous for such things. The standard answer is Gnu C/C++.

In many realtime systems, the 64-bit floats are generated directly
from a template, by writing the mantissa directly into a pre-formed
64-bit float This can be done in assembly or in C using bitwise
parallel logic operators.

I recall a famous story from the 1990s, when Microsoft was building
their own versions of standard UNIX tools. There was a meeting where
MS was presenting their Korn shell, and the presenter got into an
argument with a middle-aged guy about the required behavior. The
audience soon started to titter.

Turned out that they were trying to tell David Korn how the Korn Shell
ought to work - they had no idea who that guy was. A classic
Microsoft Moment (TM).

>I haven't tried it but I expect the chip can handle 64 bit integer loads
>and arithmetic perfectly well but the compiler will only let you store a
>53 bit mantissa and 11 bit exponent result (unless you knobble it).
>
>ISTR MSC v6.0 was the last with proper long double support included.

The MS-proof alternative is Gnu C/C++ under Linux.

>> Most modern instruction set architectures support multi precision
>> integer arithmetic in (assembly code) software.
>
>High precision integer arithmetic isn't all that hard.

Agree.

Joe Gwinn

On 14/7/21 1:36 am, Joe Gwinn wrote:
> On Tue, 13 Jul 2021 09:59:58 +1000, Clifford Heath
> <no.spam@please.net> wrote:
>
>> On 13/7/21 1:56 am, jlarkin@highlandsniptechnology.com wrote:
>>> On Mon, 12 Jul 2021 08:46:33 +0100, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> On 11/07/2021 16:57, Joe Gwinn wrote:
>>>>> On Sun, 11 Jul 2021 08:56:05 +0100, Martin Brown
>>>>> <'''newspam'''@nonad.co.uk> wrote:
>>>>>
>>>>>> On 10/07/2021 21:38, Phil Hobbs wrote:
>>>>>>> jlarkin@highlandsniptechnology.com wrote:
>>>>
>>>>>>>> We're doing a timing project now and sometimes switch between cycles
>>>>>>>> and radians, to about 1 PPB resolution.
>>>>>>>
>>>>>>> Sure, plus frequency synthesis and all sorts of DSP things.  (I only
>>>>>>> ever memorized pi to REAL*8 accuracy---for higher precision it's
>>>>>>> 4*ridiculous_precision_atan(1.).) ;)
>>>>>>
>>>>>> 6*ridiculous_precision_asin(0.5) converges a lot faster.
>>>>>>
>>>>>> These days it isn't such a problem since hardware support for floating
>>>>>> point is much better. Some older implementations struggled with atan(1).
>>>>>>
>>>>>> My supervisor used to use 4*atan(1) until someone pointed out to him
>>>>>> that was the most difficult to converge point of the atan function.
>>>>>> Some older FORTRAN compilers did not get it right to full precision!
>>>>>
>>>>> Later DEC VAX hardware implemented 128-bit floats in hardware.
>>>>
>>>> That seems more than a bit overkill - no wonder they got into trouble.
>>>>
>>>> I can count on the fingers of one hand the times when I have actually
>>>> *needed* to use quad precision (mostly for checking a double precision
>>>> algorithm) and most physics problems can be solved in single precision.
>>>> You seldom have 6 meaningful significant digits in real experimental
>>>> data (although mass spectrometry is one place where you sometimes do).
>>>
>>> We need double floats to do some numeric-ratio frequency synthesizer
>>> math.
>>
>> I thought I needed 64-bit division to calculate frequency delta words
>> for the AD9959 DDS chip, but wound up implementing reciprocal division.
>> If done correctly, you get better than PPB accuracy using only a
>> 32x32->64 multiply:
>>
>> <https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L251-L256>
>>
>> <https://github.com/cjheath/AD9959/blob/b3ee0b91c5be7d626a8bf3aeb5a605870ed8ac4b/AD9959.h#L282>
>>
>> Yes, I know, Arduino, urk. But that's what was called-for in this case.
>>
>> Even the little AVR can do "64-bit division" in about 70us using this
>> method.
>
> This would be integer division, not IEEE floating-point (which can do
> integer arithmetic only to 52 bits)..

Yes, of course. My point is if you have 64 bit integers and can apply
scaling (effectively making fixed-point math) then you don't need FP.

> Most modern instruction set architectures support multi precision
> integer arithmetic in (assembly code) software.

The gcc libraries for AVR have hand-coded full 64-bit support in ASM,
but it's still just a 16-bit chip and long division isn't very quick.
Reciprocal multiplication is much quicker, and in my example didn't need
64x64, just 32x32.

CH

On 13/07/2021 19:59, Phil Hobbs wrote:
> Martin Brown wrote:
>> On 13/07/2021 17:38, jlarkin@highlandsniptechnology.com wrote:
>>> On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
>>> <'''newspam'''@nonad.co.uk> wrote:
>>>
>>>> On 13/07/2021 16:36, Joe Gwinn wrote:
>>>>
>>>>> This would be integer division, not IEEE floating-point (which can do
>>>>> integer arithmetic only to 52 bits)..
>>>>
>>>> Depends really. The most common x87 implementation can do a 64 bit
>>>> mantissa and 16 bit exponent in hardware but MS C/C++ no longer
>>>> supports
>>>> it and makes a hash of consistent rounding to 53 bits for good measure.
>>>>
>>>> I haven't tried it but I expect the chip can handle 64 bit integer
>>>> loads
>>>> and arithmetic perfectly well but the compiler will only let you
>>>> store a
>>>> 53 bit mantissa and 11 bit exponent result (unless you knobble it).
>>>>
>>>> ISTR MSC v6.0 was the last with proper long double support included.
>>>>
>>>>> Most modern instruction set architectures support multi precision
>>>>> integer arithmetic in (assembly code) software.
>>>>
>>>> High precision integer arithmetic isn't all that hard.
>>>
>>> PowerBasic allows quad integer and extended float (10 byte) variables.
>>>
>>> We've used that when c was not good enough, or too slow.
>>
>> GCC can do quad FP precision OK. It is the MickeySoft compiler that
>> has had its extended floating point support almost completely hobbled.
>>
>
> BITD the Intel C++ compiler could do that too, and plugged into Visual
> Studio.

It still can but only if you are running Win10 *and* have a state of the
art graphics card otherwise it point blank refuses to install at all.
Their online cloud service is even less user friendly.

GCC/GFORTRAN was easily path of least resistance (and free).

--
Regards,
Martin Brown

On 13/07/2021 21:35, Joe Gwinn wrote:
> On Tue, 13 Jul 2021 16:48:09 +0100, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 13/07/2021 16:36, Joe Gwinn wrote:
>>
>>> This would be integer division, not IEEE floating-point (which can do
>>> integer arithmetic only to 52 bits).
>>
>> Depends really. The most common x87 implementation can do a 64 bit
>> mantissa and 16 bit exponent in hardware but MS C/C++ no longer supports
>> it and makes a hash of consistent rounding to 53 bits for good measure.
>
> MS is famous for such things. The standard answer is Gnu C/C++.

It works well enough. However, many of my clients require that it also
works on Mickeysoft because they use that compiler (don't ask me why!).

> I recall a famous story from the 1990s, when Microsoft was building
> their own versions of standard UNIX tools. There was a meeting where
> MS was presenting their Korn shell, and the presenter got into an
> argument with a middle-aged guy about the required behavior. The
> audience soon started to titter.
>
> Turned out that they were trying to tell David Korn how the Korn Shell
> ought to work - they had no idea who that guy was. A classic
> Microsoft Moment (TM).

*Wonderful* and entirely believable too!

>> I haven't tried it but I expect the chip can handle 64 bit integer loads
>> and arithmetic perfectly well but the compiler will only let you store a
>> 53 bit mantissa and 11 bit exponent result (unless you knobble it).
>>
>> ISTR MSC v6.0 was the last with proper long double support included.
>
> The MS-proof alternative is Gnu C/C++ under Linux.

I'm using it under Win7 via MinGW_G64 which works well enough.

Code still has to work correctly on both compilers...

--
Regards,
Martin Brown