Paul S Person <psperson@old.netcom.invalid> schrieb:
> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
><tkoenig@netcologne.de> wrote:
>
>>Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>
>>>>>> <snippo discussion of basic physics terminology>
>>>>>>
>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>> difficult.
>>>>>>
>>>>>> Brave man!
>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>
>>>>
>>>> Pity there's not a 64 bit version of the Fortran
>>>
>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>> may have a better experience.
>>
>>What is a 64-bit Fortran compiler?
>
> Presumably, it would be one that generates 64-bit code, using features
> that would not work on a 32-bit computer.

And with well-written, standard-conforming code, it does not matter.

> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
> emulate, even if running on 64-bit hardware.

Not visible from a user program, except for speed.

>
>>Typical compilers have a four-byte integer, but it is possible to
>>select different kinds of integer via the selected_int_kind
>>intrinsic, telling the compiler how many digits you need.
>
> I would expect a 64-bit C compiler to have an 8-byte 'int', since
> 'int' is intended to be the largest value the hardware can handle as a
> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
> brethren are doing something different.

Yes indeed. The standard is now i32lp64, 32-bit ints and 64-bit longs
and pointers.

>>For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>today) 32 and 64 bit IEEE floats, respectively.
>
> That is unlikely to change. But floats are not always precise enough.

Sure.

>
>>There is no need to know things like the length of a pointer in
>>Fortran (like some people do in C).

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 11/15/2022 11:11 AM, Paul S Person wrote:
>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>> <tkoenig@netcologne.de> wrote:
>>
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>
>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>
>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>> difficult.
>>>>>>>
>>>>>>> Brave man!
>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>
>>>>>
>>>>> Pity there's not a 64 bit version of the Fortran
>>>>
>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>> may have a better experience.
>>>
>>> What is a 64-bit Fortran compiler?
>>
>> Presumably, it would be one that generates 64-bit code, using features
>> that would not work on a 32-bit computer.
>>
>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>> emulate, even if running on 64-bit hardware.
>>
>>> Typical compilers have a four-byte integer, but it is possible to
>>> select different kinds of integer via the selected_int_kind
>>> intrinsic, telling the compiler how many digits you need.
>>
>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>> 'int' is intended to be the largest value the hardware can handle as a
>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>> brethren are doing something different.
>>
>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>> today) 32 and 64 bit IEEE floats, respectively.
>>
>> That is unlikely to change. But floats are not always precise enough.
>>
>>> There is no need to know things like the length of a pointer in
>>> Fortran (like some people do in C).
>
> Changing my Fortran code to double precision for all floating point
> twenty+ years ago solved a whole lot of problems and caused new ones.
> We developed our software on a Univac 1108, a 36 bit machine, starting
> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
> precision) after roundoff.

The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
or around 7.5e-9 as epsilon.

> When we ported to the IBM 370, we lost
> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
> roundoff.

Because IBM decided to save a few gates, they used hexadecimal
float in the /360. Read "Hacker's Delight" for a scathing comment
by an IBM employee on that...

> 64 bits is a wonderful 12 to 14 digits of precision after
> roundoff.

The smallest number epsilon so that 1+epsilon > 1 in IEEE
float is around 2.2e-16, but of course you cannot reliably depend
on that for numerical calculations.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>> <tkoenig@netcologne.de> wrote:

>> Changing my Fortran code to double precision for all floating point
>> twenty+ years ago solved a whole lot of problems and caused new ones.
>> We developed our software on a Univac 1108, a 36 bit machine, starting
>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>> precision) after roundoff.
>
>The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>or around 7.5e-9 as epsilon.
>

The Burroughs B3500 had 1 to 100-digit mantissa (4 to 400 bits encoded as BCD)
and a two digit BCD exponent plus sign digits for both the exponent and mantissa.

On Thu, 17 Nov 2022 23:48:52 -0800 (PST), Hamish Laws
<hamish.laws@gmail.com> wrote:

>On Friday, November 18, 2022 at 3:59:18 AM UTC+11, Paul S Person wrote:
>>
>> C is just one step up from assembler. FORTRAN and PASCAL (and C++ and
>> others) are much more abstract. This limits what you can do in some
>> situations. It also provides additional security to avoid some
>> problems.
>
>C++ isn't necessarily any more abstract than C
>My recollection is that Bjarne's goal was that any legal C is legal C++, I'm not sure he quite got there but he got incredibly close
>
>You can make C++ more abstract than C by choosing how you code in it but it's not automatic and still has all the possible ways C has of shooting yourself in the foot.

You certainly can -- but Those Who Are Serious About C++ As An
Object-Oriented Language will go into piranha mode on you.

>> But a really inventive programmer can muck things up in /any/
>> language.
>
>No arguments there
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Fri, 18 Nov 2022 23:45:04 -0600, Lynn McGuire
<lynnmcguire5@gmail.com> wrote:

