In (canonical, simple) Continued Fraction (CFs) representation, every real number is a list starting with an integer 𝑎₀ and followed by some number (possibly none) of positive integers [𝑎₁, 𝑎₂, ...]. In strictly typed programming languages, this is essentially a non-empty list; for example, in Haskell, one can use Data.List.NonEmpty and the CF becomes (𝑎₀ :| [𝑎₁, 𝑎₂, ...]) = (𝑎₀ :| tail).

Haskell's strict typing enforces the non-empty aspect of CFs. The CF list must be non-empty, so we can think of it as a head (the 𝑎₀ term) and a (possibly empty) tail (the [𝑎₁, 𝑎₂, ...] terms). If the tail is empty, then the number is an integer. So the natural numbers 0, 1, 2, ... become (0 :| []), (1 :| []), (2 :| []) and so on in CF representation.

Now, taking reciprocal in CF representation involves either removing 𝑎₀ if it is 0, or prepending 0 to the whole list. Focusing on the first case, if 𝑎₀ is 0, then we remove that from the list and keep only the tail terms. This step combined with strict typing shows why there is no reciprocal of 0.

If we start with (0 :| []), remove 0 and only keep the tail then we are left with just the empty list []. However, every real number corresponds to a non-empty list and CFs don't allow empty lists.

Therefore the reciprocal of 0 is not a real number.

#math #ContinuedFractions #type #theory #haskell #FunctionalPrograming

I added #OwlLisp to the repertoire of my answers to the #ContinuedFractions arithmetic draft-task on #RosettaCode:

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Owl_Lisp

#scheme #lisp #FunctionalProgramming

I translated, from #Mercury to #Haskell, the #ContinuedFractions #RosettaCode draft task:

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Haskell

I have decided there isn’t a single thing I like about Haskell syntax. I do not care how one writes a thing, I hate it. There is no reason whatsoever for Haskell not to have had a more ML-like syntax. None whatsoever, except to encourage breakage.

An implementation of the #RosettaCode #ContinuedFractions arithmetic draft task, in #Mercury, based very loosely on the #StandardML (that is based on the #Scheme and the #Python:

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Mercury

The implementation uses #LazyLists to represent continued fractions.

The #StandardML was a particular pleasure to write:

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Standard_ML

#SML #RosettaCode #ContinuedFractions

I have now done the #RosettaCode #ContinuedFractions arithmetic draft task in #Ada --

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Ada

I credit my own Python implementation as the original, although the Ada is quite different. Interestingly, I use ‘inheritance’ in the Ada but not in the Python! One might ask why ...

#adalang

This took a few days of overwork and obsessive overexcitement to write. A #Fortran port of my #RosettaCode for #ContinuedFractions, including a primitive #MultiplePrecision module:

Continued fraction/Arithmetic/G(matrix ng, continued fraction n1, continued fraction n2) - Rosetta Code https://rosettacode.org/wiki/Continued_fraction/Arithmetic/G(matrix_ng,_continued_fraction_n1,_continued_fraction_n2)#Fortran

Part of the problem, as I have mentioned before, is that gfortran is not especially helpful in tracking down bugs. But I see gdb has gotten better with Fortran.