Re: huge number calculator and library
From: Warren Simmons (wsimmons5_at_optonline.net)
Date: 08/01/04
- Next message: docdwarf_at_panix.com: "Re: Layout Hell-o"
- Previous message: William M. Klein: "Non-DISPLAY numeric data in files"
- In reply to: Robert Wagner: "Re: huge number calculator and library"
- Next in thread: SkippyPB: "Re: huge number calculator and library"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 01 Aug 2004 02:03:46 GMT
Regarding size, the problem is an old one. IBM's pre 360 systems had 36
bit words,
and 72 bit double precision. In meetings I attended hosted by IBM at the
time of the
release of the 360 the point was made that after a large review of user
needs, that
big a word was not needed.
I know that we used Matrix software to do what we called the circulation
of variances.
Steve Wright was the author of the software, and because of the slowness
of the system
as compared to the size of the problems, some customers ran that package
for days, or
perhaps weeks. There was a stop, and continue feature in the software.
That application
for us did not need large numbers. Yet our product code was in the
realm of 20 characters
in length. It was a collection of groups and sub groups of product.
At that time, we also had a research lab that used analog computers. We
were into
machine shop control, simulations, and among other things bridge design.
There was
a whole group that tried to keep up with the operations needs, and not
just book
keeping.
While this may not be exactly on topic, I remember that the air frame
industry's needs
were such that FORTRAN may still be their tool for plane design. Through
CODASYL
a data base extension was developed for FORTRAN.
Some of our plants had computers dedicated to controlling the making of
steel.
Now days, the system is down to a very few people and few computers.
However,
size of numbers in floating point did NOT seem to be an issue with us,
and IBM at
the 360 announcement in Huston assured us that we would not loose
precision with
the new shorter word size.
I don't believe there was a problem at the David Taylor Model Basin or
we would
have heard about it. Yet, with todays travel to the stars, and the size
of some
data bases today anything is possible.
Warren Simmons
Robert Wagner wrote:
>"William M. Klein" <wmklein@nospam.netcom.com> wrote:
>
>
>
>>to: C.L.C. (with a CC)
>>
>>When the Standards committees were extending the required numeric size from 18
>>digits to 31 digits a question arose as to whether or not anyone KNEW of any
>>existing "real-world" applications that actually needed 31-digit numbers. J4
>>and WG4 went with 31-digits as that is what the (a?) SQL Standard requires (as
>>
>>
>I
>
>
>>recall). However, I don't think I ever heard from any users that they really
>>needed these larger fields.
>>
>>
>
>I have encountered realistic problems that required more than 18 digits. Whether
>they required more than 31 digits, I cannot recall. The variables in question
>were intermediate in solving Linear Regression, Roots of a Polynomial, etc.
>Businesses use these, but the managers you polled were probably 10 years out of
>touch with technical details. They were thinking of widgets and balance sheets
>rather than mathematical intermediates.
>
>The demo was an intellectual exercise.
>
>
>
>>I am NOT saying that RW's example code is a problem (and I haven't studied it
>>
>>
>in
>
>
>>detail). However, I am curious if any participants in comp.lang.cobol have
>>found serious business needs for greater than 31-digit numbers - and if so for
>>what types of applications?
>>
>>
>
>I would turn it around to ask whether anyone thinks there should be a limit. If
>I say PIC 9(10000), why should the compiler raise an objection? It's my
>computer. If I'm wasting time foolishly, its not the compiler's job to point
>that out.
>
>
>
>>P.S. I am a little confused by the comment:
>>
>>
>>
>>>* Note that everything is relative to the size of 'huge' below.
>>>* The program would read better if I could equate
>>>* 'mid' to 'length of huge / 2'. I couldn't find a way in Cobol 85.
>>>
>>>
>>This particular code is a VERY odd (to me) mixture of '85 Standard, '02
>>Standard, and Micro Focus extension syntax, e.g.
>>
>>ENTRY - is an extension
>>
>>
>
>It wouldn't be callable by outsiders if I'd used nested programs.
>
>
>
>>TYPEDEF - is from the '02 Standard
>>
>>
>
>The first version was hardcoded for 200 digits. In searching for a way to
>abstract the number of digits, TYPEDEF was the only solution available. If Cobol
>'85 had better abstraction facilities, I would have used them.
>
>
>
>>PROGRAM-ID omitted/commented - is (semi-documented) extension
>>
>>
>
>Whoops. An accident. It should have not been commented.
>
>
>
>>and would certainly compile the program with FLAGSTD at least once to see what
>>other extensions are in use. However, (again) none of this says anything
>>
>>
>about
>
>
>>how useful this would be to someone in a Micro Focus-ONLY environment.
>>
>>
>
>ENTRY is supported by many other compilers, including IBM. Except for ENTRY, it
>is dead-stock Standard Cobol.
>
>
>
- Next message: docdwarf_at_panix.com: "Re: Layout Hell-o"
- Previous message: William M. Klein: "Non-DISPLAY numeric data in files"
- In reply to: Robert Wagner: "Re: huge number calculator and library"
- Next in thread: SkippyPB: "Re: huge number calculator and library"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