>On 11/17/2022 10:59 AM, Paul S Person wrote:
>> On Wed, 16 Nov 2022 08:51:08 -0800 (PST), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>> On Monday, November 14, 2022 at 9:44:43 AM UTC-7, Paul S Person wrote:
>>>
>>>> Yes, for the most part, and it is very convenient to be able to use
>>>> 0x00 as a stopping-point to prevent overruns.
>>>
>>> And here I thought that C strings were the primary *cause* of all the
>>> buffer overflow vulnerabilities that we encounter in software.
>>>
>>> If, instead, strings are Pascal strings, or FORTRAN character variables,
>>> it's simply not permitted, ever, to access locations past the end of a
>>> string.
>>>
>>> With a C string, though, just accidentally overwrite that 0x00 at the
>>> end, and pass the string to a subroutine, and it could keep going
>>> past the end to almost anywhere! (Of course, programmers coming
>>>from Pascal and FORTRAN who don't realize how careful they must
>>> be in C also help matters.)
>>
>> I said it was a convenience.
>>
>> I never said it was perfectly safe.
>>
>> My last buffer overrun was caused by taking it for granted that
>> certain buffers were null-terminated when, in fact, they were not.
>> Replacing while() with for() and using the known length of the text
>> fixed that right up.
>>
>> C is just one step up from assembler. FORTRAN and PASCAL (and C++ and
>> others) are much more abstract. This limits what you can do in some
>> situations. It also provides additional security to avoid some
>> problems.
>>
>> But a really inventive programmer can muck things up in /any/
>> language.
>
>My C++ code is probably more like C with Classes than real C++ nowadays.
> And yes, a real programmer can write Fortran in any language.

I've never used it, but C with Classes as I understand it to be would
probably be sufficient for a lot of programs written in C++.

Sets of subclasses instead of unions -- my mouth waters.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

<snip long Y2K related programming discussion>

I think yesterday's (Friday's) XKCD comic is relevant.
https://xkcd.com/2700/ The mouse over text is "My password is just
every Unicode codepoint concatenated into a single UTF-8 string." :P

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

On 20/11/2022 02:44, Thomas Koenig wrote:
> Paul S Person <psperson@old.netcom.invalid> schrieb:
>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>> <tkoenig@netcologne.de> wrote:
>>
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>
>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>
>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>> difficult.
>>>>>>>
>>>>>>> Brave man!
>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>
>>>>>
>>>>> Pity there's not a 64 bit version of the Fortran
>>>>
>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>> may have a better experience.
>>>
>>> What is a 64-bit Fortran compiler?
>>
>> Presumably, it would be one that generates 64-bit code, using features
>> that would not work on a 32-bit computer.
>
> And with well-written, standard-conforming code, it does not matter.
>
>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>> emulate, even if running on 64-bit hardware.
>
> Not visible from a user program, except for speed.
>
>>
>>> Typical compilers have a four-byte integer, but it is possible to
>>> select different kinds of integer via the selected_int_kind
>>> intrinsic, telling the compiler how many digits you need.
>>
>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>> 'int' is intended to be the largest value the hardware can handle as a
>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>> brethren are doing something different.
>
> Yes indeed. The standard is now i32lp64, 32-bit ints and 64-bit longs
> and pointers.
>
Aaaand you don't program Winderrs systems, do you?

IL32P64.

Sigh, life was so much easier on the Alpha, twenty-five or more years
ago, ILP64 was so simple. :-)

Cheers,
Gary B-)

On 11/19/2022 9:50 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>> <tkoenig@netcologne.de> wrote:
>>>
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>
>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>> difficult.
>>>>>>>>
>>>>>>>> Brave man!
>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>
>>>>>>
>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>
>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>> may have a better experience.
>>>>
>>>> What is a 64-bit Fortran compiler?
>>>
>>> Presumably, it would be one that generates 64-bit code, using features
>>> that would not work on a 32-bit computer.
>>>
>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>> emulate, even if running on 64-bit hardware.
>>>
>>>> Typical compilers have a four-byte integer, but it is possible to
>>>> select different kinds of integer via the selected_int_kind
>>>> intrinsic, telling the compiler how many digits you need.
>>>
>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>> 'int' is intended to be the largest value the hardware can handle as a
>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>> brethren are doing something different.
>>>
>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>
>>> That is unlikely to change. But floats are not always precise enough.
>>>
>>>> There is no need to know things like the length of a pointer in
>>>> Fortran (like some people do in C).
>>
>> Changing my Fortran code to double precision for all floating point
>> twenty+ years ago solved a whole lot of problems and caused new ones.
>> We developed our software on a Univac 1108, a 36 bit machine, starting
>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>> precision) after roundoff.
>
> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
> or around 7.5e-9 as epsilon.
>
>> When we ported to the IBM 370, we lost
>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>> roundoff.
>
> Because IBM decided to save a few gates, they used hexadecimal
> float in the /360. Read "Hacker's Delight" for a scathing comment
> by an IBM employee on that...
>
>> 64 bits is a wonderful 12 to 14 digits of precision after
>> roundoff.
>
> The smallest number epsilon so that 1+epsilon > 1 in IEEE
> float is around 2.2e-16, but of course you cannot reliably depend
> on that for numerical calculations.

Roundoff sucks.

Lynn

On 11/19/2022 10:13 AM, Scott Lurndal wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>> <tkoenig@netcologne.de> wrote:
>
>>> Changing my Fortran code to double precision for all floating point
>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>> precision) after roundoff.
>>
>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>> or around 7.5e-9 as epsilon.
>>
>
> The Burroughs B3500 had 1 to 100-digit mantissa (4 to 400 bits encoded as BCD)
> and a two digit BCD exponent plus sign digits for both the exponent and mantissa.

