# COBOL and Julia comparison

**URL:** <https://discourse.julialang.org/t/cobol-and-julia-comparison/49166>\
**Category:** Numerics\
**Created:** [October 28, 2020, 9:08am UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166 "2020-10-28T09:08:33Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![bocc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bocc/32/7546_2.png) [@bocc](https://discourse.julialang.org/u/bocc)\
**Post date:** [October 28, 2020, 9:08am UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/1 "2020-10-28T09:08:33Z")

</div>

Hello,

I’d like to state in advance that I have negligible familiarity with number representations, so please excuse any inaccuracies. I also enjoy getting rid of legacy systems.

I have recently read [an article](https://medium.com/the-technical-archaeologist/is-cobol-holding-you-hostage-with-math-5498c0eb428b) which pointed out that one of the reasons COBOL is still somewhat prevalent in the banking and governmental sectors is that it used fixed point number representations, which are less prone to accumulating inaccuracies during the typical calculations these sectors use. (There are other factors of course as many languages let you use fixed point numbers with varying levels of difficulty by now.)

This article describes Muller’s recursion formula, which is a good example of this erratic behavior. This series should converge to 5, but using doubles it converges to a 100, after some hectic jumps. I wanted to try this with Julia’s types, so I wrote this code.

```julia
module cobol

using FixedPointNumbers

mullers(y,z) = 108 - (815 - 1500/z)/y

function recur(t,n)
    v = zeros(t, n)
    v[1:2] .= t[4, 4.25]

    for ii = 3:n
        v[ii] = mullers(v[ii-1], v[ii-2])
    end

    v
end

end # module

```

For `Float64` it reproduces the behavior of other languages, as expected. With `BigFloat` it properly converges to 5. With `Rational` (`Float64.(recur(Rational,20)`) it also converges to 5, but overflows before the double representation would reach it’s fixed point at iteration 29.

What I am interested in (apart from your insights in general) is that by using a fixed point representation `N41f23` it also erroneously converges to 100 (albeit differently than doubles - at least no sign change) - is there a way to do it right with fixed point representation that I haven’t found?

---

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [October 28, 2020, 11:24am UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/2 "2020-10-28T11:24:51Z")

</div>

I have little idea about the problem here, but you likely need to make sure to preserve the types used, otherwise, you’ll calculate all in-between calculations in another number type, and only convert back when writing into the array. See if this fixes it:

```julia
mullers(y::T,z) where T = T(108) - (T(815) - T(1500)/z)/y

```

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 28, 2020, 12:21pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/3 "2020-10-28T12:21:36Z")

</div>

> [@bocc](#):
>
> fixed point number representations, which are less prone to accumulating inaccuracies during the typical calculations these sectors use.

I doubt that this is true. Error _accumulation_ is _typically_ vastly worse with fixed-point calculations than for floating-point calculations. Even simply summing a large list of N numbers accurately is much more difficult with fixed point than with floating point. Moreover, fixed-point arithmetic is vastly more susceptible to catastrophic overflow and requires continual attention to scaling. Muller’s recursion is apparently a carefully crafted exception to the rule (but even there, the article points out that fixed-point also gives the wrong answer if you don’t use a very particular number of iterations).

(This is not to say that floating-point calculations are immune to errors, just that fixed point is usually worse.)

The main advantage I’ve heard cited for fixed-point arithmetic in financial situations is that it represents human decimal inputs exactly, which is important in situations where you have a fiduciary requirement not to convert a `$0.01` deposit into `$0.0100000000000000002081668...`. But this advantage disappears if you use [decimal floating point](https://github.com/JuliaMath/DecFP.jl).

The other advantage of fixed-point arithmetic is that it can be faster; e.g. you used to see a lot of fixed-point signal processing on embedded hardware lacking a floating-point unit. And it’s certainly faster than decimal floating-point on normal CPUs (which lack decimal floating-point hardware). But floating-point performance seems unlikely to be relevant in banking situations where exact decimals are required.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [October 28, 2020, 12:36pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/4 "2020-10-28T12:36:24Z")

</div>

The place where fixed point is really nice is that it has 0 rounding error for addition, subtraction, and multiplication by integers

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 28, 2020, 12:38pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/5 "2020-10-28T12:38:40Z")

</div>

> [@Oscar\_Smith](#):
>
> The place where fixed point is really nice is that it has 0 rounding error for addition, subtraction, and multiplication by integers

So does floating-point arithmetic.

Until your results get too many digits to be represented exactly, of course — at which point floating-point accuracy gradually degrades, whereas fixed-point arithmetic catastrophically overflows.

The idea that _every_ floating-point operation incurs an error is a pernicious myth.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2020, 12:39pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/6 "2020-10-28T12:39:13Z")

</div>

Fixed point is a bit ambiguous. What they mean is like [https://github.com/JuliaMath/FixedPointDecimals.jl](https://github.com/JuliaMath/FixedPointDecimals.jl)

I believe decimal floating-point is relatively new, both as a standard and in hardware (rare), and historically COBOL has used decimal, meaning decimal fixed point, not decimal floating-point. I guess that’s still the case. Who knows if it supports both, by now it’s even object-oriented now (while I doubt much exploited).

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2020, 12:42pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/7 "2020-10-28T12:42:55Z")

</div>

Fixed-point (or integers) do not NEED to overflow (I’m not sure what DECIMAL in COBOL does, maybe you get some Inf value). In a bank, for sure you wouldn’t want owerflow, you could throw an exception (neither ideal, or saturate… for other situations).

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 28, 2020, 12:46pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/8 "2020-10-28T12:46:01Z")

</div>

> [@Palli](#):
>
> Fixed-point (or integers) do not NEED to overflow. In a bank, you wouldn’t want that, you could throw an exception (neither ideal, or saturate… for other situations).

Point taken — but halting the calculation with an exception can still effectively be catastrophic, especially if it occurs frequently. Moreover, in floating-point arithmetic you can raise an inexact exception you want to detect rounding errors as well.

---

<div class="post-metadata">

**Author:** ![lungben](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lungben/32/12314_2.png) [@lungben](https://discourse.julialang.org/u/lungben)\
**Post date:** [October 28, 2020, 12:51pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/9 "2020-10-28T12:51:08Z")

</div>

Banks are not using Cobol because it is better than more modern languages for their purposes, but because it is too difficult / expensive / risky to replace legacy systems 😉

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 28, 2020, 12:55pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/10 "2020-10-28T12:55:41Z")

</div>

> [@bocc](#):
>
> I have recently read [an article](https://medium.com/the-technical-archaeologist/is-cobol-holding-you-hostage-with-math-5498c0eb428b) which pointed out that one of the reasons COBOL is still somewhat prevalent in the banking and governmental sectors is that it used fixed point number representations

The main point of the article seems to be that COBOL has the advantage of having fixed-point arithmetic built in:

> Python (and for that matter Java) do not have fixed point built in and COBOL does. […] If you’ve ever worked on a project with a whole bunch of imports you already know that they are not free. In a language like Java (which is usually what people want to migrate to when they talk about getting rid of COBOL), [the costs of the relevant library can be noticeably higher](https://gist.github.com/hillmanli-seekers/a8ab8e463e7b60989e6d0c0900cf4d93).

(They are citing an article saying that `BigDecimal` is slow compared to `double`, duh.)

I think the relevant point here for Julia is not whether one type of arithmetic is better than another (it depends on the context), but rather that in Julia there is no inherent advantage for “built-in” types, unlike most other languages. The fact that `FixedPointNumbers` are in a package does not inherently make them any slower than the built-in numeric types (which are, in fact, implemented in Julia code). The only limitation is what arithmetic operations the _hardware_ supports vs what operation you are trying to implement.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2020, 12:57pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/11 "2020-10-28T12:57:26Z")

</div>

I guess there’s a reason they introduced decimal-floating point, for banks and/or engineering. I can maybe see the point (pun intended) more for engineering as you just do not want to lose a cent, or more, gradually. There’s no way around that when you do not have enough bits.

But for huge values, the old Lira, and Zimbabwe dollar, decimal-floats are good. Bitcoin also does something clever thinking about values growing.

For the dollar, most individual entries aren’t going to be too big, and even if (would end in lots of zeros) so it might make sense to use DECFP32 to save space, and only DECFP64 for cumulative values?

Julia shouldn’t be overlooked as a COBOL replacement, while I likely think that will happen, not just because people will overlook the best type to use, that’s not in the standard library. Maybe we need a COBOL to Julia transpiler… anyone up for that? They already did (old) Fortran to Julia transpiler for just one library.

---

<div class="post-metadata">

**Author:** ![johnmyleswhite](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnmyleswhite/32/31_2.png) [@johnmyleswhite](https://discourse.julialang.org/u/johnmyleswhite)\
**Post date:** [October 28, 2020, 1:15pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/12 "2020-10-28T13:15:06Z")

</div>

I have to say that I think the original source article is fairly misleading; this is the second time in a few months that I’ve seen people walk away confused by the article. The author doesn’t really provide much evidence that fixed point numbers were better suited for the IRS’s use cases. They simply note that the results were different when the team wrote a naive Java port, then they show in a potentially overfit toy problem that the differences could sometimes go in favor of fixed point, then they wave theirs hands and assert it’s a potential problem that newer languages don’t have fixed point numbers as built-in types.

It all sounds like they just should have staffed the project with someone with real numeric computing experience before trying to port mission-critical numeric code.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [October 28, 2020, 1:29pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/13 "2020-10-28T13:29:00Z")

</div>

I think we’ve gotten off track from the original question here, which was not about fixed- vs floating-point arithmetic but rather on how to reproduce a particular calculation from either COBOL or Python:

> [@bocc](#):
>
> What I am interested in (apart from your insights in general) is that by using a fixed point representation `N41f23` it also erroneously converges to 100 (albeit differently than doubles - at least no sign change) - is there a way to do it right with fixed point representation that I haven’t found?

The problem with this code may be that, in the current release of FixedPointNumbers.jl, `/` and `*` are implemented by [converting to floating point](https://github.com/JuliaMath/FixedPointNumbers.jl/blob/v0.8.4/src/normed.jl#L252-L253), performing the operation, and then rounding back to fixed point.

So, perhaps you want a different arithmetic operation; maybe someone who is more familiar with the `FixedPointNumbers` package can comment on the best way to reproduce results from the Python `decimal` package.

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [October 28, 2020, 2:59pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/14 "2020-10-28T14:59:48Z")

</div>

> [@stevengj](#):
>
> The problem with this code may be that, in the current release of FixedPointNumbers.jl, `/` and `*` are implemented by [converting to floating point](https://github.com/JuliaMath/FixedPointNumbers.jl/blob/v0.8.4/src/normed.jl#L252-L253), performing the operation, and then rounding back to fixed point.

It is not an essential matter whether the calculation is done within floating point numbers. The multiplication and division for fixed-point numbers cause the decimal point to be in a different position. In the case of `Fixed` (not `Normed`), it is possible to calculate without numerical error by widening the types.

---

<div class="post-metadata">

**Author:** ![PabloZubieta](https://avatars.discourse-cdn.com/v4/letter/p/ee7513/32.png) [@PabloZubieta](https://discourse.julialang.org/u/PabloZubieta)\
**Post date:** [October 28, 2020, 3:29pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/15 "2020-10-28T15:29:19Z")

</div>

If you just want to reproduce the python example there, you can do:

```julia
module Muller

using FixedPointDecimals

muller(y, z) = 108 - (815 - 1500 / z) / y

function recur(T, n)
    v = zeros(T, n)
    v[1:2] .= T[4, 4.25]

    for i = 3:n
        v[i] = muller(v[i - 1], v[i - 2])
    end

   return v
end

end # module

```

and then you’ll get

```julia
julia> using FixedPointDecimals

julia> Muller.recur(FixedDecimal{BigInt,25}, 20)
20-element Array{FixedDecimal{BigInt,25},1}:
 FixedDecimal{BigInt,25}(4.0000000000000000000000000)
 FixedDecimal{BigInt,25}(4.2500000000000000000000000)
 FixedDecimal{BigInt,25}(4.4705882352941176470588235)
 FixedDecimal{BigInt,25}(4.6447368421052631578947362)
 FixedDecimal{BigInt,25}(4.7705382436260623229461618)
 FixedDecimal{BigInt,25}(4.8557007125890736342039857)
 FixedDecimal{BigInt,25}(4.9108474990827932004342938)
 FixedDecimal{BigInt,25}(4.9455374041239167246519529)
 FixedDecimal{BigInt,25}(4.9669625817627005962571288)
 FixedDecimal{BigInt,25}(4.9800457013556311118526582)
 FixedDecimal{BigInt,25}(4.9879794484783912679439415)
 FixedDecimal{BigInt,25}(4.9927702880620482067468253)
 FixedDecimal{BigInt,25}(4.9956558915062356478184985)
 FixedDecimal{BigInt,25}(4.9973912683733697540253088)
 FixedDecimal{BigInt,25}(4.9984339437852482376781601)
 FixedDecimal{BigInt,25}(4.9990600687785413938424188)
 FixedDecimal{BigInt,25}(4.9994358732880376990501184)
 FixedDecimal{BigInt,25}(4.9996602467866575821700634)
 FixedDecimal{BigInt,25}(4.9997713526716167817979714)
 FixedDecimal{BigInt,25}(4.9993671517118171375788238)

```

which is the exact same list of values in the article, so I suspect that the Decimal type in python is probably equivalent to `FixedDecimal{BigInt,25}`.

As others have said that article is misleading, but if you just want to show you can recreate the sequence with a fixed-point Julia type, there you have it.

---

<div class="post-metadata">

**Author:** ![Jeff\_Emanuel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeff_emanuel/32/15440_2.png) [@Jeff\_Emanuel](https://discourse.julialang.org/u/Jeff_Emanuel)\
**Post date:** [October 28, 2020, 6:23pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/16 "2020-10-28T18:23:09Z")

</div>

> [@Palli](#):
>
> I believe decimal floating-point is relatively new, both as a standard and in hardware (rare)

Not exactly new, but a niche until the 80s.

> **[Floating-point arithmetic | History](https://en.wikipedia.org/wiki/Floating-point_arithmetic#History)**
>
> In 1914, the Spanish engineer Leonardo Torres Quevedo published Essays on Automatics, where he designed a special-purpose electromechanical calculator based on Charles Babbage's Analytical Engine and described a way to store floating-point numbers in a consistent manner. He stated that numbers will be stored in exponential format as n x 10
>   
>     
>       
>         
>           
>           
> m
>           
>         
>       
>     
> {\\displaystyle ^{m}}
>   
> , and offered three rules by which c

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [October 28, 2020, 6:25pm UTC](https://discourse.julialang.org/t/cobol-and-julia-comparison/49166/17 "2020-10-28T18:25:46Z")

</div>

> [@bocc](#):
>
> This article describes Muller’s recursion formula, which is a good example of this erratic behavior. This series should converge to 5, but using doubles it converges to a 100, after some hectic jumps.

No, that recursion is an extremely bad illustration of inaccuracy accumulation. As soon as you leave the curve `y = 8 - 15 / z`, which effectively every plausible rounding will do, the correct solution in exact arithmetics is to converge to 100.

See [# Short version The Muller’s Recurrence is a mathematical problem that will conv... | Hacker News](https://news.ycombinator.com/item?id=17637441) for a reasonable amount of analysis.