Talk:Convert decimal number to rational

Name change?

To possibly: "Convert decimal number to rational". To make it more descriptive. --Paddy3118 05:59, 12 June 2011 (UTC)

Or "Convert from decimal into a fraction" --Markhobley 08:34, 12 June 2011 (UTC)

What are the plans for results greater than one? Do we want a "top heavy" fraction or whole number and fractional component? What should 3.5 and 7 look like? Presumably we want "7/2" and "7/1" or do we want "3 1/2" and "7"?

Well, since it is not specified, I would think that it is left to the individual, but giving a fraction that is still reducible, such as 5/10 would not feel right. --Paddy3118 11:42, 12 June 2011 (UTC)

Yeah. We definitely need lowest terms.--Markhobley 12:14, 12 June 2011 (UTC)

Decimal?

Are we talking about only rationals? What about 3.14159265...? --Ledrug 06:36, 12 June 2011 (UTC)

Well if you can express it as a finite decimal expansion ... :-)
--Paddy3118 11:44, 12 June 2011 (UTC)

Presumably we are only working to the precision (or double precision) of the system registers, (or to the number of digits originally provided in numerical string based implementations), so the values would all be rational. --Markhobley 12:28, 12 June 2011 (UTC)

Definitions: Rationals - the real numbers constructible as ratio of A/B, where A and B are both integers. Irrationals - the real numbers that cannot be expressed as such a ratio.

The set of rationals exactly matches the set of numbers with decimal expansions that either terminate (i.e. fixed length), or become periodic (i.e. written it with a bar over the last N digits).

The set of irrationals exactly matches the set of numbers with decimal expansions that neither terminate nor become periodic.

Therefore, there is no way to put an irrational number into your code as a decimal number, even if you can also indicate number of repeating digits. You *can* say PI or sqrt(2) in most languages, but what you get from those is just the largest (truncated) decimal version that fits into your floating point representation.

To summarize, IMHO, *yes*, only rationals make sense for this task. --Util 14:49, 12 June 2011 (UTC)

Good, I just wanted to clarify whether the task was talking about machine precision floats or any conceptual real numbers, because specifying a "best approximation" for irrationals would make it a lot more complicated. --Ledrug 22:01, 12 June 2011 (UTC)

Bah, I implemented the best approximation method anyway, 10 digit integer fractions are just so useless. The task author really needs to clarify what he had in mind. --Ledrug 01:22, 13 June 2011 (UTC)

Repetitive digit chains and rounding

What do we want to do with chains of repeating sequences such as 0.333333333333? Do we want 111111111111/333333333333 or 333333333333/1000000000000 or do we need to round out the repetitions before evaluation (producing 3/10? or possibly even 1/3). --Markhobley 12:52, 12 June 2011 (UTC)

I recommend allowing a second optional parameter to indicate number of repeating digits. dec2frac(0.1234,2) would mean 0.123434343434... (written as 0.1234 with a bar over the "34), and should convert to 611/4950, while dec2frac(0.1234) or dec2frac(0.1234, 0) would mean *exactly* 0.1234 (1234/10000), which should convert to 617/5000. --Util 13:48, 12 June 2011 (UTC)

For an algorithm to handle such indicated repeating digits, see [1] --Util 15:15, 12 June 2011 (UTC)

It is certainly interesting, but I think it goes well beyond what is in the task description and given in the first, (canonical?), example in BASIC. I read it as needing a routine that can take the given decimal numbers and generate their rational approximations with no need to introduce repeating digit handling. --Paddy3118 15:25, 12 June 2011 (UTC)

Yeah, you are probably right Paddy. The repeating sequence scenario only applies if it occurs across the full width of input. Handling of repetitive digits could be dealt with by a separate handler before this routine is called. A separate task could be to create such a handler. For this task (not the handler task) we could deal just with the conversion, and the output is taken as it is. --Markhobley 16:09, 12 June 2011 (UTC)

Whoops! I posted my Perl 6 solution (that handles rep-digits) before checking here. If the task comes out of Draft status with this decision (no rep-digits) intact, then I will reduce the Perl 6 solution to fit the simpler problem. I think that the Python solution will need similar attention. --Util 16:39, 12 June 2011 (UTC)

It probably won't need trimming. We can probably just add a note that the repetitive sequences are sanitized by this version of the program. --Markhobley 17:25, 12 June 2011 (UTC)

J and best fit

This is a curiosity rather than critism, because I know nothing about J to begin with. My question: how is a floating point stored in J, and how does it determine what a "best fit" is? In the first example 0.518518 turned into a "866492568306r1671094481399" ("r" means "/" I assume?). Why? What about 518518/1000000? --Ledrug 17:57, 14 June 2011 (UTC)