We never ported to the Burroughs platform.

Lynn

In article <tkvdvc$3blge$1@newsreader4.netcologne.de>,
Thomas Koenig <tkoenig@netcologne.de> wrote:
>Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>> <lynnmc...@gmail.com> wrote:
>>>>>
>>>>> <snippo discussion of basic physics terminology>
>>>>>
>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>> difficult.
>>>>>
>>>>> Brave man!
>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>
>>>
>>> Pity there's not a 64 bit version of the Fortran
>>
>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>> may have a better experience.
>
>What is a 64-bit Fortran compiler?
>
>Typical compilers have a four-byte integer, but it is possible to
>select different kinds of integer via the selected_int_kind
>intrinsic, telling the compiler how many digits you need.
>
>For REAL and DOUBLE PRECISION, those are (on relevant architectures
>today) 32 and 64 bit IEEE floats, respectively.
>
>There is no need to know things like the length of a pointer in
>Fortran (like some people do in C).

(Hal Heydt)
The FORTRAN IID compiler on the IBM 1620 had a compiler directive
called the "F and K statement" that allowed on to specify to the
length in digits for fixed point ("K") variables, minimum 2, and
floating point ("F") variables, minimum 4, with 2 for the
exponent and the rest for the mantissa. I don't recall, off
hand, the maximum permitted values.

Gary R. Schmidt <grschmidt@acm.org> schrieb:
> On 20/11/2022 02:44, Thomas Koenig wrote:
>> Paul S Person <psperson@old.netcom.invalid> schrieb:
>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>> <tkoenig@netcologne.de> wrote:
>>>
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>
>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>> difficult.
>>>>>>>>
>>>>>>>> Brave man!
>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>
>>>>>>
>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>
>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>> may have a better experience.
>>>>
>>>> What is a 64-bit Fortran compiler?
>>>
>>> Presumably, it would be one that generates 64-bit code, using features
>>> that would not work on a 32-bit computer.
>>
>> And with well-written, standard-conforming code, it does not matter.
>>
>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>> emulate, even if running on 64-bit hardware.
>>
>> Not visible from a user program, except for speed.
>>
>>>
>>>> Typical compilers have a four-byte integer, but it is possible to
>>>> select different kinds of integer via the selected_int_kind
>>>> intrinsic, telling the compiler how many digits you need.
>>>
>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>> 'int' is intended to be the largest value the hardware can handle as a
>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>> brethren are doing something different.
>>
>> Yes indeed. The standard is now i32lp64, 32-bit ints and 64-bit longs
>> and pointers.
>>
> Aaaand you don't program Winderrs systems, do you?
>
> IL32P64.

You're right, I don't, my C stuff is UNIX only. And for Fortran,
it doesn't matter.

> Sigh, life was so much easier on the Alpha, twenty-five or more years
> ago, ILP64 was so simple. :-)

Sort of negates the need for long, though.

Also must have made porting to platforms with 32-bit integers hard.

On 20/11/2022 21:04, Thomas Koenig wrote:
> Gary R. Schmidt <grschmidt@acm.org> schrieb:
>> On 20/11/2022 02:44, Thomas Koenig wrote:
>>> Paul S Person <psperson@old.netcom.invalid> schrieb:
>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>> <tkoenig@netcologne.de> wrote:
>>>>
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>
>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>> difficult.
>>>>>>>>>
>>>>>>>>> Brave man!
>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>
>>>>>>>
>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>
>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>> may have a better experience.
>>>>>
>>>>> What is a 64-bit Fortran compiler?
>>>>
>>>> Presumably, it would be one that generates 64-bit code, using features
>>>> that would not work on a 32-bit computer.
>>>
>>> And with well-written, standard-conforming code, it does not matter.
>>>
>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>> emulate, even if running on 64-bit hardware.
>>>
>>> Not visible from a user program, except for speed.
>>>
>>>>
>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>> select different kinds of integer via the selected_int_kind
>>>>> intrinsic, telling the compiler how many digits you need.
>>>>
>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>> brethren are doing something different.
>>>
>>> Yes indeed. The standard is now i32lp64, 32-bit ints and 64-bit longs
>>> and pointers.
>>>
>> Aaaand you don't program Winderrs systems, do you?
>>
>> IL32P64.
>
> You're right, I don't, my C stuff is UNIX only. And for Fortran,
> it doesn't matter.
>
>> Sigh, life was so much easier on the Alpha, twenty-five or more years
>> ago, ILP64 was so simple. :-)
>
> Sort of negates the need for long, though.
>
> Also must have made porting to platforms with 32-bit integers hard.

Long, long, long ago I inherited a habit of not using built-in types
directly, but using #define, and later, typedef, to specify exactly what
was wanted from those types.

Life was much easier.

Cheers,
Gary B-)

