For Programmers: Free Programming Magazines  


Home > Archive > Cobol > September 2004 > Re: Classic RW









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 Re: Classic RW
William M. Klein

2004-08-31, 8:55 pm

Actually, what wouldn't bother me is if RW stated,

"Most implementations store fixed-point numbers the same way they store
integers - but the compiler also stores its scaling factor to insure proper
handling of the DIFFERENCE between integers and non-integer fixed point numbers"

Of course, it is also true that the statement

"It is stored in memory as '0345', if decimal, or 0159, if binary/hex."

isn't true of any operating system that I know of. All the ones that I have
worked with actually store ALL data (and instructions) in "binary". Therefore a
data field with a value of "3.45" can be stored in a number of ways (depending
upon the PICTURE clause, USAGE, etc - if it is stored by a COBOL program).
Consider:

01 Num-Disp Pic 9v99 Value 3.45 Usage Display.
probably stores it as B"111100111111010011110101" (if my calculations are
right - which they may not be) for an EBCDIC environment.

and don't ask me what it would store it as for
01 Num-Nat Pic 9v99 Value 3.45 Usage National.

And compare this to (again, my calculations may be in error)

01 Num-S-Disp Pic S9v99 Value +3.45 Usage Display.
probably stores it as B"111100111111010011000101"

and

01 Num-Sep-Disp Pic S9v99 Sign is trailing separate Value 3.45 Usage Display.
probably stores it as B"11110011111101001111010101001110

The chances are that the same bit-pattern might be interpreted (depending upon
"environment") as:
- an instruction sequence
- an integer
- a character string
- probably other things

Therefore, saying that a fixed-point data value is "stored" as an integer may
(or may not) be true but
- doesn't really mean much (as the storage could mean other things as well)
- still has NO relevance to any statement claiming that a "fixed-point item IS
an integer item"

P.S. For those (referring to the subject of this thread) who don't understand
why some people have problems with RW's posts, it is simply that when he is
wrong (and simply WRONG) he has such difficulty in admitting it. If he simply
admitted his errors and said,
"sorry about that, what I really meant to say was ..."
or
"sorry for my mistake, you're right and I was wrong"

then I think his posts (correct and erroneous) would get much better reception.
This thread is simply a "classic" example of his refusal to admit that his
original statement (clear, and simple) that

"They <fixed-point items> are integers"

was WRONG (is wrong and always will be wrong)

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ch2fnh$2f7$1@si05.rsvl.unisys.com...
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:8ue9j05arsd8h5jhknobv9a46pur41tfhc@
4ax.com...
>
>
> Last time I looked, "is", "is treated as" and "is stored in memory as"
> aren't synonymous. I believe I've pointed that out before. What you
> wrote was "All fixed-point numbers are integers."
>
> If what you *really* meant was "All implementations of my acquaintance store
> fixed-point numbers in memory as integers", then I'd suggest that that's
> what you should have written. I wouldn't have a quibble with that. Even
> the shorthand "Most implementations store fixed-point numbers as integers"
> doesn't rankle. The standard doesn't require this, however.
>
> I know environments in which integers, fixed-point and floating-point data
> items are "stored in memory" identically; the only differentiation among
> them is how they are handled and treated. In that environment, in fact,
> there is no requirement that integer data actually *be* in "canonic integer
> form"; a normalized floating-point representation of the value serves
> equally well and is just as exact a representation. Thus, in that
> environment, a fixed-point numeric value may be stored, *not* as an integer
> defined for that implementation, but as a *floating-point* item that happens
> to have an exact value. So I would take exception to the elision of "of my
> acquaintance" because it would demonstrably turn the statement from "true"
> to "false".
>
> How something is *handled* and how something are *stored* may be entirely
> orthogonal to what something *is*.
>
> -Chuck Stevens
>
>



Lueko Willms

2004-09-01, 3:55 am

.. Am 31.08.04
schrieb wmklein@nospam.netcom.com (William M. Klein)
auf /COMP/LANG/COBOL
in x76dnbUkvvDZUqncRVn-sg@comcast.com
ueber Re: Classic RW

WMK> Of course, it is also true that the statement
WMK>
WMK> "It is stored in memory as '0345', if decimal, or 0159, if
WMK> binary/hex."
WMK>
WMK> isn't true of any operating system that I know of. All the ones that
WMK> I have worked with actually store ALL data (and instructions) in
WMK> "binary".

WMK> 01 Num-Disp Pic 9v99 Value 3.45 Usage Display.
WMK> probably stores it as B"111100111111010011110101" (if my
WMK> calculations are right - which they may not be) for an EBCDIC
WMK> environment.

Don't try to appear so dumb. It is clear from the context that
Robert Wagner meant the byte-or half-byte-wise representation in
hexadecimal. What else do you make of "binary/hex"?


Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
William M. Klein

2004-09-01, 3:55 am

I thought he was talking about the difference between how you "store"

05 Num-Bin Pic S9v99 Binary +3.45.
versus
05 Num-Disp Pic S9v99 Display +3.45.

As I didn't "de-compose" "0159" (and it didn't happen to have A-F "nibbles") I
just didn't think of the other interpretation of what he might have meant.

--
Bill Klein
wmklein <at> ix.netcom.com
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9FvwA7s9flB@jpberlin-l.willms.jpberlin.de...
>. Am 31.08.04
> schrieb wmklein@nospam.netcom.com (William M. Klein)
> auf /COMP/LANG/COBOL
> in x76dnbUkvvDZUqncRVn-sg@comcast.com
> ueber Re: Classic RW
>
> WMK> Of course, it is also true that the statement
> WMK>
> WMK> "It is stored in memory as '0345', if decimal, or 0159, if
> WMK> binary/hex."
> WMK>
> WMK> isn't true of any operating system that I know of. All the ones that
> WMK> I have worked with actually store ALL data (and instructions) in
> WMK> "binary".
>
> WMK> 01 Num-Disp Pic 9v99 Value 3.45 Usage Display.
> WMK> probably stores it as B"111100111111010011110101" (if my
> WMK> calculations are right - which they may not be) for an EBCDIC
> WMK> environment.
>
> Don't try to appear so dumb. It is clear from the context that
> Robert Wagner meant the byte-or half-byte-wise representation in
> hexadecimal. What else do you make of "binary/hex"?
>
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> "Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
> Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)



Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com