[Info-vax] Roadmap

[Dave Froble]

On 1/6/2019 3:00 PM, John Reagan wrote:
> On Sunday, January 6, 2019 at 11:16:49 AM UTC-5, geze... at rlgsc.com wrote:
>> On Sunday, January 6, 2019 at 6:56:16 AM UTC-5, geze... at rlgsc.com wrote:
>>> On Saturday, January 5, 2019 at 9:19:06 PM UTC-5, Arne Vajhøj wrote:
>>>> On 1/5/2019 8:23 PM, Dave Froble wrote:
>>>>> On 1/5/2019 1:48 PM, John Reagan wrote:
>>>>>>         The format of the REAL_SIZE qualifier is as follows:
>>>>>>
>>>>>>            /REAL_SIZE={SINGLE}
>>>>>>                       {DOUBLE}
>>>>>>                       {GFLOAT}
>>>>>>                       {SFLOAT}
>>>>>>                       {TFLOAT}
>>>>>>                       {XFLOAT}
>>>>
>>>>>> So Dave's "OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )" which was
>>>>>> originally used to say "I want extra precision on my REALs" locks into
>>>>>> you Dfloat on Itanium.
>>>>
>>>>>> What a horrible design decision.  So people who didn't say anything on
>>>>>> Itanium, get fast Sfloat but the moment you want more precision and
>>>>>> blindly say "REAL DOUBLE", you get your extra precision (but no extra
>>>>>> range) and a performance hit.
>>>>
>>>>> Maybe the D_FLOAT isn't so bad, if you're not doing a lot of work with it.
>>>>
>>>> Basic is probably not a favorite language for number crunchers, so
>>>> most likely the practical impact is minimal.
>>>>
>>>> It is possible though to create an example showing a difference:
>>>>
>>>> $ type dbl.bas
>>>>           option type = explicit
>>>>           declare long constant n = 10000000
>>>>           external long function pas$clock2
>>>>           dim real x(n)
>>>>           declare long j, i, t1, t2
>>>>           t1 = pas$clock2()
>>>>           for j = 1 to 10
>>>>             x(1) = 1.0
>>>>             for i = 2 to n
>>>>               x(i) = (x(i - 1) * 2 + 2) / 2
>>>>             next i
>>>>           next j
>>>>           t2 = pas$clock2()
>>>>           print using "#### (##########.#)"; (t2 - t1); x(n)
>>>>           end
>>>> $ bas/real=double dbl
>>>> $ lin dbl
>>>> $ r dbl
>>>> 5810 (  10000000.0)
>>>> $ bas/real=tfloat dbl
>>>> $ lin dbl
>>>> $ r dbl
>>>> 3000 (  10000000.0)
>>>>
>>>> (forgive me for any basic Basic blunders - it is not a language
>>>> I am using)
>>>>
>>>> Arne
>>>
>>> Arne,
>>>
>>> BASIC is still popular in some quarters, where it is used for serious systems. I have had more than a few clients who meet this description.
>>>
>>> In many ways, interoperability of one form or another is the most important use of the different formats. Some have historical data files. Some have mixed-architecture OpenVMS clusters. Others exchange binary data with other systems, on the same or different machine, of the same or different organization.
>>>
>>> OpenVMS standards also mean that these differences can arise due to different parts of the same software image being written in different languages.
>>>
>>> It is thus not a debate of "which is better", but a debate of "which is needed". This situation argues for provision of both defaults (e.g., compiler switches, implicit declarations) and explicit data types, as well as the obvious cross-type conversions.
>>>
>>> - Bob Gezelter, http://www.rlgsc.com
>>
>> A clarification:
>>
>> C/C++ has had long-time challenges with the use of keywords such as "long", "double", etc.
>>
>> In the case of floating point, perhaps all (repeat ALL) OpenVMS compilers should support a non-standard keyword "IEEE754" as an adjunct to REAL and DOUBLE. A "C"-ish example would be:
>>
>>            IEEE754 float X;
>>            IEEE754 double Y;
>>
>> in FORTRAN:
>>
>>            IEEE754 REAL*4 X;
>>            IEEE754 REAL*8 Y;
>>
>> This would allow the clarity in documenting mixed representation programs, e.g., programs which read/write one format while working internally in another. Often, such situations are, as I have noted elsewhere, not a voluntary choice. Historical data exists, libraries expect certain formats, etc.
>>
>> Doing this consistently across multiple compilers is, I admit, a chore. However, it is also a problem best addressed in a consistent manner, than ad hoc for each different compiler.
>>
>> My apologies to John for adding to his work queue.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> Already done years ago for Pascal.
>
> REAL - single-precision, compiler choice for format
> DOUBLE - double-precision, compiler choice for format
> QUADRUPLE - quad-preicsion, compiler choice for format
> F_FLOAT
> S_FLOAT (not on VAX)
> D_FLOAT
> G_FLOAT
> T_FLOAT (not on VAX)
> X_FLOAT (not on VAX)
> H_FLOAT (VAX only)
>
> and matching %?_FLOAT directives to give an explicit format to floating constants.  It lets you use %F_FLOAT to call LIB$WAIT on OpenVMS Itanium while still using the default of S_FLOAT everywhere else.
>
> And Pascal allows both VAX and IEEE formats to be used in the same routine but you can't let them touch. :)
>

This issue has two main parts.

1) data in memory
2) data stored in files

The types of floating point numbers supported on different HW might 
cause one to pick the most efficient for calculations, and that has 
changed, as HW has changed.  One can determine if any performance hit is 
meaningful, and plan accordingly.

As for data stored in files, it's a different problem.  The issue is 
whether one can accurately retrieve data.

One solution might be some type of identifier for each piece of floating 
point data, which would be respected by whatever code moved data from 
file to memory, and back.  I'd expect some type of performance hit from 
such a scheme.

Pick only one of two, performance or accuracy ....

:-)

Perhaps the /REAL_SIZE should be /REAL_TYPE ?


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486