On Sunday, November 20, 2022 at 2:44:50 AM UTC+11, Thomas Koenig wrote:
> Paul S Person <pspe...@old.netcom.invalid> schrieb:
> > On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
> ><tko...@netcologne.de> wrote:
> >
> >>Lynn McGuire <lynnmc...@gmail.com> schrieb:
> >>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
> >>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
> >>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
> >>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
> >>>>>> <lynnmc...@gmail.com> wrote:
> >>>>>>
> >>>>>> <snippo discussion of basic physics terminology>
> >>>>>>
> >>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
> >>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
> >>>>>>> Fortran character strings to C strings or C++ STL strings are very
> >>>>>>> difficult.
> >>>>>>
> >>>>>> Brave man!
> >>>>> I've got to have a 64 bit version of my calculation engine and soon. My
> >>>>> customers are clamoring for it with the new 64 bit version of Excel.
> >>>>>
> >>>>
> >>>> Pity there's not a 64 bit version of the Fortran
> >>>
> >>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
> >>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
> >>> may have a better experience.
> >>
> >>What is a 64-bit Fortran compiler?
> >
> > Presumably, it would be one that generates 64-bit code, using features
> > that would not work on a 32-bit computer.
>
> And with well-written, standard-conforming code, it does not matter.

Try interacting with 64 bit applications using 32 bit code in windows

On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
<lynnmcguire5@gmail.com> wrote:

>On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>> <tkoenig@netcologne.de> wrote:
>>>>
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>
>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>> difficult.
>>>>>>>>>
>>>>>>>>> Brave man!
>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>
>>>>>>>
>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>
>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>> may have a better experience.
>>>>>
>>>>> What is a 64-bit Fortran compiler?
>>>>
>>>> Presumably, it would be one that generates 64-bit code, using features
>>>> that would not work on a 32-bit computer.
>>>>
>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>> emulate, even if running on 64-bit hardware.
>>>>
>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>> select different kinds of integer via the selected_int_kind
>>>>> intrinsic, telling the compiler how many digits you need.
>>>>
>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>> brethren are doing something different.
>>>>
>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>
>>>> That is unlikely to change. But floats are not always precise enough.
>>>>
>>>>> There is no need to know things like the length of a pointer in
>>>>> Fortran (like some people do in C).
>>>
>>> Changing my Fortran code to double precision for all floating point
>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>> precision) after roundoff.
>>
>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>> or around 7.5e-9 as epsilon.
>>
>>> When we ported to the IBM 370, we lost
>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>> roundoff.
>>
>> Because IBM decided to save a few gates, they used hexadecimal
>> float in the /360. Read "Hacker's Delight" for a scathing comment
>> by an IBM employee on that...
>>
>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>> roundoff.
>>
>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>> float is around 2.2e-16, but of course you cannot reliably depend
>> on that for numerical calculations.
>
>Roundoff sucks.

Which is why God gave us Integers.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Sat, 19 Nov 2022 10:03:03 -0800, Dimensional Traveler
<dtravel@sonic.net> wrote:

><snip long Y2K related programming discussion>
>
>I think yesterday's (Friday's) XKCD comic is relevant.
>https://xkcd.com/2700/ The mouse over text is "My password is just
>every Unicode codepoint concatenated into a single UTF-8 string." :P

That's some password!
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Saturday, November 19, 2022 at 11:32:36 PM UTC-7, Hal Heydt wrote:

> The FORTRAN IID compiler on the IBM 1620 had a compiler directive
> called the "F and K statement" that allowed on to specify to the
> length in digits for fixed point ("K") variables, minimum 2, and
> floating point ("F") variables, minimum 4, with 2 for the
> exponent and the rest for the mantissa. I don't recall, off
> hand, the maximum permitted values.

Having collected a number of manuals from Bitsavers, I found the
manual for 1620 Fortran II, and it described the Source Program Control
Card to match your description:

*26104

would mean that the floating-point precision was 26 digits, the fixed point
precision was 10 digits (the maximums for each) and the 4 at the end
indicated the object code was to be generated to run on a machine with
40,000 core storage locations (of two decimal digits each, IIRC).

John Savard

On Sat, 19 Nov 2022 08:44:06 -0800, Paul S Person
<psperson@old.netcom.invalid> wrote:

>>You can make C++ more abstract than C by choosing how you code in it but it's not automatic and still has all the possible ways C has of shooting yourself in the foot.
>
>You certainly can -- but Those Who Are Serious About C++ As An
>Object-Oriented Language will go into piranha mode on you.

But let's face it - those are the C people who outdo Scientologists in
their devotion to their holy texts (compilers)

On 11/20/2022 11:08 AM, Paul S Person wrote:
> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
> <lynnmcguire5@gmail.com> wrote:
>
>> On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>> <tkoenig@netcologne.de> wrote:
>>>>>
>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>
>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>> difficult.
>>>>>>>>>>
>>>>>>>>>> Brave man!
>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>
>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>> may have a better experience.
>>>>>>
>>>>>> What is a 64-bit Fortran compiler?
>>>>>
>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>> that would not work on a 32-bit computer.
>>>>>
>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>> emulate, even if running on 64-bit hardware.
>>>>>
>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>> select different kinds of integer via the selected_int_kind
>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>
>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>> brethren are doing something different.
>>>>>
>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>
>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>
>>>>>> There is no need to know things like the length of a pointer in
>>>>>> Fortran (like some people do in C).
>>>>
>>>> Changing my Fortran code to double precision for all floating point
>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>> precision) after roundoff.
>>>
>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>> or around 7.5e-9 as epsilon.
>>>
>>>> When we ported to the IBM 370, we lost
>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>> roundoff.
>>>
>>> Because IBM decided to save a few gates, they used hexadecimal
>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>> by an IBM employee on that...
>>>
>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>> roundoff.
>>>
>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>> float is around 2.2e-16, but of course you cannot reliably depend
>>> on that for numerical calculations.
>>
>> Roundoff sucks.
>
> Which is why God gave us Integers.

