Home > Archive > Cobol > August 2004 > cobol data format!!! urgent!!!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
cobol data format!!! urgent!!!
|
|
| Stella 2004-08-24, 3:55 am |
| Can anybody please let me know the internal representation of comp-1
and comp-2 data format. for example like what bytes will be stored for
data like +1234,-1234.
| |
|
|
| Gerry Anstey 2004-08-26, 3:55 pm |
| deepakhbti@rediffmail.com (Stella) wrote in message news:<455feb1d.0408232110.50e690ee@posting.google.com>...
> Can anybody please let me know the internal representation of comp-1
> and comp-2 data format. for example like what bytes will be stored for
> data like +1234,-1234.
Comp-1 in single word floating point and comp-2 is double word
floating point, see the principles of operation manual for an
explanation of how the numbers are held: http://tinyurl.com/6p3qs
GA
| |
| JerryMouse 2004-08-26, 3:55 pm |
| Stella wrote:
> Can anybody please let me know the internal representation of comp-1
> and comp-2 data format. for example like what bytes will be stored for
> data like +1234,-1234.
These are compiler dependent, but I can get you started from my old days on
IBM.
A full-word, floating point number is represented by exponent (1st byte) and
mantissa (next three bytes). The exponent is biased by 40 with the implied
hexidecimal point immediately in front of the mantissa. So, zero is
(hexidecimal point, in brackets, is imaginary):
40 [.]00 00 00
The exponent tells you where the hexadecimal point is located (biased by
40). So "1" is represented by:
41 1[.]0 00 00
"1.5" is 41 1[.]8 00 00
"2048" is 43 80 0[.]0 00
"32768" is 44 80 00[.] 00
"0.5" is 39 [.0]80 00 00 <== 39 = 40 - 1, moving hexpoint to left
The sign is carried as the leading bit
"-1" = C1 1[.]0 00 00 00
In double-word floating point, the mantissa is expanded by 4 bytes:
"1" = 41 1[.]0 00 00 00 00 00 00 00
So, to deduce a number like 44 12 34 00,
1. write down the mantissa
12 34 00 00
2. Count off hexidecimal places (44 - 40 = 4)
12 34 [.]00 00
3. Convert 1234 to decimal (4304)
It's not easy to do this by hand, but what's art without suffering.
| |
| Robert Wagner 2004-08-26, 3:55 pm |
| On Tue, 24 Aug 2004 07:54:32 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:
>Stella wrote:
>
>These are compiler dependent, but I can get you started from my old days on
>IBM.
ESA/390 supports IEEE in hardware. Enterprise Cobol does not support
IEEE for most uses (yet), but its JNI does.
The question did not specify IBM mainframe. Comp-1 means IEEE in many
Cobol compilers, including some from IBM, such as AS/400, Visual Age,
AIX.
"IEEE Binary Floating-Point is an industry-standard architecture. The
IBM System/360™ hexadecimal floating-point architecture predates the
IEEE standard and has been carried forward through the System/370™ to
current System/390® processors. The growing importance of industry
standards and floating-point combined to produce a need for IEEE
Floating-Point on System/390. At the same time, customer investment in
IBM floating-point had to be preserved. This paper describes the
architecture, hardware, and software efforts that combined to produce
a conforming implementation of IEEE Floating-Point on System/390 while
retaining compatibility with the original IBM architecture. "
http://www.research.ibm.com/journal/rd/435/abbott.html
http://www-1.ibm.com/support/docvie...g27004196&aid=1
| |
| Chuck Stevens 2004-08-26, 3:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:7ugmi0p0h3r77ukbgki9i08k4k3ioe6pbu@
4ax.com...
> The question did not specify IBM mainframe.
Indeed, nor did it specify the compiler being used.
> Comp-1 means IEEE in many
> Cobol compilers,
... in which it darned well better be marked as an extension to standard
COBOL, regardless of which compiler you're talking about.
COMPUTATIONAL is standard COBOL.
COMPUTATIONAL-1, COMPUTATIONAL-WHATSIS and COMPUTATIONAL-ANYTHING-ELSE mean
*exactly* and *only* what the particular compiler vendor on the particular
platform decides they mean, whatever that might be, and regardless of what
any other vendor on the same or any other platform decides they mean.
> including some from IBM, such as AS/400, Visual Age,
> AIX.
Is there any COBOL implementation anywhere in which COMP-1 *might* mean
anything else? How about COMP-2? I know of some ...
> "IEEE Binary Floating-Point is an industry-standard architecture.
To a point. I haven't obtained a copy of IEC 559:1989 or ISO/IEC 10967:1994
to determine how compatible with IEEE 754 they are.
As it stands now, implementors are free to implement one or more of the
USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
with IEEE Floating-Point representations, *if they so choose*, but USAGEs
for the floating-point representations described in IEEE 754 are *not* in
standard COBOL (of any vintage). .
Note also that the 32-bit and 64-bit IEEE representations are insufficiently
precise or capacious for the purposes of describing a COBOL intermediate
result, and were thus expressly ruled out as a possible format for the COBOL
Standard Intermediate Data Item (SIDI) as described in ISO/IEC 1989:2002. .
While the 128-bit quadruple-precision IEEE format that *has been proposed*
for the next revision of IEEE 754 is better, and might be shown to meet the
requirements of the COBOL Standard Intermediate Data Item, this format is
not yet *approved* as part of the IEEE standard.
Note also that so far as I know IEEE 754 is an *American* standard, not an
ISO-approved one, and that presents practical and diplomatic problems for
its citation within an *international* standard, particularly if IEC
559:1989 and ISO/IEC 10967:1994 (which *are* indisputably referenceable in
another ISO standard) differ from it in any significant way.
-Chuck Stevens
| |
| Jack Sleight 2004-08-26, 3:55 pm |
| Hey Stella!!!!
Your sister would tell you it's unseemly to use the word urgent!!!!
when relying on the generosity of strangers.
gerry_anstey@hotmail.com (Gerry Anstey) wrote in message news:<87b8877d.0408240136.7dfcbd4c@posting.google.com>...
> deepakhbti@rediffmail.com (Stella) wrote in message news:<455feb1d.0408232110.50e690ee@posting.google.com>...
>
> Comp-1 in single word floating point and comp-2 is double word
> floating point, see the principles of operation manual for an
> explanation of how the numbers are held: http://tinyurl.com/6p3qs
>
> GA
| |
| Robert Wagner 2004-08-26, 3:55 pm |
| On Tue, 24 Aug 2004 09:43:12 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:7ugmi0p0h3r77ukbgki9i08k4k3ioe6pbu@
4ax.com...
>
>
> ... in which it darned well better be marked as an extension to standard
>COBOL, regardless of which compiler you're talking about.
>
>COMPUTATIONAL is standard COBOL.
>
>COMPUTATIONAL-1, COMPUTATIONAL-WHATSIS and COMPUTATIONAL-ANYTHING-ELSE mean
>*exactly* and *only* what the particular compiler vendor on the particular
>platform decides they mean, whatever that might be, and regardless of what
>any other vendor on the same or any other platform decides they mean.
When the vendor says it complies with IEEE 754, users refer to that
standard for a definition. Granted it's not Cobol, but it's not
vendor-defined either.
>Is there any COBOL implementation anywhere in which COMP-1 *might* mean
>anything else? How about COMP-2? I know of some ...
You've kindly described here their meaning in Unisys.
>
>To a point. I haven't obtained a copy of IEC 559:1989 or ISO/IEC 10967:1994
>to determine how compatible with IEEE 754 they are.
IEC 559 is identical. IEC 10967:1994 added integers. Its
floating-point is close but not identical. Differences are in flags
and handling extreme values such as zero and infinity. The 2001 update
added numerical functions.
Floating-point numbers contain a flag specifying whether they follow
10967 or 'other', which usually means 754/559.
>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).
In the 20 years since IEEE 754 was adopted, the computer industry
boomed. Because Cobol offered no floating-point, we used the best
standard available.
>Note also that the 32-bit and 64-bit IEEE representations are insufficiently
>precise or capacious for the purposes of describing a COBOL intermediate
>result, and were thus expressly ruled out as a possible format for the COBOL
>Standard Intermediate Data Item (SIDI) as described in ISO/IEC 1989:2002. .
>
>While the 128-bit quadruple-precision IEEE format that *has been proposed*
>for the next revision of IEEE 754 is better, and might be shown to meet the
>requirements of the COBOL Standard Intermediate Data Item, this format is
>not yet *approved* as part of the IEEE standard.
These four sources say it has been in the standard since 1985. The
last two made machines and/or compilers that used it.
IEC 10967 inherited Extended (below) from the earlier standards. Look
at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
'long double' type and it explicitly cites compliance with IEC 10967.
http://www.kuzbass.ru/docs/isocpp/l...b.support.types
"When comparing the format parameters of "extended double-precision"
in IEEE-754's Table 1 and those of the so-called
"quadruple-precision", one finds that the "quadruple-precision" format
is simply a specific instance of the "extended double-precision"
format. Similarly, one will note that "double-precision" is a specific
instance of "extended single-precision"."
http://babbage.cs.qc.edu/courses/cs...references.html
"The standard defines the encoding for the quadruple-precision
floating-point data type "quadruple" (128 bits or 16 bytes). The
encoding used is designed to be a simple analog of of the encoding
used for single and double-precision floating-point numbers using one
form of IEEE double extended precision. The standard encodes the
following three fields, which describe the quadruple-precision
floating-point number: "
[Sun manual]
http://asg.web.cmu.edu/rfc/rfc1832.html
Language elements that support the various extended range and ex-
tended precision floating-point architectural features:
- 32-bit IEEE S_floating data type, with an 8-bit exponent and
23-bit mantissa, which provides a range of 1.17549435E-38 (normal-
ized) to 3.40282347E38 (the IEEE denormalized limit is 1.40129846E-
45) and a precision of typically 7 decimal digits
- 64-bit IEEE T_floating data type, with an 11-bit exponent and
53-bit mantissa, which provides a range of 2.2250738585072013D-
308 (normalized) to 1.7976931348623158D308 (the IEEE denormal-
ized limit is 4.94065645841246544D-324) and a precision of typ-
ically 15 decimal digits
- 128-bit IEEE extended X_floating data type, with a 15-bit ex-
ponent and a 113-bit mantissa, which provides a range of approx-
imately 6.48Q-4966 to 1.18Q4932 and a precision of typically 33
decimal digits
[DEC manual]
http://www.iac.tut.fi/usr/local/doc.../f9a200_spd.txt
See also this bibliography. Search for extended.
http://www.cs.berkeley.edu/~dbindel...279/dsb-bib.pdf
>Note also that so far as I know IEEE 754 is an *American* standard, not an
>ISO-approved one, and that presents practical and diplomatic problems for
>its citation within an *international* standard, particularly if IEC
>559:1989 and ISO/IEC 10967:1994 (which *are* indisputably referenceable in
>another ISO standard) differ from it in any significant way.
That's a problem. It appears that IEC 559 will be replaced by IEC
10967, which has small differences -- not in number representation but
in administrative details.
I cannot find one single compiler, any language, claiming to be
10967-compliant. Yet J4 cannot give us IEEE floating-point because
10967 exists?
>As it stands now, implementors are free to implement one or more of the
>USAGEs FLOAT-SHORT, FLOAT-LONG and/or FLOAT-EXTENDED in a manner consistent
>with IEEE Floating-Point representations, *if they so choose*, but USAGEs
>for the floating-point representations described in IEEE 754 are *not* in
>standard COBOL (of any vintage).
This response from Ann Bennett, only two years ago, rejects the idea
of using EITHER standard in Cobol 2002.
"1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
floating point).
Response: A floating point data type was added in FCD 1989 to
provide access to hardware floating point, which is not universally
IEEE 754. A primary requirement addressed by FCD 1989 is interaction
with other programming languages. A mandated IEEE 754 implementation
would not meet that requirement. "
http://www.cobolportal.com/j4/files/02-0060.doc
| |
| Chuck Stevens 2004-08-26, 3:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:m0vmi0p1e99g7sje29tmnt48rie677dlg3@
4ax.com...
10967:1994[color=darkred]
>
> IEC 559 is identical. IEC 10967:1994 added integers. Its
> floating-point is close but not identical. Differences are in flags
> and handling extreme values such as zero and infinity. The 2001 update
> added numerical functions.
> Floating-point numbers contain a flag specifying whether they follow
> 10967 or 'other', which usually means 754/559.
Aye, there's the rub. "Usually means ..." doesn't work really well in a
standard, be it ISO 10967 or ISO/IEC 1989!
> In the 20 years since IEEE 754 was adopted, the computer industry
> boomed. Because Cobol offered no floating-point, we used the best
> standard available.
Who be "we"? COBOL on Unisys MCP systems has had pretty near "the best
floating-point available" for forty-odd years! ;-)
What *one* format of high-precision floating-point do you believe is
appropriate for *every* existing machine, producing identical results across
all platforms?
That question hasn't even been answered in COBOL for "single-word" integers!
> These four sources say it has been in the standard since 1985. The
> last two made machines and/or compilers that used it.
"The encoding of extended formats is implementation-defined, and thus their
size in storage." Quadruple precision formats are *basic*, one binary and
one decimal, and data items in each format occupy 128 bits. That there are
exactly two instantiations of extended formats that match the quadruple
precision format (*still described as proposed* in the DRAFT dated last
Friday for the next revision of ISO 754!) is a red herring. *Which*
extended format in the *existing* ISO 754 should the COBOL standard have
insisted was appropriate for all implementations?
> IEC 10967 inherited Extended (below) from the earlier standards. Look
> at ISO/IEC 14882, the C++ standard approved in 1998. It includes a
> 'long double' type and it explicitly cites compliance with IEC 10967.
> http://www.kuzbass.ru/docs/isocpp/l...b.support.types
From what I see, this is a panoply of formats, not a single one appropriate
to all implementations.
> "When comparing the format parameters of "extended double-precision"
> in IEEE-754's Table 1 and those of the so-called
> "quadruple-precision", one finds that the "quadruple-precision" format
> is simply a specific instance of the "extended double-precision"
> format. Similarly, one will note that "double-precision" is a specific
> instance of "extended single-precision"."
> http://babbage.cs.qc.edu/courses/cs...references.html
And ... Are you prepared to demand that all COBOL vendors support
bit-addressability and arbitrary word lengths in order to provide for
"extended double precision" in all formats? Of all vendors around, I'd
argue that Unisys has more experience with that than anyone else around,
based on my eighteen years of intimate exposure to the Burroughs Small
System -- which had bit-addressable memory and for which the microcode
provided different word lengths (if any word orientation at all) for each
language! I don't think other vendors would appreciate a demand by the
COBOL standard for such flexibility!
> "The standard defines the encoding for the quadruple-precision
> floating-point data type "quadruple" (128 bits or 16 bytes). The
> encoding used is designed to be a simple analog of of the encoding
> used for single and double-precision floating-point numbers using one
> form of IEEE double extended precision. The standard encodes the
> following three fields, which describe the quadruple-precision
> floating-point number: "
> [Sun manual]
> http://asg.web.cmu.edu/rfc/rfc1832.html
Ditto. This isn't a *basic* format, it's an *extended* format. It is still
*proposed* as a *basic* format as of the draft of the next revision for IEEE
754 *from last Friday*.
> Language elements that support the various extended range and ex-
> tended precision floating-point architectural features:
> ... - 32-bit IEEE S_floating data type, with an 8-bit exponent and
> 23-bit mantissa, which provides a range of 1.17549435E-38 (normal-
> ized) to 3.40282347E38 (the IEEE denormalized limit is 1.40129846E-
> 45) and a precision of typically 7 decimal digits
>
> - 64-bit IEEE T_floating data type, with an 11-bit exponent and
> 53-bit mantissa, which provides a range of 2.2250738585072013D-
> 308 (normalized) to 1.7976931348623158D308 (the IEEE denormal-
> ized limit is 4.94065645841246544D-324) and a precision of typ-
> ically 15 decimal digits
>
> - 128-bit IEEE extended X_floating data type, with a 15-bit ex-
> ponent and a 113-bit mantissa, which provides a range of approx-
> imately 6.48Q-4966 to 1.18Q4932 and a precision of typically 33
> decimal digits
> [DEC manual]
> http://www.iac.tut.fi/usr/local/doc.../f9a200_spd.txt
And with the exceptions in range cited above, I'm supposed to assume that
the 32-bit and 64-bit encodings are consistent with the goal of
unconditionally identical results on *all* platforms? That someone has
implemented something that looks like, and sometimes works like an IEEE 754
format doesn't impress me much!
It does appear that the particular choice for an Extended X-floating type
does match what is proposed as a basic type in IEEE 754, but it ain't in
IEEE 754 as a *basic* type yet, it is one among an undefined number of
possibilities within the set of extended binary floating-point formats.
> I cannot find one single compiler, any language, claiming to be
> 10967-compliant. Yet J4 cannot give us IEEE floating-point because
> 10967 exists?
I believe the *basic* 32-bit and the *basic* 64-bit floating-point encodings
are inadequate for general COBOL use, both in terms of precision and in
terms of range. There is not a *single basic* IEEE floating-point format
that is sufficiently capacious for COBOL. Once one of these standards
provides a *single basic* format adequate to contain a Standard Intermediate
Data Item then that format, and the rounding and precision loss rules
associated with that format, can be *considered* for *standard* COBOL.
Any vendor is free to provide support for whatever formats he wants, and for
whatever rules for "native arithmetic" he deems appropriate.
> This response from Ann Bennett, only two years ago, rejects the idea
> of using EITHER standard in Cobol 2002.
>
> "1.h. Reference, and use later on, IEC 60559 (a.k.a. IEEE 754, IEEE
> floating point).
>
> Response: A floating point data type was added in FCD 1989 to
> provide access to hardware floating point, which is not universally
> IEEE 754. A primary requirement addressed by FCD 1989 is interaction
> with other programming languages. A mandated IEEE 754 implementation
> would not meet that requirement. "
>
> http://www.cobolportal.com/j4/files/02-0060.doc
Yes, this was in response to a comment from the national standards body of
Sweden about the Final Committee Draft, and I agree with the response, which
represented J4's consensus.
Your DEC example above amply illustrates my big concern for the 32-bit and
64-bit encodings: even if the format matches, the *operating environment*
(regardless of system, hardware, platform, whatever you want to call it) has
to *operate the same* regardless. This looks like IEEE floating-point
formats, but the documentation expressly states that it doesn't behave like
them.
And as to her concern: floating-point formats are *typically* defined for
the individual platform, and the 2002 standard COBOL definition allows them
to be what the platform defines them to be. If the COBOL compiler required
that IEEE-format floating-point be used, and the Pascal compiler on the same
platform used native-format floating-point, the two are incompatible. For
any degree of more-than-snail-like performance, in order to make good use of
IEEE floating point formats, the particular platform vendor has to provide
*hardware* support for the format. Not all do, not all wish to do so, not
all believe that there is sufficient customer demand for this feature.
I don't believe an ISO standard has yet "blessed" a *single* extended
X-floating format; my best guess is that the 128-bit decimal and binary
floating-point formats in the draft will be in the next revision of IEEE
754, and promulgated into ISO standards from there. Until ISO (or IEEE)
establishes hard-and-fast rules for rounding and precision loss in
arithmetic for those *specific* formats, I don't think there's much chance
of convincing WG4 that this is a worthwhile addition to the standard.
Once these formats are accepted *as a basic format in an international
standard*, I see significant merit in the idea of data types corresponding
to them, and even in the idea of support (in the language, in hardware, and
in supporting software) for the IEC/IEEE arithmetic rules corresponding to
the six basic IEEE 754 floating-point formats in a manner similar to, and
according to the precedent established by, the ARITHMETIC clause of the
OPTIONS paragraph. But *only* once the 128-bit encodings are ensconced as
*basic* formats in an ISO or IEC standard.
Note that another comment from Sweden was "Reference, and use later on,
LIA-1 (ISO/IEC 10967-1:1994; note, however, annex E of LIA-2). LIA-1 is
"Language independent arithmetic-integer and floating point arithmetic."
The J4 response was "Most of the arithmetic specification in FCD 1989
existed in the previous edition of the COBOL standard and cannot be changed
incompatibly. WG4 will investigate mapping to LIA-1 in a future standard".
In this context, since the FCD that was being commented on was that which
has already led to ISO/IEC 1989:2002, and since WG4 has already indicated to
J4 what feature content they will accept in the planned 2008 draft, and by
their direction that feature content doesn't include LIA-1 and LIA-2. So
far as I can tell, *basic* floating-point formats (as distinct from specific
or arbitrary selections from among the many possible *extended*
floating-point formats) sufficient to encompass the requirements of a COBOL
Standard Intermediate Data Item do not *yet* exist in a *published*
international standard. "Future standard" in this case means "some version
of the standard after the one being proposed for publication in 2008", so
from that I'd think it'd be safe to surmise that LIA-1 and LIA-2 support
won't show up in an approved version of ISO/IEC 1989 any time soon.
-Chuck Stevens
| |
| James J. Gavan 2004-08-26, 3:55 pm |
| Chuck Stevens wrote:
>Who be "we"? COBOL on Unisys MCP systems has had pretty near "the best
>floating-point available" for forty-odd years! ;-)
>
>
"Who be 'we' ? Never realized you had visited my beloved Somerset on
vacation.
"Ooh bee wee ?". "Oi'll tell yoo ooh wee bee if yoo tells o'I where
yooos at ". :-)
Roberto,
ACCOUNTING :
While I'm at it. You posted something a while back on accounting -
nobody picked up on it.
Background, just before leaving RAF was doing correspondence course
Chattered Institute of Secretaries, (the corporate Secretary then was
chief legal-beagle(corporate law)/and chief bean-counter - now defunct
and as we know the two functions are now split). Then in civvy street
became the lowest of the low in Sep '61 coding A/P invoices to be
key-punched using either Power-Samas or Hollerith for print-outs. Come
late '62/early '63 was Deputy Accountant for this large dairy company.
Switched to EDP in June '64 with same company. Never regretted it,
getting away from bean-counting. (O'ive been at this ADP stuff, man an'
boiiy theese passt fortie yeers).
Now your message wasn't Misinformation but more Disinformation. That
Dutchman back in the 1600s invented Double-Entry book-keeping NOT
Quadruple. Where did you learn your Inventive Accounting ? Enron ? Ahhh
that explains all..As I recall you put $5,000 into a new company you set
up and called the money a 'Future Liability' ?. Then magically you
turned the $5,000 into $10,000. Sometime since I did manual accounting
or computer accounting but I thought that can't be right.
Two possibilities :-
1) Deposit to Bank then make immediate Payment (Zilch !)
2) What you suggested - Deposit to Bank, don't make payment and have it
in a 'Current future liability' - still only comes out as $5,000.
Whichever way you do it, you ain't gonna see Ten Grand on your Balance
Sheet. Don't believe me. Do what I did, for confirmation, post the
entries for (1) and (2) above, as separate companies, through something
like Quickbooks !
I know........ You are going to tell me Intuit's Quickbooks is a lousy
package.
OBJECT ORIENTATION :
I read with interest your "Random Number Simulation ?" where you were
comparing using straight table features versus OO Collection classes.
- I'm going from memory but I think you set the Capacity to a figure of
50K.( NB Mr. Stephens - use of the word 'Capacity'.)
- One exercise you used Dictionary (will be called KeyedCollection in
new J4 TR(Technical Report) for collections). I could be wrong, but
reading Adele Golberg's book "Smalltalk 80", (the text, not the coded
examples), Dictionaries/KeyedCollections are primarily quick
memory-resident look-up tables. - so the vendor's code, having
physically placed the element in the collection, each element probably
added as "Last", then has to do the equivalent of an ISAM, registering
the Key and noting the 'silent' index position of the Element. - plus of
course no duplicate keys allowed. That means KeyedCollections are a bit
'busy, busy, busy' actioning elements. Truly doesn't make it suitable
for what you were doing.
- SortedCollections - I think you may have used ? Again adding records
as 'Last' and probably doing a silent index comparing values of elements
either side of the one you are entering. Busy, busy, busy - again not
suitable.
- OrderedCollection - just keeps adding as 'Last' which is what I think
you were after. However, you complained its performance was also lousy.
Haven't looked at them, because I haven't seen the need, but perhaps one
of the others, Bag, ValueSet might possibly have been useful . Now don't
rush off and try it because our kind friends at J4 have reduced it
currently to :-
- OrderedCollection
- UnorderedColllection
- KeyedCollection
Wait just a few days Chuck - I *USE* SortedCollections 80-95% of the
time. Piss on Unordered - that's achievable using Ordered. which will
also do what Robert wants.
Back to Robert - Smalltalk does have specific classes for Simulation -
but I've no idea how they perform. Perhaps the basic OrderedCollection
may not be up to the type of volume you are talking about, not a big
number, I believe it was 50K - but where there is user-interaction, or
say collecting data for a simulation (some O & M goof work-studying the
customer flow, through a department store central cash desk), then the
performance will be more than adequate. They are just recording timed
events.
I believe you have Fujitsu as well as ServerExpress - does F/J provide
class source like M/F. ? It's a boon - gives you tips on coding and in
your case having access to the support classes for OrderedCollection you
could sub-class with your own methods to override some of the current
ones, to fine-tune the simulation performance.
I could be real *evil* and suggest that if you think OO is lacking in
this area make a submission to J4 - Chuck is *already* groaning and
preparing his draft e-mail. Don't you dare, Robert ! Because to use
your own wording, "this is one of my intellectual exercises....". Anyway
before your paper hits Don Schricker, Chuck will already have e-mailed
the others on J4 warning , "Whatever the number is that gets allocated,
from RW - get ready say, "No!"). :-)
Here endeth the lesson - people get paid for this stuff.
Jimmy, Calgary AB
| |
| docdwarf@panix.com 2004-08-26, 3:55 pm |
| In article <lm8Xc.216394$gE.12574@pd7tw3no>,
James J. Gavan <jjgavan@shaw.ca> wrote:
[snip of anything vaguely resembling context]
>Here endeth the lesson - people get paid for this stuff.
They do? My stars and garters, they should get a gander at some of the...
stuff that gets flung around here for free; it's worth at least *double*
that!
DD
| |
| Chuck Stevens 2004-08-26, 3:55 pm |
|
"James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:lm8Xc.216394$gE.12574@pd7tw3no...
> I could be real *evil* and suggest that if you think OO is lacking in
> this area make a submission to J4 - Chuck is *already* groaning and
> preparing his draft e-mail. Don't you dare, Robert ! Because to use
> your own wording, "this is one of my intellectual exercises....". Anyway
> before your paper hits Don Schricker, Chuck will already have e-mailed
> the others on J4 warning , "Whatever the number is that gets allocated,
> from RW - get ready say, "No!"). :-)
Nahhh. I don't pre-warn the other J4 members on such matters. I *always*
recommend submitting suggestions for improvements to the standard to J4.
I believe the other members of J4 to be competent to decide for themselves
whether the changes *anybody* suggests have sufficient merit to warrant a
delay in the production of the TR (and the concomitant delay in the
production of the next standard).
When such subjects come up, I might state my opinion as to their viability,
as well as whether they represent a "missing piece" or an "additional
feature", but only in meetings or if correspondence among the J4 members
arises from elsewhere on the committee. I for one welcome serious and
careful submissions, though I admit being annoyed by frivolous ones.
Many features of 2008 COBOL were designed to be introduced in "minimalist"
form, to be enhanced -- based on real-world experience -- in future
standards if there's enough interest from users, vendors and implementors.
If nobody actually uses a mechanism in practice, it's not clear that adding
a whizbang feature to that mechanism will be worth the effort of either J4
to design it or implementors to provide it!
-Chuck Stevens
| |
| James J. Gavan 2004-08-26, 3:55 pm |
| Chuck Stevens wrote:
>Many features of 2008 COBOL were designed to be introduced in "minimalist"
>form, to be enhanced -- based on real-world experience -- in future
>standards if there's enough interest from users, vendors and implementors.
>If nobody actually uses a mechanism in practice, it's not clear that adding
>a whizbang feature to that mechanism will be worth the effort of either J4
>to design it or implementors to provide it!
>
>
>
I can understand and agree with that. With the flexibility of OO
probably (???) even the proposed minimalist classes for collections
would suffice say for something like Simulation. On the other hand,
along comes a whiz bang mathematician who sees a crying need for
enhancements. Well if there's only one user - diplomatic reply, "Thank
you for your interest re Simulation. Why don't you take a look at
FORTRAN ?". :-)
Just don't go too 'minimalist' on me on Collections - and with due
humility I will provide some 'real world experience' to support my case..
That problem with object references for Collection elements - got it
licked. I was close, but couldn't get it to work. Fortunately David at
Newbury spotted it immediately he saw my code As it stands for
instantiations currently, in Net Express V 3.1. - not sure about V
4.0, you *must* specify global OBJECT-STORAGE SECTION instead of
WORKING-STORAGE SECTION (2002 Standard). Got into the habit of using
WORKING-STORAGE thinking of future compatibility - and if you are only
actually producing ONE instance sometimes it appears to work, others
not. I've spotted it and changed "WORKING" back to "OBJECT". Ahhh but
many instances of the same class - then you have got to use
OBJECT-STORAGE SECTION because that's the trigger to the compiler. Mind
you wouldn't have hurt if the author who kick-started the thing had
provided a quick answer. With a mental blockage on the feature until I
got it resolved, it certainly has delayed my being able to comment by
some two w s..
Jimmy, Calgary AB
| |
| Robert Wagner 2004-08-26, 3:55 pm |
| On Wed, 25 Aug 2004 22:26:25 GMT, "James J. Gavan" <jjgavan@shaw.ca>
wrote:
>Chuck Stevens wrote:
>
>"Who be 'we' ? Never realized you had visited my beloved Somerset on
>vacation.
>
>"Ooh bee wee ?". "Oi'll tell yoo ooh wee bee if yoo tells o'I where
>yooos at ". :-)
>
>Roberto,
If I supported the drug culture, I'd say 'That's some good shit you're
on. Care to share?' But I don't support it, so I don't ask.
>Now your message wasn't Misinformation but more Disinformation. That
>Dutchman back in the 1600s invented Double-Entry book-keeping NOT
>Quadruple. Where did you learn your Inventive Accounting ? Enron ? Ahhh
>that explains all..As I recall you put $5,000 into a new company you set
>up and called the money a 'Future Liability' ?.
No, you called it Asset.
>Then magically you
>turned the $5,000 into $10,000. Sometime since I did manual accounting
>or computer accounting but I thought that can't be right.
>
>Two possibilities :-
>
>1) Deposit to Bank then make immediate Payment (Zilch !)
>2) What you suggested - Deposit to Bank, don't make payment and have it
>in a 'Current future liability' - still only comes out as $5,000.
>
>Whichever way you do it, you ain't gonna see Ten Grand on your Balance
>Sheet. Don't believe me. Do what I did, for confirmation, post the
>entries for (1) and (2) above, as separate companies, through something
>like Quickbooks !
Two possibilities --
1) Sell the company for $10K.
2) Do a quasi-reorganization.
>Back to Robert - Smalltalk does have specific classes for Simulation -
>but I've no idea how they perform.
Nor do I. I'd bet everything it's piss poor.
>I could be real *evil* and suggest that if you think OO is lacking in
>this area make a submission to J4 - Chuck is *already* groaning and
>preparing his draft e-mail. Don't you dare, Robert ! Because to use
>your own wording, "this is one of my intellectual exercises....". Anyway
>before your paper hits Don Schricker, Chuck will already have e-mailed
>the others on J4 warning , "Whatever the number is that gets allocated,
>from RW - get ready say, "No!"). :-)
It's really kicking in now. Bliss, brother. J4 doesn't dictate
performance. That's up to the implementor/vendor.
>Here endeth the lesson - people get paid for this stuff.
Enough for the next nickel bag?
| |
| docdwarf@panix.com 2004-08-26, 3:55 pm |
| In article <7buqi0dt6adb1hnfr7plba7ltf9c6q6ceh@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On Wed, 25 Aug 2004 22:26:25 GMT, "James J. Gavan" <jjgavan@shaw.ca>
>wrote:
>
>
>If I supported the drug culture, I'd say 'That's some good shit you're
>on. Care to share?' But I don't support it, so I don't ask.
And, Mr Wagner, were you not so arrogantly ethnocentric and limited in
your worldview to a small heap of accents and dialects you'd recognise a
classic demonstration of mild chiding by use of the speech used typically
by those of a lower socioeconomic bracket or in a rural area...
.... but maybe it is not this at all, I could be wrong since I'se jes' a
COBOL-codin' fool. In any case, Mr Wagner, that *you* see no sense in it
does not mean that there is no sense to be found in it; to conclude that
'I don't understand so it must be without sense' is, in my experience, the
mark of an inferior intellect and a base, churlish soul.
DD
| |
| Robert Wagner 2004-08-26, 3:55 pm |
| On 26 Aug 2004 05:37:57 -0400, docdwarf@panix.com wrote:
>In article <7buqi0dt6adb1hnfr7plba7ltf9c6q6ceh@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>And, Mr Wagner, were you not so arrogantly ethnocentric and limited in
>your worldview to a small heap of accents and dialects you'd recognise a
>classic demonstration of mild chiding by use of the speech used typically
>by those of a lower socioeconomic bracket or in a rural area...
I grew up in the lower socioeconomic class. Rather than finding
vibrancy and 'joy of life', I found it pathetic .. an example of how
NOT to live one's life.
>... but maybe it is not this at all, I could be wrong since I'se jes' a
>COBOL-codin' fool.
Some would say that's redundant.
>In any case, Mr Wagner, that *you* see no sense in it
>does not mean that there is no sense to be found in it; to conclude that
>'I don't understand so it must be without sense' is, in my experience, the
>mark of an inferior intellect and a base, churlish soul.
I never understood Monty Python, either. A bunch of gay guys acting
like buffos is supposed to be high-art funny? What I find amusing is
intelligent wit such as HL Mencken and this:
Lettered gentility .. is achieved at King's College at the cost of
certain theatricality. It is hard, at times, to recall that the
pictures are real, the port is real, that the candles in the
candlesticks are real candles and not electric lights pretending to be
candles; above all, that the people are creatures of flesh and bone.
In my two years there as a Fellow, I found that a sense of illusion
was rapidly becoming my standard experiential mode. The air of charade
was all-pervasive: the sons of suburbia, like myself, parodied the
lettered gentry; and the lettered gentry parodied the sons of suburbia
parodying themselves ... Brilliant young scientists who knew nothing
of life or art gave ham performances of the role "brilliant young
scientist who knows nothing of life or art." Vain art historians gave
virtuoso performances of "art historian being distastefully vain." And
the institution itself rose repeatedly to heights of dramatic
absurdity.
--Liam Nelson, The Cult of the Fact
| |
| docdwarf@panix.com 2004-08-26, 3:55 pm |
| In article <0vhri01rque18qvh61ol9omu16qmhv9520@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 26 Aug 2004 05:37:57 -0400, docdwarf@panix.com wrote:
>
>
>I grew up in the lower socioeconomic class. Rather than finding
>vibrancy and 'joy of life', I found it pathetic .. an example of how
>NOT to live one's life.
It was not suggested that you find 'vibrancy' or 'joy of life' there, Mr
Wagner, nor was it suggested that 'poor is better'. It was suggested that
you might, given a bit of education and experience, be able to recognise a
classic demonstration of mild chiding by use of the speech used typically
by those of a lower socioeconomic bracket or in a rural area.
>
>
>Some would say that's redundant.
There are more things in Heaven and on earth than are dreamt of in your
philosophies, Horatio.
>
>
>I never understood Monty Python, either. A bunch of gay guys acting
>like buffos is supposed to be high-art funny?
It is one thing not to understand, Mr Wagner, and to admit to a lack of
understanding; it is quite another to conclude, as you did above, that
something you do not understand is the result of intoxication.
>What I find amusing is
>intelligent wit such as HL Mencken and this:
>
>Lettered gentility .. is achieved at King's College at the cost of
>certain theatricality. It is hard, at times, to recall that the
>pictures are real, the port is real, that the candles in the
>candlesticks are real candles and not electric lights pretending to be
>candles; above all, that the people are creatures of flesh and bone.
>In my two years there as a Fellow, I found that a sense of illusion
>was rapidly becoming my standard experiential mode. The air of charade
>was all-pervasive: the sons of suburbia, like myself, parodied the
>lettered gentry; and the lettered gentry parodied the sons of suburbia
>parodying themselves ... Brilliant young scientists who knew nothing
>of life or art gave ham performances of the role "brilliant young
>scientist who knows nothing of life or art." Vain art historians gave
>virtuoso performances of "art historian being distastefully vain." And
>the institution itself rose repeatedly to heights of dramatic
>absurdity.
How very touching and sensitive of you to provide such a cite, Mr
Wagner... some might see it as a transparent, pitiable effort of a
self-loathing member of the Booboisie at attempting to disguise his
disgust with his background by slavishly and clownishly aping the
affectations of those whom he thinks to be his betters...
.... and some might see it otherwise.
DD
| |
| Chuck Stevens 2004-08-26, 3:55 pm |
| "James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:lm8Xc.216394$gE.12574@pd7tw3no...
> "Who be 'we' ? Never realized you had visited my beloved Somerset on
> vacation.
Actually, I think I have, if a town in the Northeast of that region (but I
think administratively separate) counts.
If a little bit of Georgian architecture executed in yellow-tan stone is
good, a WHOLE LOT of Georgian architecture executed in yellow-tan stone has
to be a WHOLE LOT better, right? Thank you, Messrs. Wood (pere et fils),
but enough is enough ... ;-)
Unless you were talking about the Somerset that the Boerne Greyhounds
football team used to play against back in the 1950's, which I visited a few
times as a member of the Boerne High School Marching Band ... Nice town, I
guess, but "beloved?" ;-)
I didn't pick up the usage from either of these locations, by the way, but I
don't know where; most likely, I think is the quote "I doubt me an it be
commercial" from a Flanders & Swann bit about (as I recall) the origins of
Greenfleeves.
-Chuck Stevens
| |
| Robert Wagner 2004-08-26, 3:55 pm |
| On Wed, 25 Aug 2004 12:15:22 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:m0vmi0p1e99g7sje29tmnt48rie677dlg3@
4ax.com...
>
>
>
>Aye, there's the rub. "Usually means ..." doesn't work really well in a
>standard, be it ISO 10967 or ISO/IEC 1989!
Like most standard committees, the 10967 folk take the attitude 'if
you don't do it our way, you're on your own.' Why should they support
the competition in IEC 559?
>
>What *one* format of high-precision floating-point do you believe is
>appropriate for *every* existing machine, producing identical results across
>all platforms?
IEEE 754. That's not only my belief, that's reality. It's in most
Intel, Motorola, Power PC, Sun and HP CPUs. It's even in S/390. See
below.
>"The encoding of extended formats is implementation-defined, and thus their
>size in storage." Quadruple precision formats are *basic*, one binary and
>one decimal, and data items in each format occupy 128 bits. That there are
>exactly two instantiations of extended formats that match the quadruple
>precision format (*still described as proposed* in the DRAFT dated last
>Friday for the next revision of ISO 754!) is a red herring. *Which*
>extended format in the *existing* ISO 754 should the COBOL standard have
>insisted was appropriate for all implementations?
I'd say decimal. Cobol people 'know' binary floating-point is
inappropriate for bidness use because it cannot represent .01 exactly.
>
>From what I see, this is a panoply of formats, not a single one appropriate
>to all implementations.
As far as I know, every C++ implementation has float and double. The
addition of long double is logical.
>
>
>And ... Are you prepared to demand that all COBOL vendors support
>bit-addressability and arbitrary word lengths in order to provide for
>"extended double precision" in all formats? Of all vendors around, I'd
>argue that Unisys has more experience with that than anyone else around,
>based on my eighteen years of intimate exposure to the Burroughs Small
>System -- which had bit-addressable memory and for which the microcode
>provided different word lengths (if any word orientation at all) for each
>language! I don't think other vendors would appreciate a demand by the
>COBOL standard for such flexibility!
PACKED DECIMAL requires bit addressability on platforms that don't
support it in hardware i.e. all except IBM and Unisys.
Accessing bits doesn't require bit-addressable memory; it requires an
AND instruction. You already knew that.
>Ditto. This isn't a *basic* format, it's an *extended* format. It is still
>*proposed* as a *basic* format as of the draft of the next revision for IEEE
>754 *from last Friday*.
Perhaps the standards process is too slow for real-world use. DEC,
Sun, et al. couldn't afford to sit on their hands for 20 years. They
reasonably went with the closest standard, or approximation thereof,
available at the time. If there had been a standard, they would have
used it.
>
>Yes, this was in response to a comment from the national standards body of
>Sweden about the Final Committee Draft, and I agree with the response, which
>represented J4's consensus.
>
>Your DEC example above amply illustrates my big concern for the 32-bit and
>64-bit encodings: even if the format matches, the *operating environment*
>(regardless of system, hardware, platform, whatever you want to call it) has
>to *operate the same* regardless. This looks like IEEE floating-point
>formats, but the documentation expressly states that it doesn't behave like
>them.
It was legacy design. The VAX 'G' format looked like IEEE but did not
behave the same. More recent DEC designs, such as Alpha, are
compliant.
>And as to her concern: floating-point formats are *typically* defined for
>the individual platform, and the 2002 standard COBOL definition allows them
>to be what the platform defines them to be.
I dispute that. It WAS typical in the mainframe world and elsewhere
prior to 1985. It wasn't the case in 2002.
This document shows how Intel achieved 100% compatibility with the
IEEE standard, in behavior as well as format.
"Two subsections are dedicated to the floating-point divide,
remainder, and square root operations, which are implemented in
software. It is shown how IEEE compliance was achieved using new IA-64
features such as fused multiply-add operations, predication, and
multiple status fields for IEEE status flags. Derived integer
operations (the integer divide and remainder) are also illustrated.
IA-64 floating-point exceptions and traps are described, including the
Software Assistance faults and traps that can lead to further
IEEE-defined exceptions. The software extensions to the hardware
needed to comply with the IEEE Standard's recommendations in handling
floating-point exceptions are specified. "
http://developer.intel.com/technolo...icles/art_6.htm
Here we see AMD doing rigorous compliance testing:
We describe a mechanically verified proof of correctness of the
floating-point multiplication, division, and square root instructions
of The AMD K7 microprocessor. The instructions, which are based on
Goldschmidt's Algorithm, are implemented in hardware and represented
here by register-transfer level specifications, the primitives of
which are logical operations on bit vectors. On the other hand, the
statements of correctness, derived from IEEE Standard 754, are
arithmetic in nature and considerable more abstract. Therefore, we
begin by developing a theory of bit vectors and their role in
floating-point representations and rounding, extending our previous
work in conection with the K5 FPU. We then present the hardware model
and a rigorous and detailed proof of its correctness. All of our
definitions, lemmas, and theorems have been formally encoded in the
ACL2 logic, and every step in the proof has been mechanically checked
with the ACL2 prover
http://nitro.xyzdns.net/~russ/david...7-div-sqrt.html
Here we see motorola describing one of its early (1988) chips:
"The DSP96002 is notable for its full hardware support of IEEE-754
single-precision and single-extended-precision floating-point
arithmetic, its two complete sets of external 32-bit address and
32-bit data buses, and its lack of common on-chip peripherals. "
http://www.bdti.com/procsum/mot96002.htm
Here is an account of floating-point history by William Kahan. I urge
you to read the whole report. It's a brilliant description of how a
good standard was developed.
"Anarchy, among floating-point arithmetics implemented in software on
microprocessors, impelled Dr. Robert Stewart to convene meetings in an
attempt to reach a consensus under the aegis of the IEEE. Thus was
IEEE p754 born. The second meeting was held one evening in November
1977 at a San Francisco peninsula hotel under the chairmanship of
Richard Delp. It attracted over a dozen attendees and Prof. Kahan.
"These guys were serious. Some had been sent by microprocessor makers
who had floating-point implementations in mind. National Semiconductor
sent two. Zilog sent someone thinking about a Z8070 for its Z8000.
Motorola was represented by Joel Boney who then led their project in
Austin, Texas, to build what later ( 1984 ) became the MC68881/2
coprocessors. These were beautiful jobs. Of course, motorola and Zilog
had a lot more transistors to play with by then."
"Most mainframe makers, like CDC and Cray, sent nobody to these
meetings, construing them to matter only to microprocessor makers. IBM
was there only to observe; they knew their microprocessors were coming
but couldn't say much."
Prof. Kahan presented the K-C-S draft to the IEEE p754 working group.
It had several proposals to consider. DEC was advocating that their
formats be adopted. Other proposals came from microprocessor
producers. The initial reaction to the K-C-S document was mixed.
"It looked pretty complicated. On the other hand, we had a rationale
for everything. What distinguished our proposal from all the others
was the reasoning behind every decision. I had worked out the details
initially for Intel."
"In the usual standards meetings everybody wants to grandfather in his
own product. I think it is nice to have at least one example -- IEEE
754 is one -- where sleaze did not triumph. CDC, Cray and IBM could
have weighed in and destroyed the whole thing had they so wished.
Perhaps CDC and Cray thought `Microprocessors? Why should we worry?'
In the end, all computer systems designers must try to make our things
work well for the innumerable ( innumerate ?) programmers upon whom we
all depend for the existence of a burgeoning market."
http://www.cs.berkeley.edu/~wkahan/...s/754story.html
> If the COBOL compiler required
>that IEEE-format floating-point be used, and the Pascal compiler on the same
>platform used native-format floating-point, the two are incompatible. For
>any degree of more-than-snail-like performance, in order to make good use of
>IEEE floating point formats, the particular platform vendor has to provide
>*hardware* support for the format.
Anyone who designed new non-compliant hardware after 1985 had rocks in
his head. It didn't happen. Non-compliant hardware is old design. So
make an exception for 'native floating-point' to appease mainframes.
Looking at it positively, most machines have IEEE hardware .. whether
Cobol uses it or not. Denying it's there makes Cobol look .. old.
>I don't believe an ISO standard has yet "blessed" a *single* extended
>X-floating format; my best guess is that the 128-bit decimal and binary
>floating-point formats in the draft will be in the next revision of IEEE
>754, and promulgated into ISO standards from there. Until ISO (or IEEE)
>establishes hard-and-fast rules for rounding and precision loss in
>arithmetic for those *specific* formats, I don't think there's much chance
>of convincing WG4 that this is a worthwhile addition to the standard.
The rules will be the same as 64-bit, logically extended to 128. Just
as 64 is a logical extension of 32.
>Note that another comment from Sweden was "Reference, and use later on,
>LIA-1 (ISO/IEC 10967-1:1994; note, however, annex E of LIA-2). LIA-1 is
>"Language independent arithmetic-integer and floating point arithmetic."
>The J4 response was "Most of the arithmetic specification in FCD 1989
>existed in the previous edition of the COBOL standard and cannot be changed
>incompatibly. WG4 will investigate mapping to LIA-1 in a future standard".
Good answer. I think LIA-1/2 is 'too little, too late'. There are 100M
chips with IEEE cast into silicon.
| |
| Chuck Stevens 2004-08-26, 8:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:0vhri01rque18qvh61ol9omu16qmhv9520@
4ax.com...
> I never understood Monty Python, either. A bunch of gay guys acting
> like buffos is supposed to be high-art funny?
Rather broad brush, that.
Graham Chapman was openly gay, according to his biography. But as to the
other members of the troupe, all the evidence I see in their biographies
indicates to me that they were comfortably heterosexual.
Perhaps your exposure to them was more intimate than mine. Or your
definition of "a bunch" allows it to be synonymous with "one".
-Chuck Stevens
| |
| docdwarf@panix.com 2004-08-26, 8:55 pm |
| In article <cglhir$e8a$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:0vhri01rque18qvh61ol9omu16qmhv9520@
4ax.com...
>
>
>Rather broad brush, that.
>
>Graham Chapman was openly gay, according to his biography. But as to the
>other members of the troupe, all the evidence I see in their biographies
>indicates to me that they were comfortably heterosexual.
>
>Perhaps your exposure to them was more intimate than mine. Or your
>definition of "a bunch" allows it to be synonymous with "one".
Be kind, Mr Stevens... perhaps Mr Wagner is just experiencing a rounding
error.
DD
| |
| William M. Klein 2004-08-26, 8:55 pm |
| Either that or by "gay" he meant "joyous" which I think would describe most - if
not all - of that group <G>
--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:cglj0l$oq0$1@panix5.panix.com...
> In article <cglhir$e8a$1@si05.rsvl.unisys.com>,
> Chuck Stevens <charles.stevens@unisys.com> wrote:
>
> Be kind, Mr Stevens... perhaps Mr Wagner is just experiencing a rounding
> error.
>
> DD
>
| |
| Chuck Stevens 2004-08-27, 3:55 am |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:1j1si05tv3jdi13t2j0lchj0e9u3kkjg0e@
4ax.com...
> Like most standard committees, the 10967 folk take the attitude 'if
> you don't do it our way, you're on your own.' Why should they support
> the competition in IEC 559?
And what would you expect "if you do <x> the expected results are <y>" to
imply if you refuse to follow the constraints of <x>? Perhaps I have
misunderstood what "conformance to a standard" means.
across[color=darkred]
>
> IEEE 754. That's not only my belief, that's reality. It's in most
> Intel, Motorola, Power PC, Sun and HP CPUs. It's even in S/390. See
> below.
IEEE 754 in its current form does *not* specify a *single* format of
*high-precision* floating-point. It specifies a whole range of them, all
equally valid. That's my point.
their[color=darkred]
and[color=darkred]
are[color=darkred]
>
> I'd say decimal. Cobol people 'know' binary floating-point is
> inappropriate for bidness use because it cannot represent .01 exactly.
It's still implementation defined. The quotation above is from IEEE 754.
> As far as I know, every C++ implementation has float and double. The
> addition of long double is logical.
What you haven't demonstrated is that every implementation of C++ has a
"long double", or that what is logical as a representation of a "long
double" in one implementation is exactly the same as every other
implementation of a "long double", or whether any of those implementations
actually are identical to either BINARY128 or DECIMAL128 floating-point
formats as proposed in the August 20 draft of IEEE 754. Thus, "the
addition of long double is logical" is similar to "if we had some ham, we
could have some ham and eggs. If we had some eggs."
> PACKED DECIMAL requires bit addressability on platforms that don't
> support it in hardware i.e. all except IBM and Unisys.
Really? "Each implementor specifies the precise effect of the USAGE IS
PACKED-DECIMAL clause upon the alignment and representation of the data item
in the storage of the computer ...".
> Accessing bits doesn't require bit-addressable memory; it requires an
> AND instruction. You already knew that.
I didn't say "accessing bits", I said "bit addressibility", and perhaps I
should have said "nonpreferential bit addressibility", an environment in
which there are no natural boundaries above the bit level. In such an
environment, accessing a 27-bit "word" that begins at bit 37,421 of the
system memory is accomplished using the same number of instructions as
accessing a 32-bit word at bit 32,768.
> Perhaps the standards process is too slow for real-world use. DEC,
> Sun, et al. couldn't afford to sit on their hands for 20 years. They
> reasonably went with the closest standard, or approximation thereof,
> available at the time. If there had been a standard, they would have
> used it.
And each went their own way. That's precisely my point.
> It was legacy design. The VAX 'G' format looked like IEEE but did not
> behave the same.
Your citation as an example of an implementation of an IEEE 754 format, with
all that entails.
> More recent DEC designs, such as Alpha, are compliant.
With a design that wasn't defined as part of IEEE 754 until 12 November
2001?
for[color=darkred]
them[color=darkred]
>
> I dispute that. It WAS typical in the mainframe world and elsewhere
> prior to 1985. It wasn't the case in 2002.
You dispute *what*? That the Unisys OS/2200 floating-point format isn't the
same as the IBM System/390 format which isn't the same as the Unisys MCP
format which isn't the same as the 16-bit Intel format which isn't the same
as the Sun format which isn't the same as the 32-bit Intel format which
isn't the same as the 64-bit Intel format? Or is it the irrelevance of
everything but PC's to the world of COBOL these days?
> This document shows how Intel achieved 100% compatibility with the
> IEEE standard, in behavior as well as format.
>
> "Two subsections are dedicated to the floating-point divide,
> remainder, and square root operations, which are implemented in
> software. It is shown how IEEE compliance was achieved using new IA-64
> features such as fused multiply-add operations, predication, and
> multiple status fields for IEEE status flags. Derived integer
> operations (the integer divide and remainder) are also illustrated.
> IA-64 floating-point exceptions and traps are described, including the
> Software Assistance faults and traps that can lead to further
> IEEE-defined exceptions. The software extensions to the hardware
> needed to comply with the IEEE Standard's recommendations in handling
> floating-point exceptions are specified. "
>
> http://developer.intel.com/technolo...icles/art_6.htm
I'm sorry, but their "double-extended" isn't 128-bit (best I can tell, it
might be as high as 84 bits.)
> Here we see AMD doing rigorous compliance testing:
>
> We describe a mechanically verified proof of correctness of the
> floating-point multiplication, division, and square root instructions
> of The AMD K7 microprocessor. The instructions, which are based on
> Goldschmidt's Algorithm, are implemented in hardware and represented
> here by register-transfer level specifications, the primitives of
> which are logical operations on bit vectors. On the other hand, the
> statements of correctness, derived from IEEE Standard 754, are
> arithmetic in nature and considerable more abstract. Therefore, we
> begin by developing a theory of bit vectors and their role in
> floating-point representations and rounding, extending our previous
> work in conection with the K5 FPU. We then present the hardware model
> and a rigorous and detailed proof of its correctness. All of our
> definitions, lemmas, and theorems have been formally encoded in the
> ACL2 logic, and every step in the proof has been mechanically checked
> with the ACL2 prover
>
> http://nitro.xyzdns.net/~russ/david...7-div-sqrt.html
"Statements of correctness, derived from IEEE 754" is not the same as "fully
compliant with the requirements of IEEE 754".
> Here we see motorola describing one of its early (1988) chips:
>
> "The DSP96002 is notable for its full hardware support of IEEE-754
> single-precision and single-extended-precision floating-point
> arithmetic, its two complete sets of external 32-bit address and
> 32-bit data buses, and its lack of common on-chip peripherals. "
>
> http://www.bdti.com/procsum/mot96002.htm
Where's the 128-bit floating-point format that would meet the requirements
of COBOL SIDI's?
> Here is an account of floating-point history by William Kahan. I urge
> you to read the whole report. It's a brilliant description of how a
> good standard was developed.
Don't doubt that.
> Anyone who designed new non-compliant hardware after 1985 had rocks in
> his head. It didn't happen. Non-compliant hardware is old design. So
> make an exception for 'native floating-point' to appease mainframes.
The Unisys MCP floating-point formats were in existence a quarter-century
before that. "Native arithmetic" in COBOL is what COBOL has specified since
the first standard; "standard arithmetic" is what's new to COBOL. And the
two current standard basic formats 32-bit and 64-bit binary floating-point
according to IEEE 754 are *inadequate* to the requirements of standard
arithmetic.
> Looking at it positively, most machines have IEEE hardware .. whether
> Cobol uses it or not. Denying it's there makes Cobol look .. old.
The "Brooklyn Bridge" argument?
> The rules will be the same as 64-bit, logically extended to 128. Just
> as 64 is a logical extension of 32.
The gift of prescience is a precious one indeed. I for one don't know what
IEEE is going to do, or, for that matter, what ISO/IEC is going to do; it
must be very gratifying to you that you can state this as a fact! What of
the *decimal* formats?
> Good answer. I think LIA-1/2 is 'too little, too late'. There are 100M
> chips with IEEE cast into silicon.
Think away. COBOL requires implementations allow for 32 digits of precision
in numeric data items for *both* standard *and* native arithmetic, and
requires 32-digit floating-point representations for SIDI's in standard
arithmetic. The current basic 32-bit and 64-bit floating point
representations aren't adequate to that task, and there is no *single*
extended floating-point format for all platforms to implement in a
compatible manner.
-Chuck Stevens
| |
| James J. Gavan 2004-08-27, 3:55 am |
| Chuck Stevens wrote:
>"James J. Gavan" <jjgavan@shaw.ca> wrote in message
>news:lm8Xc.216394$gE.12574@pd7tw3no...
>
>
>
>
>Actually, I think I have, if a town in the Northeast of that region (but I
>think administratively separate) counts.
>
>
>
You pulling my leg. Just to ensure we are on the same wavelength. I'm
talking county of Somersetshire, bordered by Wiltshire, N.E.,
Dorset(shire) S.E. and Devon(shire) W. Or are you talking about Somerset
in Kentucky . There, bet you didn't know I knew that. Dead easy; about 5
years back met a doctor at Lake Louise from Somerset, Ky. Ironically my
son lives in a new housing development SE of me in Calgary called Somerset.
>If a little bit of Georgian architecture executed in yellow-tan stone is
>good, a WHOLE LOT of Georgian architecture executed in yellow-tan stone has
>to be a WHOLE LOT better, right? Thank you, Messrs. Wood (pere et fils),
>but enough is enough ... ;-)
>
>
>
Presumably you are talking Bath ? Fascinating place. Peer down to the
Roman baths (spa) some 30 feet below and you are standing on 30 feet of
human debris built up over the centuries. Could of course go to Cheddar
Gorge, interesting caves with stalagmites(upwards) and
stalactites(downwards) - the way I remember that is tight(tite) "hang
on". There's not an ounce of Cheddar made there. Then of course Bristol
'all shipshape and Bristol fashion', which used to be part of
Zummerzett. My favourite sherry drink, Harvey's Bristol Cream - recent
years reverted to selling it in blue bottles. Kind of puts me off
thinking of methyl hydrate - but in fact the colour is kosher, 'Bristol
Blue'. Taunton nice county town, no big deal. Ever read R.D.
Blackmore's, or seen on PBS "Lorna Doone". 'iz book shure makes a reel
effert to uuse Zummerzet dilict. Location, lovely Exmoor - very
occasional stag.
You wouldn't probably have picked up on it but steeped in Arthurian
legend. As a romanticist, how I so much wish a real person had existed.
I think the legend is based on an amalgam of historical figures, both
from southern Wales and the south-western part of England. At long last
the latest movie, which I haven't seen, sets it in the correct period
Romano-Britain just as the Romans were slowly retreating back to Italy.
Close to where I lived some five miles east of Taunton, a nondescript
hillock in a field Camel(ot). North of me in ancient times, (pre-Roman),
were the Lake Dwellers, just like in modern Indonesia, people living in
houses built on stilts above water level.. Being largely under water the
area towards Glastonbury Tor ties in with the legend. Supposedly Arthur
and his queen are buried there. Just slightly north of me, you are
through the place in about a minute in a car, where Alfred (the Great)
took shelter with a woodsman and his wife while pondering how he could
beat the Danes. As the school story goes the wife warned Alfred to watch
her cakes/scones. Deep in thought about the Danes - "Alfred burnt the
cakes".
During the monastic period it was the monks who taught the locals to
build channels or canals to drain the soil - leaving behind superb land
for grazing cows - making Somerset a haven for dairy herds. Back in the
middle ages, the sea or an inlet used to go inland to Creech St. Michael
where I lived, some thirty miles at least from the N. Somerset coast.
..
Some five miles north of Taunton at Western Zoyland I think - the last
invasion/battle on English soil. The Duke of Monmouth the bastard son
of Charles II, landed on the Dorset coast, moved up to Taunton and was
challenged at W.Z. by the army of James II, (his 'uncle'). Carted back
to Taunton, the rebels were quickly tried and hanged on the orders of
the notorious Judge Jeffreys. Jeffreys figures in 'Lorna Doone'.
Monmouth was initially taken east over-nighting at Guildford, county
town of Surrey, and then on to the Tower "where they done 'im in" -
probably the axe.
The county has a very silent history, like much of UK. You pass through
some nondescript place and don't realize its connection with the past.
>Unless you were talking about the Somerset that the Boerne Greyhounds
>football team used to play against back in the 1950's, which I visited a few
>times as a member of the Boerne High School Marching Band ... Nice town, I
>guess, but "beloved?" ;-)
>
>
>
No I don't think so. A discordant off-tone School Marching Band in
England back in my time - so terribly gauche.
>I didn't pick up the usage from either of these locations, by the way, but I
>don't know where; most likely, I think is the quote "I doubt me an it be
>commercial" from a Flanders & Swann bit about (as I recall) the origins of
>Greenfleeves.
>
>
>
Can't remember but Flanders and Swann, were they the pair who sang "I'm
a ger-noo (Gnu) "
> -Chuck Stevens
>
>
>
>
Serious note. It hit me this morning. Why SortedCollections don't figure
in the proposal. Using your open mind, follow this one through. I told
you I got that ListRecord class to work; I sent you a copy. Now take a
p at what I sent you. Remember it's an object - so how would you sort
it. Can be done - but long-winded. "Nah ignore it. Folks can worry about
sorting later if they must". *I will be covering the point in some detail !*
Jimmy, Calgary AB
| |
| Robert Wagner 2004-08-27, 3:55 am |
| On Thu, 26 Aug 2004 17:53:40 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:1j1si05tv3jdi13t2j0lchj0e9u3kkjg0e@
4ax.com...
>
>
>And what would you expect "if you do <x> the expected results are <y>" to
>imply if you refuse to follow the constraints of <x>? Perhaps I have
>misunderstood what "conformance to a standard" means.
It would be nice if they'd allocated two bits and defined four values
as 10967, 559, native and unknown. They had the arrogance to name the
indicator ISO, which implies 559 is not an ISO standard.
>across
[color=darkred]
>IEEE 754 in its current form does *not* specify a *single* format of
>*high-precision* floating-point. It specifies a whole range of them, all
>equally valid. That's my point.
Yes, you've made that point. I meant IEEE generically. Its 32-bit and
64-bit versions are in current hardware; extended formats generally
are not.
>
>What you haven't demonstrated is that every implementation of C++ has a
>"long double"
I didn't say they did; I said the ISO C++ standard has a long double
AND claims to be compliant with 10967. The C++ standard committee
found 10967 extended format adequate. This document explicitly says
"extended" for long double, not for the others.
http://www.research.att.com/~bs/glo...ting-point-type
http://www.research.att.com/~bs/iso_release.html
>
>And each went their own way. That's precisely my point.
Machines designed after 1985 went with IEEE. They did not go their own
way.
>
>Your citation as an example of an implementation of an IEEE 754 format, with
>all that entails.
It was offered as an example of 128-bit. If I'd read it more
carefully, I wouldn't have used it.
>
>With a design that wasn't defined as part of IEEE 754 until 12 November
>2001?
With the base types that were defined in 1985.
>for
>them
>
>You dispute *what*?
I dispute that floating-point formats are typically defined for the
individual platform. They haven't been since 1985.
>That the Unisys OS/2200 floating-point format isn't the
>same as the IBM System/390 format which isn't the same as the Unisys MCP
>format which isn't the same as the 16-bit Intel format
IBM S/390 now has IEEE 754 hardware support.
> 16-bit Intel format which isn't the same
>as the Sun format which isn't the same as the 32-bit Intel format which
>isn't the same as the 64-bit Intel format?
All those follow IEEE 754.
> Or is it the irrelevance of everything but PC's to the world of COBOL these days?
On the Top 500 computer list, 93% are based on Intel, Power, HP, AMD
or Alpha. For instance, the Thunder system at Lawrence Livermore
delivers 20 teraflops from 4K Intel Itaniums chewing on IEEE 754
numbers.
Granted, that's not a likely Cobol machine. But high-end servers from
Sun and HP costing $2M are candidates, as are millions of mid-range
servers.
None of these machines are PCs.
>I'm sorry, but their "double-extended" isn't 128-bit (best I can tell, it
>might be as high as 84 bits.)
I didn't site these sources to show a 128-bit implementation; I cited
them to show that chip manufacturers are serious about following IEEE
754. They don't go their own way. They do not define floating-point
formats for each platform.
| |
| James J. Gavan 2004-08-27, 3:55 am |
| Chuck Stevens wrote:
[color=darkred]
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:0vhri01rque18qvh61ol9omu16qmhv9520@
4ax.com...
>
>
>
Don't know about their sexual preferences - but I agree I didn't find
them funny either. In slapstick mode I did somewhat enjoy John Cleese in
'Fawlty Towers', occasionally. Same goes for the David Frost group
TWTWTW (That Was The W That Was) a bunch of smart-ass ex-university
types from Oxbridge showing us how terribly clever they were. Of course
David F, put on a jowl of a look, somewhat like Nixon, and started a
reasonable career interviewing, for what, a couple of decades. Still
does the odd interview I believe.
It might have been some of the same, but there was a group early fifties
that did a stage show. Remember the 'Uncle Tom's Cabin, Siamese ballet
in R & H's "King and I" There's a chorus line in the original "Poor
little Eliza", referring to the bastard daughter ?.
They really spoofed that one, complete accentuated Siamese hand
movements and hopping across the stage. "Poor Little Eliza" became "Poor
little basket" (bastard)..
But recently returned from RAF in Egypt in '54, I was 'starved' for
some sort of culture. For about three months simmersed myself in theatre
in London, waiting patiently on a Saturday night at ticket offices until
there were cancellations and then getting in at half price.
"Love of Four Colonels". Written, produced, and acted by Peter Ustinov
playing the Devil. He enticed four Allied Lt. Cols. in Berlin to seduce
the heroine played by an attractive blonde Australian actress, Moira
Lister. Each colonel picked his own environment, the Russkie - Chekhov,
the Brit - Tudor, the Frenchman - Louis XIV and the Yank - a 'thirties
speak easy. Incredibly funny and absolutely brilliant Ustinov of course.
Shame you probably never had it in the States. I know Archie Bunker
became an icon, but its British model, "Till Death Do Us Part" or am I
using the American title ? The lead was played by British/Jewish actor
Warren ???, mum probably only had about four lines in any one session.
Would gaze up from her knitting, and right in the middle of a heated
topic, would utter something tototally iirrelevant like, "Oh look. The
weather's changing". The son-in-law had one of those bubble cuts of the
sixties and Alf referred to him as Shirley (Temple). Yes he was a
blue-collar conservative from Dockland, and as I said Jewish, would make
utterances like "Yeah then there's your bleedin' 'Arold Wilson. Look all
them bleedin' Jews, catholics. Not only that, then again there's all
those bleedin' blacks taking over the Queen's realm". In mid-sentence
Alf is interrupted by a knock at the door, still cursing, throws it open
to be confronted by a smiling Negro parson collecting for some charity !.
Jimmy, Calgary AB.
| |
|
|
| Chuck Stevens 2004-08-27, 3:55 pm |
| "James J. Gavan" <jjgavan@shaw.ca> wrote in message
news:QbyXc.224953$J06.87842@pd7tw2no...
> Don't know about their sexual preferences - but I agree I didn't find
> them funny either. In slapstick mode I did somewhat enjoy John Cleese in
> 'Fawlty Towers', occasionally. Same goes for the David Frost group
> TWTWTW (That Was The W That Was) a bunch of smart-ass ex-university
> types from Oxbridge showing us how terribly clever they were. Of course
> David F, put on a jowl of a look, somewhat like Nixon, and started a
> reasonable career interviewing, for what, a couple of decades. Still
> does the odd interview I believe.
Although I admit I did enjoy the irreverence of Monty Python, I preferred
the rather more urbane sort of British humo(u)r reflected in (in reverse
chronological order) Beyond the Fringe, Flanders & Swann, and the Hoffnung
Music Festivals. I'd count Anna Russell in there too, except that I believe
she was an Australian phenomenon. In my youth, even Victor Borge was often
too broad for my taste.
As to John Cleese and Fawlty Towers: During my childhood, my home was a
26-room ex-stagecoach-stop hotel that my parents owned and ran in a small
town in Texas, and a *great deal* of the humor in that program hit *very*
close to home. I believe I have the entire series on tape somewhere. My
mother was nowhere near social enough for the "oh, I know..." telephone
conversations, but the antics of the "help" in particular were spot-on.
-Chuck Stevens
| |
| docdwarf@panix.com 2004-08-27, 3:55 pm |
| In article <cgnqrs$1vsr$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
[snip]
>In my youth, even Victor Borge was often
>too broad for my taste.
No, wait, wasn't it Milton Berle who used to dress in women's clothes?
Oh... different kind of 'too broad', never mind.
DD
| |
| Chuck Stevens 2004-08-27, 8:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:jm8ti01aeo3igm42n2d2ole964csm8k3v7@
4ax.com...
> On Thu, 26 Aug 2004 17:53:40 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
>
> It would be nice if they'd allocated two bits and defined four values
> as 10967, 559, native and unknown. They had the arrogance to name the
> indicator ISO, which implies 559 is not an ISO standard.
It's not. It's an *IEC* standard.
> ... intermediate conversation elided for brevity ...
> ... I meant IEEE generically. Its 32-bit and
> 64-bit versions are in current hardware; extended formats generally
> are not.
And that brings us back to my point that the 2002 standard requires 31-digit
precision for all numeric data items that have PICTURE clauses, which makes
the 32-bit and 64-bit formats unusable for manipulating values at that
precision level.
And you've already gone on record as being *adamantly* opposed to using
anything but DISPLAY numeric for any sort of data exportation from or
importation into COBOL programs on grounds of portability. If 32-bit
formats are virtually useless *within* the COBOL program, and they're to be
eschewed as visible elements *from or to* a COBOL program, what does COBOL
need with them?
> I didn't say they did; I said the ISO C++ standard has a long double
> AND claims to be compliant with 10967. The C++ standard committee
> found 10967 extended format adequate. This document explicitly says
> "extended" for long double, not for the others.
What the C++ user community directs the standards committee for C++ to
incorporate and to treat as adequate in that environment is entirely
orthogonal to what the COBOL community directs the standards committee for
COBOL to treat as adequate.
The COBOL community has made it abundantly clear to the standards committee
that the standard requirement that PICTUREs for numeric items provide for no
more than 18 digits (ANSI X3.23-1974) was an onerous limitation to them, and
the 2002 standard provides for 31.
>
> Machines designed after 1985 went with IEEE. They did not go their own
> way.
Machines designed after 1985 *still* don't have a single basic portable
floating-point format capable of meeting the needs of the COBOL community.
And I would have to say there are *plenty* of machines designed after 1985
that neither went their own way nor went with IEEE. What many of them did
was provide additional capabilities within a given *architecture*.
I remember the stories of IBM introducing the large-scale 704 system as
their answer for the *scientific* community, and the large-scale 705 system
for the *business* community. The 705 was fairly successful, and it went
through two more generations enhancing capability. When the second
generation was introduced, the 704/709 architecture lived on in the
7040/7090, but IBM introduced the entirely-incompatible 7070 as the
replacement for the 705. Existing 705 customers stayed away in droves,
forcing IBM to rush the 7080 (which had 705-compatibility switches on its
console) to market in record time.
I personally think it's a Really Bad Idea for a manufacturer to turn its
back on an existing customer base or to force a user to abandon an existing
library of his programs with which he is otherwise quite satisfied.
While many (and I daresay not all!) new *architectures* may have
incorporated hardware support for 32-bit and 64-bit basic floating-point
formats, if they're not suitable for internal use within COBOL, there's not
a whole lot of incentive for the *COBOL* standard to "bless" them as an
attractive new feature for that language! What's the attraction?
> It was offered as an example of 128-bit. If I'd read it more
> carefully, I wouldn't have used it.
You're responsible for that choice!
> With the base types that were defined in 1985.
The term "base type" does not appear in IEEE 754. The term "base" is used
in IEEE 754 only to describe the number base used for the representation.
The 128-bit format is not a *basic format* in 1985, it's a possibility from
among the myriad possible *extended formats*. IEEE 754 doesn't
characterize the 128-bit format as a "base type", and I'd say goes to rather
significant lengths to indicate otherwise, both for the general and the
specific cases.
> I dispute that floating-point formats are typically defined for the
> individual platform. They haven't been since 1985.
Are you *truly* insisting that the floating-point formats designed decades
ago for the Burroughs Large System, the IBM 360, the Univac 1108, and other
platforms whose architectures continue to attract new customers to this day
*ceased to exist as defined formats* in 1985?
> IBM S/390 now has IEEE 754 hardware support.
Goody for them. The 32-bit and 64-bit formats are *still* not adequate for
31-digit COBOL arithmetic.
> All those follow IEEE 754.
The other question I have is whether they also follow IEEE 854, and the
various ISO and IEC standards *already published*.
these days?[color=darkred]
>
> On the Top 500 computer list, 93% are based on Intel, Power, HP, AMD
> or Alpha. For instance, the Thunder system at Lawrence Livermore
> delivers 20 teraflops from 4K Intel Itaniums chewing on IEEE 754
> numbers.
>
> Granted, that's not a likely Cobol machine. But high-end servers from
> Sun and HP costing $2M are candidates, as are millions of mid-range
> servers.
> None of these machines are PCs.
Are any of them capable of the 32-digit arithmetic that COBOL requires (and
COBOL requires it because *users* demanded it)?
> I didn't site these sources to show a 128-bit implementation; I cited
> them to show that chip manufacturers are serious about following IEEE
> 754. They don't go their own way. They do not define floating-point
> formats for each platform.
Being serious about IEEE 754 isn't necessarily the same as being serious
about meeting the needs of the large financial institution or the large
manufacturer. Or of the average COBOL user.
32-bit and 64-bit basic binary floating-point formats from IEEE 754 might be
a "nice touch" for standard COBOL, but doesn't add functionality as far as
I'm concerned. The implementor of COBOL for a given platform is *today*
free to use these formats for USAGE FLOAT-SHORT, FLOAT-LONG and/or
FLOAT-EXTENDED -- or to *not* use them for those USAGEs -- *whether or not
the target platform provides hardware support for these formats*.
As for BINARY-CHAR, BINARY-SHORT, BINARY-LONG and BINARY-DOUBLE, what each
of these is understood to mean in a given environment in COBOL or otherwise
is frequently defined in terms of the word length of the individual
*platform*. This means that what is BINARY-LONG on one machine may be
BINARY-SHORT on another. And what I read of C++, the same is true there.
The only formal movement I've seen toward the adoption of IEEE-style
floating-point formats *in language standards* is in the current draft for
the next FORTRAN standard.
Now that a single 128-bit binary floating-point format is *on its way* to
becoming formally standardized, I personally would think adding support for
these formats *as a syntactic addition to* the language would be worthwhile,
and will probably end up pursuing it for a future standard.
But as it is, any implementor on a platform is free to define the three
standard floating-point formats provided by the language as defining items
in IEEE formats -- or not -- as they see fit or as their users demand. They
are also free to provide syntax in the language describing the three IEEE
formats in implementor-defined extensions -- or not -- as they see fit or
as their users demand.
As to standardization in other languages, I see the following in an on-line
C++ reference:
<<The size and range of any data type is compiler and architecture
dependent. The "cfloat" (or "float.h") header file often defines minimum and
maximum values for the various data types. You can use the sizeof operator
to determine the size of any data type, in bytes. However, many
architectures implement data types of a standard size. ints and floats are
often 32-bit, chars 8-bit, and doubles are usually 64-bit. bools are often
implemented as 8-bit data types.>>
"Often" is not "always", even in standard C++, as I see it. In a
(hypothetical) machine with addressibility at 64-bit boundaries, does a
32-bit int (or BINARY-SHORT) really make all that much sense? The extra
cost that might be incurred by arithmetic involving a BINARY-LONG instead of
a BINARY-SHORT might actually be offset by the cost of retrieving the
half-word item! I have seen the Intel architecture go from 16 to 32 to 64
bits. How long will it be before the "native word length" for commodity
hardware becomes 128 bits, and thus the logical format for a "long
double-precision item" occupies 512 bits?
-Chuck Stevens
| |
| Richard 2004-08-27, 8:55 pm |
| "James J. Gavan" <jjgavan@shaw.ca> wrote
> Don't know about their sexual preferences - but I agree I didn't find
> them funny either. In slapstick mode I did somewhat enjoy John Cleese in
> 'Fawlty Towers', occasionally.
It is probably a generational thing. My father doesn't much like
Monty Python either. Nor did he like the Rolling Stones. There was a
complete change in the 60s for most of us. You either liked Bing
Crosby _or_ Monty Python.
> Same goes for the David Frost group
> TWTWTW (That Was The W That Was) a bunch of smart-ass ex-university
> types from Oxbridge showing us how terribly clever they were.
The 'David Frost' group was primarily John Cleese and 'The Two
Ronnies', though they were relative unknowns at the time. Before
Monty Python that lot were a stage 'review' called 'Cambridge Circus'
referring to their University days (which I went to).
| |
| JerryMouse 2004-08-27, 8:55 pm |
| Chuck Stevens wrote:
>
> As to John Cleese and Fawlty Towers: During my childhood, my home
> was a 26-room ex-stagecoach-stop hotel that my parents owned and ran
> in a small town in Texas, and a *great deal* of the humor in that
> program hit *very* close to home. I believe I have the entire series
> on tape somewhere. My mother was nowhere near social enough for the
> "oh, I know..." telephone conversations, but the antics of the "help"
> in particular were spot-on.
Still, Monty Python has gotten into the psyche.
Some ornithological group in Australia had a long-standing reward for a
specimen of the Australian Night Parrot (whose last sighting was in, like,
1927).
A few years ago, some birders stopped alongside the road for a 'nature
call.' There, at the feet of one, was a dead Australian Night Parrot.
They turned the carcass of the dead parrot in for the reward.
The curator (or factotum) of the society offering the reward said: "This is
straight out of the Monty Python 'Dead Parrot' skit!"
| |
| Donald Tees 2004-08-29, 8:55 am |
| James J. Gavan wrote:
> OK - maybe it's more the Blues perhaps - I dunno. I definitely like
> Stephane Grappelli, (at least when I heard him on BBC Radio - but of
> course that means I haven't heard him for years). I'm also thinking of
> improvisors at the piano keyboard - don't like them much either, tinkle,
> tinkle this end of the keyboard, then same sequence at the other end -
> bores me to tears.. Now Oscar Levant playing Gershwin , and perhaps a
> little bit of improvisation - great.
>
> Jimmy, Calgary AB
Take a listen to Art Tatum one day Jimmy.
Donald
| |
| Donald Tees 2004-08-29, 8:55 am |
| LX-i wrote:
> Donald Tees wrote:
>
>
>
> It's about the total package, man... :)
>
>
Thats the problem ... the total package is the package. The media is the
message is not always a *good* thing.
Donald
| |
| docdwarf@panix.com 2004-08-29, 3:55 pm |
| In article <05j2j09ksklj1kf7b66f95nbfksrq3gndr@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 28 Aug 2004 20:58:40 -0400, docdwarf@panix.com wrote:
>
>
>I wish your understanding of art in music extended to programming.
Mr Wagner, 'understanding' is much like anything else in that just because
one cannot see it does not translate into its lack of existence.
DD
| |
| docdwarf@panix.com 2004-08-29, 3:55 pm |
| In article <7VcYc.254062$J06.91749@pd7tw2no>,
James J. Gavan <jjgavan@shaw.ca> wrote:
>docdwarf@panix.com wrote:
>
[snip]
[color=darkred]
[snip]
[color=darkred]
>OK - maybe it's more the Blues perhaps - I dunno. I definitely like
>Stephane Grappelli, (at least when I heard him on BBC Radio - but of
>course that means I haven't heard him for years). I'm also thinking of
>improvisors at the piano keyboard - don't like them much either, tinkle,
>tinkle this end of the keyboard, then same sequence at the other end -
>bores me to tears.. Now Oscar Levant playing Gershwin , and perhaps a
>little bit of improvisation - great.
Your taste becomes clearer, Mr Gavan... improvising can be thought of as a
spice added to the dish of music (synaesthesia, anyone?); Mozart was
well-known for taking a melody and taking off with it... much of his
piano-work was never transcribed to paper because he would show up for
concerts without any sheet music and just... *go*, you might want to
listen to his Theme and Variations K.265 ('Twinkle, Twinkle, Little Star')
while thinking of it as 18th Century jazz.
As with any spicing... some like more, some less. Stephane Grapelli might
cause you to smile while Lenny Tristano might drive you from the table to
s solace in other fare... de gustibus non desputandum est and yet...
what a Wonderful World it is that has New Food in it!
DD
| |
| Warren Simmons 2004-08-29, 3:55 pm |
| James J. Gavan wrote:
> Warren Simmons wrote:
>
>
>
> Answer Me Oh Lord Above ? Remember him. Tell me Warren, I mentioned Vera
> Lynn as the UK 'Forces Sweetheart" during WWII. There has to be an
> American equivalent, but can only think of Betty Grable the pin-up girl.
> The nearest she came to music was she was married to band leader .....?
>
> GI Joe in India ? You weren't there helping Errol Flynn to win the
> friggin' Battle of Burma were you :-) Were you special forces or just
> there to ensure the British Indian Army was doing a pukka job. I say old
> chap, you mustah had a decent cup of tea from a shai wallah. (Still
> that's Egypt - perhaps shai is different in Hindi). On the old BBC radio
> "Goon Show", Peter Sellers - he was in India during WWII, used to
> occasionally throw in a few lines of "Oh the cages in Bombay.....".
> Those in the know in the studio audience would roar with laughter. He
> was referring to hookers hung, ready for sale in wicker baskets.
>
> Ah Nat - Mr Mellow - that voice which was like a smooth glass of sherry
> going down your throat.
>
> Jimmy
>
Gee, Jimmy, don't go overboard on me. I saw Calcutta upon, landing,
flew to Ledo to help set up tents for the rest of the gang who came
by train...more like a w or two. Volunteered to drive a truck to
Kunming to deliver same to the Chinese, flew back over the hump to
Ledo, and traveled as the shotgun on another convoy to reach a station
in China. Though trained to be a central office repairman, our battalion
replaced the Brits who had been there three years or more, and all I did
for the balance of my duty was drive a six by six on sundry and various
assignments. Once back in India we flew to DumDum in Calcutta and stayed
there until our ship for home was ready. My trip over took 40 days and
went by way of Australia, then to Calcutta. On the ride home, the
trip took 30 days, and the sailors on that ship had fewer days on the
high seas than I had.
I did take a tour of Calcutta, got caught in a riot, and spent two ws
in camp awaiting the trip home which took us passed some big places and
stopped in Manila (out in the bay) then to Seattle before train to
Indiana, and home by bus to Gary. Dad picket me up.
While in China, I played the guitar in a combo that played for the
Officers Club on Sunday afternoons, and at the Hospital on Saturday
nights fo | | |