Continued fraction/Arithmetic/Construct from rational number: Difference between revisions

Line 293:
=={{header|ATS}}==
 
I amfound notthe certainreference to "lazy evaluation" is the best way to describe what is neededmisleading, for it implies featuresa special feature of a programming language. Haskell, for example, evaluates lists "lazily". ATS2 has the notation '''$delay''', forand there are various "lazy evaluationlist" ofimplementations thatfor kindScheme. I considered using such methods, but decided against doing so.
 
What one is--I am certain--supposed to write is means for generating an arbitrary number of terms of a continued fraction, one term after another. It happens that, for a rational number, eventually all further terms are known to be infiniteswamped by an infinity, and so need not be computed. The finite terms ''could'' be returned as a finite-length list. However, this will not be so when irrational numbers enter the picture. SoTherefore one needs a way to generate ''any''an indefinite number'' of terms. AndBut this is something that requires no "lazy" features of a language. It could be done about as easily in standard C! asThe inresulting code might, indeed, evaluate terms "lazily", but no special language features are ATSrequired.
 
So I do not use '''$delay''' at all. I do use closures, which standard C does not have, but pairing a regular procedure with an environment could achieve the same effect in C.
 
<hr/>
 
In the first example solution, I demonstrate concretely that the method of integer division matters. I use 'Euclidean division' (see ACM Transactions on Programming Languages and Systems, Volume 14, Issue 2, pp 127–144. https://doi.org/10.1145/128861.128862) and show that you get a different continued fraction if you start with (-151)/77 than if you start with 151/(-77). I verified that both continued fractions do equal -(151/77).
1,448

edits