I shudder to think of replacing my double precision variables with
integers. I have my major stops set at 1.0e100 and 1.0e-100 at the moment.

Lynn

On Mon, 21 Nov 2022 14:17:26 -0600, Lynn McGuire
<lynnmcguire5@gmail.com> wrote:

>On 11/20/2022 11:08 AM, Paul S Person wrote:
>> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
>> <lynnmcguire5@gmail.com> wrote:
>>
>>> On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>>> <tkoenig@netcologne.de> wrote:
>>>>>>
>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>>
>>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>>> difficult.
>>>>>>>>>>>
>>>>>>>>>>> Brave man!
>>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>>
>>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>>> may have a better experience.
>>>>>>>
>>>>>>> What is a 64-bit Fortran compiler?
>>>>>>
>>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>>> that would not work on a 32-bit computer.
>>>>>>
>>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>>> emulate, even if running on 64-bit hardware.
>>>>>>
>>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>>> select different kinds of integer via the selected_int_kind
>>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>>
>>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>>> brethren are doing something different.
>>>>>>
>>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>>
>>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>>
>>>>>>> There is no need to know things like the length of a pointer in
>>>>>>> Fortran (like some people do in C).
>>>>>
>>>>> Changing my Fortran code to double precision for all floating point
>>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>>> precision) after roundoff.
>>>>
>>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>>> or around 7.5e-9 as epsilon.
>>>>
>>>>> When we ported to the IBM 370, we lost
>>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>>> roundoff.
>>>>
>>>> Because IBM decided to save a few gates, they used hexadecimal
>>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>>> by an IBM employee on that...
>>>>
>>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>>> roundoff.
>>>>
>>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>>> float is around 2.2e-16, but of course you cannot reliably depend
>>>> on that for numerical calculations.
>>>
>>> Roundoff sucks.
>>
>> Which is why God gave us Integers.
>
>I shudder to think of replacing my double precision variables with
>integers. I have my major stops set at 1.0e100 and 1.0e-100 at the moment.

Well, that's why such things exist: so you can at least approximate
really large values.

And, anyway, if they worked in FORTRAN, they should work just as well
in C++, particularly if they comply with the standard and are using
the same number of bits.

However, if you are running an Anti-missile battery, you might want to
advise the user to reboot periodically so the accumulated errors don't
cause a failure to hit the incoming target. I believe the Israeli's
learned that the hard way at one point.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On 11/22/2022 11:13 AM, Paul S Person wrote:
> On Mon, 21 Nov 2022 14:17:26 -0600, Lynn McGuire
> <lynnmcguire5@gmail.com> wrote:
>
>> On 11/20/2022 11:08 AM, Paul S Person wrote:
>>> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
>>> <lynnmcguire5@gmail.com> wrote:
>>>
>>>> On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>>>> <tkoenig@netcologne.de> wrote:
>>>>>>>
>>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>>>
>>>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>>>> difficult.
>>>>>>>>>>>>
>>>>>>>>>>>> Brave man!
>>>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>>>
>>>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>>>> may have a better experience.
>>>>>>>>
>>>>>>>> What is a 64-bit Fortran compiler?
>>>>>>>
>>>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>>>> that would not work on a 32-bit computer.
>>>>>>>
>>>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>>>> emulate, even if running on 64-bit hardware.
>>>>>>>
>>>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>>>> select different kinds of integer via the selected_int_kind
>>>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>>>
>>>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>>>> brethren are doing something different.
>>>>>>>
>>>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>>>
>>>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>>>
>>>>>>>> There is no need to know things like the length of a pointer in
>>>>>>>> Fortran (like some people do in C).
>>>>>>
>>>>>> Changing my Fortran code to double precision for all floating point
>>>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>>>> precision) after roundoff.
>>>>>
>>>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>>>> or around 7.5e-9 as epsilon.
>>>>>
>>>>>> When we ported to the IBM 370, we lost
>>>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>>>> roundoff.
>>>>>
>>>>> Because IBM decided to save a few gates, they used hexadecimal
>>>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>>>> by an IBM employee on that...
>>>>>
>>>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>>>> roundoff.
>>>>>
>>>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>>>> float is around 2.2e-16, but of course you cannot reliably depend
>>>>> on that for numerical calculations.
>>>>
>>>> Roundoff sucks.
>>>
>>> Which is why God gave us Integers.
>>
>> I shudder to think of replacing my double precision variables with
>> integers. I have my major stops set at 1.0e100 and 1.0e-100 at the moment.
>
> Well, that's why such things exist: so you can at least approximate
> really large values.
>
> And, anyway, if they worked in FORTRAN, they should work just as well
> in C++, particularly if they comply with the standard and are using
> the same number of bits.
>
> However, if you are running an Anti-missile battery, you might want to
> advise the user to reboot periodically so the accumulated errors don't
> cause a failure to hit the incoming target. I believe the Israeli's
> learned that the hard way at one point.

