Interesting Article I ran across on Hacker News:
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL: https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
Interesting Article I ran across on Hacker News:
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL: https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components >written in any language that implements the COM interface.
I don't think COBOL has any real advantage over anything else in this >regard.--- Synchronet 3.20a-Linux NewsLink 1.114
The "performance hit" she describes for loading a library to support
decimal would only happen if the library was loaded dynamically, it has
no more impact if it is statically linked than compiled COBOL has.
Pete.
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components
written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Clark Morris
I don't think COBOL has any real advantage over anything else in this
regard.
The "performance hit" she describes for loading a library to support
decimal would only happen if the library was loaded dynamically, it has
no more impact if it is statically linked than compiled COBOL has.
Pete.
On 07/30/2018 10:06 AM, Clark F Morris wrote:
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components >>> written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Clark Morris
I don't think COBOL has any real advantage over anything else in this
regard.
The "performance hit" she describes for loading a library to support
decimal would only happen if the library was loaded dynamically, it has
no more impact if it is statically linked than compiled COBOL has.
Pete.
Most people think 4 decimal places are enough for all money, but
that isn't necessarily true. :-)
bill
It is fun to explain to a Java programmer about packed decimal.
Generally, when they finally understand it, they are quite impressed by it.
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components
written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
On 7/28/2018 9:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL: https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
That was a fun read!Apparently somebody saw the need. There's now a java.math.BigDecimal class. (I'm not tryng to start a language war; I still believe that a common business-oriented language, on hardware with a commercial instruction set, will generally do business computation faster than Java.)
It turns out that COBOL fixed-point arithmetic is actually pretty
convenient for business accounting, and the Java programmers had no idea.
Just wait 'til they find out about block-mode I/O.Luckily, they have: the java.nio package was introduced in JDK 1.4.
On 31/07/2018 5:36 AM, Bill Gunshannon wrote:
On 07/30/2018 10:06 AM, Clark F Morris wrote:I have never needed more than that for handling Dollars or Pounds, but possibly for statistical reporting on currencies like Rupees or Pesos,
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point >>>> to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM
components
written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Clark Morris
I don't think COBOL has any real advantage over anything else in this
regard.
The "performance hit" she describes for loading a library to support
decimal would only happen if the library was loaded dynamically, it has >>>> no more impact if it is statically linked than compiled COBOL has.
Pete.
Most people think 4 decimal places are enough for all money, but
that isn't necessarily true. :-)
bill
where numbers can be very large...
I'd be interested to see any (real life, not theoretical...) examples
you may have where it isn't enough.
Pete.
On 07/30/2018 09:32 PM, pete dashwood wrote:Looks like the plot from Superman III.
On 31/07/2018 5:36 AM, Bill Gunshannon wrote:
On 07/30/2018 10:06 AM, Clark F Morris wrote:I have never needed more than that for handling Dollars or Pounds, but possibly for statistical reporting on currencies like Rupees or Pesos, where numbers can be very large...
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point >>>> to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM
components
written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Clark Morris
I don't think COBOL has any real advantage over anything else in this >>>> regard.
The "performance hit" she describes for loading a library to support >>>> decimal would only happen if the library was loaded dynamically, it has >>>> no more impact if it is statically linked than compiled COBOL has.
Pete.
Most people think 4 decimal places are enough for all money, but
that isn't necessarily true. :-)
bill
I'd be interested to see any (real life, not theoretical...) examples
you may have where it isn't enough.
Pete.
It's probably old enough to not even be findable on the
WayBack Machine but there was a news story that made the
rounds on USENET back before the INTERNET was even a dream
about a COBOL Programmer in NYC working for a very large
and well known bank. While programming some of their
accounting software he asked what to do with the
computations beyond mils. He was told "We don't care."
He proceeded to add them to his own personal account.
When you are dealing in millions of dollars a day it
is more than you might think. He got fired. And I doubt
he got to keep the money. He was not charged with theft
as he did what he was told. It was considered unethical,
however. I am sure today financial institutions track
all of it to many decimal places. One hundreth of a
mil (.000001) on a trillion dollars is still $100,000.
bill
On Tuesday, July 31, 2018 at 8:07:01 AM UTC-4, Bill Gunshannon wrote:
On 07/30/2018 09:32 PM, pete dashwood wrote:
On 31/07/2018 5:36 AM, Bill Gunshannon wrote:
On 07/30/2018 10:06 AM, Clark F Morris wrote:I have never needed more than that for handling Dollars or Pounds, but
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point >>>>>> to 4 places does very nicely in all of the commonly used languages. >>>>>>
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM
components
written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not >>>>> have been accurate enough for at least one of my COBOL programs.
Clark Morris
I don't think COBOL has any real advantage over anything else in this >>>>>> regard.
The "performance hit" she describes for loading a library to support >>>>>> decimal would only happen if the library was loaded dynamically, it has >>>>>> no more impact if it is statically linked than compiled COBOL has. >>>>>>
Pete.
Most people think 4 decimal places are enough for all money, but
that isn't necessarily true. :-)
bill
possibly for statistical reporting on currencies like Rupees or Pesos,
where numbers can be very large...
I'd be interested to see any (real life, not theoretical...) examples
you may have where it isn't enough.
Pete.
It's probably old enough to not even be findable on the
WayBack Machine but there was a news story that made the
rounds on USENET back before the INTERNET was even a dream
about a COBOL Programmer in NYC working for a very large
and well known bank. While programming some of their
accounting software he asked what to do with the
computations beyond mils. He was told "We don't care."
He proceeded to add them to his own personal account.
When you are dealing in millions of dollars a day it
is more than you might think. He got fired. And I doubt
he got to keep the money. He was not charged with theft
as he did what he was told. It was considered unethical,
however. I am sure today financial institutions track
all of it to many decimal places. One hundreth of a
mil (.000001) on a trillion dollars is still $100,000.
bill
Looks like the plot from Superman III.
Here's an article that discusses this type of scam.
< https://filmschoolrejects.com/getting-rich-with-richard-pryors-banking-scheme-from-superman-iii-7811840a8a0/ >
Of note is this:
"What about all those fractions of cents?
"Banks and corporations don’t simply truncate the final value,
as Gus’s colleague suggests in Superman III. Instead, the
numbers are preserved internally to five or six decimal places.
Then the value is rounded rather than truncated when a check
is cut or a deposit is made. That means that instead of just
chopping off those fractions of a cent, they round up or down
to the nearest cent."
That is, a claim of "five or six decimal places".
On 31/07/2018 2:06 AM, Clark F Morris wrote:
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<dashwood@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components >>> written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Can you share more details, Clark?
I have worked in a number of Banks and never seen a use case where more
than 4 decimals were required for transactions in real currency (not >management reporting).
I don't doubt what you say, but I'd be interested to see why 4 was not >enough...
Pete.--- Synchronet 3.20a-Linux NewsLink 1.114
<snipped>
On Mon, 30 Jul 2018 12:10:55 +1200, pete dashwood
<d.....@enternet.co.nz> wrote:
On 29/07/2018 2:29 PM, John McCue wrote:
Interesting Article I ran across on Hacker News:It is indeed interesting.
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
However, for commercial applications dealing with currency, fixed point
to 4 places does very nicely in all of the commonly used languages.
S9(14)v9(4) represents (in COBOL) the "Currency" type for COM components >written in any language that implements the COM interface.
PL/1 also has provision for fixed point. 4 decimal places would not
have been accurate enough for at least one of my COBOL programs.
Interesting Article I ran across on Hacker News:
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL: https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
A great article! Reminds me that Intel stopped support for BCD in 64bit code. Current microprocessors support BCD in 32-bit mode only. I wonder what effect this might have on COBOL implementations for x86.
Mayer
On Sunday, July 29, 2018 at 5:29:05 AM UTC+3, John McCue wrote:
Interesting Article I ran across on Hacker News:
Tiny URL: https://tinyurl.com/y9mjyoqe
Real URL:
https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
John
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,030 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 23:21:58 |
| Calls: | 13,346 |
| Calls today: | 3 |
| Files: | 186,574 |
| D/L today: |
1,716 files (461M bytes) |
| Messages: | 3,357,692 |