The closest that I can get to that is that my software can simulate
mustard gas reactors to a very high degree of accuracy.

Lynn

Paul S Person <psperson@old.netcom.invalid> schrieb:
> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
><lynnmcguire5@gmail.com> wrote:
>
>>On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>> <tkoenig@netcologne.de> wrote:
>>>>>
>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>
>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>> difficult.
>>>>>>>>>>
>>>>>>>>>> Brave man!
>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>
>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>> may have a better experience.
>>>>>>
>>>>>> What is a 64-bit Fortran compiler?
>>>>>
>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>> that would not work on a 32-bit computer.
>>>>>
>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>> emulate, even if running on 64-bit hardware.
>>>>>
>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>> select different kinds of integer via the selected_int_kind
>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>
>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>> brethren are doing something different.
>>>>>
>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>
>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>
>>>>>> There is no need to know things like the length of a pointer in
>>>>>> Fortran (like some people do in C).
>>>>
>>>> Changing my Fortran code to double precision for all floating point
>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>> precision) after roundoff.
>>>
>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>> or around 7.5e-9 as epsilon.
>>>
>>>> When we ported to the IBM 370, we lost
>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>> roundoff.
>>>
>>> Because IBM decided to save a few gates, they used hexadecimal
>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>> by an IBM employee on that...
>>>
>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>> roundoff.
>>>
>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>> float is around 2.2e-16, but of course you cannot reliably depend
>>> on that for numerical calculations.
>>
>>Roundoff sucks.
>
> Which is why God gave us Integers.

So you have to keep track of the scales yourselves?

One of Backus' contributions to computers, before the FORTRAN
compiler, was an interpretative system called Speedcoding.
It emulated floating point numbers on the IBM 701, was dog-slow
(a factor of 10-20 vs. native machine code) and a big boost
to productivity because programs could be written and debugged
much faster.

The 704 then had hardware floating point, and the rest is history.

On 22/11/2022 16.36, Thomas Koenig wrote:
> Paul S Person <psperson@old.netcom.invalid> schrieb:
>> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
>> <lynnmcguire5@gmail.com> wrote:
>>
>>> On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>>> <tkoenig@netcologne.de> wrote:
>>>>>>
>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>>
>>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>>> difficult.
>>>>>>>>>>>
>>>>>>>>>>> Brave man!
>>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>>
>>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>>> may have a better experience.
>>>>>>>
>>>>>>> What is a 64-bit Fortran compiler?
>>>>>>
>>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>>> that would not work on a 32-bit computer.
>>>>>>
>>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>>> emulate, even if running on 64-bit hardware.
>>>>>>
>>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>>> select different kinds of integer via the selected_int_kind
>>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>>
>>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>>> brethren are doing something different.
>>>>>>
>>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>>
>>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>>
>>>>>>> There is no need to know things like the length of a pointer in
>>>>>>> Fortran (like some people do in C).
>>>>>
>>>>> Changing my Fortran code to double precision for all floating point
>>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>>> precision) after roundoff.
>>>>
>>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>>> or around 7.5e-9 as epsilon.
>>>>
>>>>> When we ported to the IBM 370, we lost
>>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>>> roundoff.
>>>>
>>>> Because IBM decided to save a few gates, they used hexadecimal
>>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>>> by an IBM employee on that...
>>>>
>>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>>> roundoff.
>>>>
>>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>>> float is around 2.2e-16, but of course you cannot reliably depend
>>>> on that for numerical calculations.
>>>
>>> Roundoff sucks.
>>
>> Which is why God gave us Integers.
>
> So you have to keep track of the scales yourselves?

My first job that was explicitly coding was on a 16-bit minicomputer.
We were doing real-time control of (utility-scale) generation. All
of the power values were represented as scaled integers, so that
(e.g.) 436.1 MW would be represented internally as "4361".

We couldn't scale by two decimal places because 16 bits of one's
complement couldn't handle that.

--
Michael F. Stemper
What happens if you play John Cage's "4'33" at a slower tempo?

On Tue, 22 Nov 2022 22:36:39 -0000 (UTC), Thomas Koenig
<tkoenig@netcologne.de> wrote:

>Paul S Person <psperson@old.netcom.invalid> schrieb:
>> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
>><lynnmcguire5@gmail.com> wrote:
>>
>>>On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>>> <tkoenig@netcologne.de> wrote:
>>>>>>
>>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>>
>>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>>> difficult.
>>>>>>>>>>>
>>>>>>>>>>> Brave man!
>>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>>
>>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>>> may have a better experience.
>>>>>>>
>>>>>>> What is a 64-bit Fortran compiler?
>>>>>>
>>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>>> that would not work on a 32-bit computer.
>>>>>>
>>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>>> emulate, even if running on 64-bit hardware.
>>>>>>
>>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>>> select different kinds of integer via the selected_int_kind
>>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>>
>>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>>> brethren are doing something different.
>>>>>>
>>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>>
>>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>>
>>>>>>> There is no need to know things like the length of a pointer in
>>>>>>> Fortran (like some people do in C).
>>>>>
>>>>> Changing my Fortran code to double precision for all floating point
>>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>>> precision) after roundoff.
>>>>
>>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>>> or around 7.5e-9 as epsilon.
>>>>
>>>>> When we ported to the IBM 370, we lost
>>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>>> roundoff.
>>>>
>>>> Because IBM decided to save a few gates, they used hexadecimal
>>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>>> by an IBM employee on that...
>>>>
>>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>>> roundoff.
>>>>
>>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>>> float is around 2.2e-16, but of course you cannot reliably depend
>>>> on that for numerical calculations.
>>>
>>>Roundoff sucks.
>>
>> Which is why God gave us Integers.
>
>So you have to keep track of the scales yourselves?

That is a downside if you are using computer integers to represent
fixed-point values.

OTOH, I expect my bank statements to be accurate to the penny. No room
for error, no excuses.

>One of Backus' contributions to computers, before the FORTRAN
>compiler, was an interpretative system called Speedcoding.
>It emulated floating point numbers on the IBM 701, was dog-slow
>(a factor of 10-20 vs. native machine code) and a big boost
>to productivity because programs could be written and debugged
>much faster.
>
>The 704 then had hardware floating point, and the rest is history.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Wednesday, November 23, 2022 at 11:51:03 AM UTC-5, Paul S Person wrote:
> On Tue, 22 Nov 2022 22:36:39 -0000 (UTC), Thomas Koenig
> <tko...@netcologne.de> wrote:
>
> >Paul S Person <pspe...@old.netcom.invalid> schrieb:
> >> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
> >><lynnmc...@gmail.com> wrote:
> >>
> >>>On 11/19/2022 9:50 AM, Thomas Koenig wrote:
> >>>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
> >>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
> >>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
> >>>>>> <tko...@netcologne.de> wrote:
> >>>>>>
> >>>>>>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
> >>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
> >>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
> >>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
> >>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
> >>>>>>>>>>> <lynnmc...@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> <snippo discussion of basic physics terminology>
> >>>>>>>>>>>
> >>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
> >>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
> >>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
> >>>>>>>>>>>> difficult.
> >>>>>>>>>>>
> >>>>>>>>>>> Brave man!
> >>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
> >>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Pity there's not a 64 bit version of the Fortran
> >>>>>>>>
> >>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
> >>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
> >>>>>>>> may have a better experience.
> >>>>>>>
> >>>>>>> What is a 64-bit Fortran compiler?
> >>>>>>
> >>>>>> Presumably, it would be one that generates 64-bit code, using features
> >>>>>> that would not work on a 32-bit computer.
> >>>>>>
> >>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
> >>>>>> emulate, even if running on 64-bit hardware.
> >>>>>>
> >>>>>>> Typical compilers have a four-byte integer, but it is possible to
> >>>>>>> select different kinds of integer via the selected_int_kind
> >>>>>>> intrinsic, telling the compiler how many digits you need.
> >>>>>>
> >>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
> >>>>>> 'int' is intended to be the largest value the hardware can handle as a
> >>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
> >>>>>> brethren are doing something different.
> >>>>>>
> >>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
> >>>>>>> today) 32 and 64 bit IEEE floats, respectively.
> >>>>>>
> >>>>>> That is unlikely to change. But floats are not always precise enough.
> >>>>>>
> >>>>>>> There is no need to know things like the length of a pointer in
> >>>>>>> Fortran (like some people do in C).
> >>>>>
> >>>>> Changing my Fortran code to double precision for all floating point
> >>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
> >>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
> >>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
> >>>>> precision) after roundoff.
> >>>>
> >>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
> >>>> or around 7.5e-9 as epsilon.
> >>>>
> >>>>> When we ported to the IBM 370, we lost
> >>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
> >>>>> roundoff.
> >>>>
> >>>> Because IBM decided to save a few gates, they used hexadecimal
> >>>> float in the /360. Read "Hacker's Delight" for a scathing comment
> >>>> by an IBM employee on that...
> >>>>
> >>>>> 64 bits is a wonderful 12 to 14 digits of precision after
> >>>>> roundoff.
> >>>>
> >>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
> >>>> float is around 2.2e-16, but of course you cannot reliably depend
> >>>> on that for numerical calculations.
> >>>
> >>>Roundoff sucks.
> >>
> >> Which is why God gave us Integers.
> >
> >So you have to keep track of the scales yourselves?
> That is a downside if you are using computer integers to represent
> fixed-point values.
>
> OTOH, I expect my bank statements to be accurate to the penny. No room
> for error, no excuses.

You're probably safe. Even back in the late 80s, when I worked at a major
Wall Street bank, math involving money was done with 96 bit integers,
using pennies as the unit.

Pt

On 11/23/2022 8:34 PM, pete...@gmail.com wrote:
> On Wednesday, November 23, 2022 at 11:51:03 AM UTC-5, Paul S Person wrote:
>> On Tue, 22 Nov 2022 22:36:39 -0000 (UTC), Thomas Koenig
>> <tko...@netcologne.de> wrote:
>>
>>> Paul S Person <pspe...@old.netcom.invalid> schrieb:
>>>> On Sat, 19 Nov 2022 22:21:15 -0600, Lynn McGuire
>>>> <lynnmc...@gmail.com> wrote:
>>>>
>>>>> On 11/19/2022 9:50 AM, Thomas Koenig wrote:
>>>>>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
>>>>>>> On 11/15/2022 11:11 AM, Paul S Person wrote:
>>>>>>>> On Tue, 15 Nov 2022 07:09:32 -0000 (UTC), Thomas Koenig
>>>>>>>> <tko...@netcologne.de> wrote:
>>>>>>>>
>>>>>>>>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
>>>>>>>>>> On 11/13/2022 5:32 AM, Hamish Laws wrote:
>>>>>>>>>>> On Sunday, November 13, 2022 at 6:50:28 AM UTC+11, Lynn McGuire wrote:
>>>>>>>>>>>> On 11/12/2022 10:44 AM, Paul S Person wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 14:35:30 -0600, Lynn McGuire
>>>>>>>>>>>>> <lynnmc...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> <snippo discussion of basic physics terminology>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am in the beginning of converting my 5,000+ subroutines / 700,000+
>>>>>>>>>>>>>> lines of F77 code to C++. I have converted 23,000 lines so far. The
>>>>>>>>>>>>>> Fortran character strings to C strings or C++ STL strings are very
>>>>>>>>>>>>>> difficult.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brave man!
>>>>>>>>>>>> I've got to have a 64 bit version of my calculation engine and soon. My
>>>>>>>>>>>> customers are clamoring for it with the new 64 bit version of Excel.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Pity there's not a 64 bit version of the Fortran
>>>>>>>>>>
>>>>>>>>>> My experience with the 64 bit Fortran compilers with my 700,000+ lines
>>>>>>>>>> of my old F77 code and my 50,000+ lines of C++ code is not good. Others
>>>>>>>>>> may have a better experience.
>>>>>>>>>
>>>>>>>>> What is a 64-bit Fortran compiler?
>>>>>>>>
>>>>>>>> Presumably, it would be one that generates 64-bit code, using features
>>>>>>>> that would not work on a 32-bit computer.
>>>>>>>>
>>>>>>>> Such as native 64-bit multiplcation. Which a 32-bit compiler can only
>>>>>>>> emulate, even if running on 64-bit hardware.
>>>>>>>>
>>>>>>>>> Typical compilers have a four-byte integer, but it is possible to
>>>>>>>>> select different kinds of integer via the selected_int_kind
>>>>>>>>> intrinsic, telling the compiler how many digits you need.
>>>>>>>>
>>>>>>>> I would expect a 64-bit C compiler to have an 8-byte 'int', since
>>>>>>>> 'int' is intended to be the largest value the hardware can handle as a
>>>>>>>> unit. But perhaps that ended with 32-bit compilers, and their 64-bit
>>>>>>>> brethren are doing something different.
>>>>>>>>
>>>>>>>>> For REAL and DOUBLE PRECISION, those are (on relevant architectures
>>>>>>>>> today) 32 and 64 bit IEEE floats, respectively.
>>>>>>>>
>>>>>>>> That is unlikely to change. But floats are not always precise enough.
>>>>>>>>
>>>>>>>>> There is no need to know things like the length of a pointer in
>>>>>>>>> Fortran (like some people do in C).
>>>>>>>
>>>>>>> Changing my Fortran code to double precision for all floating point
>>>>>>> twenty+ years ago solved a whole lot of problems and caused new ones.
>>>>>>> We developed our software on a Univac 1108, a 36 bit machine, starting
>>>>>>> back in 1965. 36 bits is 1 ppm (part per million) (6 digits of
>>>>>>> precision) after roundoff.
>>>>>>
>>>>>> The UNIVYC 1108 had a 27-bit mantissa in its floating point format,
>>>>>> or around 7.5e-9 as epsilon.
>>>>>>
>>>>>>> When we ported to the IBM 370, we lost
>>>>>>> precision down to 32 bits. 32 bits is about 1.5 ppm (5.5 digits) after
>>>>>>> roundoff.
>>>>>>
>>>>>> Because IBM decided to save a few gates, they used hexadecimal
>>>>>> float in the /360. Read "Hacker's Delight" for a scathing comment
>>>>>> by an IBM employee on that...
>>>>>>
>>>>>>> 64 bits is a wonderful 12 to 14 digits of precision after
>>>>>>> roundoff.
>>>>>>
>>>>>> The smallest number epsilon so that 1+epsilon > 1 in IEEE
>>>>>> float is around 2.2e-16, but of course you cannot reliably depend
>>>>>> on that for numerical calculations.
>>>>>
>>>>> Roundoff sucks.
>>>>
>>>> Which is why God gave us Integers.
>>>
>>> So you have to keep track of the scales yourselves?
>> That is a downside if you are using computer integers to represent
>> fixed-point values.
>>
>> OTOH, I expect my bank statements to be accurate to the penny. No room
>> for error, no excuses.
>
> You're probably safe. Even back in the late 80s, when I worked at a major
> Wall Street bank, math involving money was done with 96 bit integers,
> using pennies as the unit.
>
Reminds me of a Richard Pryor movie where he played an underpaid
programmer for some huge corporation and started transferring all those
fractions of a penny dropped from paycheck withholdings to his own
account. The big bosses realized he was the one responsible when a week
after starting it he drove to work in a megabucks supercar. :D

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.