Talk:Convert decimal number to rational: Difference between revisions

(Yes -- goes without saying in all floating point contexts)
 
(15 intermediate revisions by 3 users not shown)
Line 51:
 
: Given that floating point representation can only exactly represent fractions whose denominators are powers of 2, I think that we have to assume that an approximation is demanded here (and, frankly, this should hold -- that we are dealing with approximations -- in any context where floating point is used to represent fractions [unless all denominators are explicitly declared to be powers of 2], and also where floating point is used to represent integers which are larger than the floating point mantissa [unless, of course, the mantissa times power-of-two multiplier is explicitly declared to have sufficient precision for complete accuracy]). --[[User:Rdm|Rdm]] 20:26, 13 August 2012 (UTC)
 
:: No, not all floating point is represented in powers of two; Intel (and others) have floating point decimal instructions (but hardly anybody uses it as far as I know, PL/I may be the exception as far as languages, and I haven't looked at what PL/I uses on non-IBM hardware). I believe '''C''' has a mention of it in the language definition, but I don't believe any '''C''' language implemented it (I'm not a '''C''' expert, --- hell's bells, I'm not even a novice, but I can spell it). The REXX language uses base ten floating-point numbers, no matter what the underlying hardware can or does use. The mantissa is only limited (in REXX) by how large one wishes to make it. There is no hardware constrained limits of 16, 32, 64, 128, 256, ... 4096 ... The REXX language for the most part in regards to expressing numbers and performing arithmetic, endeavors to be human-centric, not machine-centric. It does arithmatic very much like a sentient CBLF would (that has ten fingers). (er, ... carbon-based life form.) -- [[User:Gerard Schildberger|Gerard Schildberger]] 20:51, 13 August 2012 (UTC)
 
::: Sorry, yes -- I assumed IEEE-754 floating point, as opposed to some other variation. And, yes, the term "floating point" is general enough to cover all sorts of implementations. Still, that doesn't change the fundamental issue here -- which is that floating point is an approximation unless explicitly declared otherwise. If anything, it reinforces that conclusion (since it requires that the details of the floating point implementation be fixed before we can have a case where floating point is not an approximation). --[[User:Rdm|Rdm]] 21:08, 13 August 2012 (UTC)
 
:::: When talking about floating point numbers to a REXXer (er, I think that's what I am ...), floating point is exact. 10.77 is precise (no approximations) and that's the way REXX stores it: the way you see it here. What you see is what you get. I realized that for most programmers, this isn't the case when it comes to the storage or expressing of floating-point numbers. I'd hate to have REXX excluded from this party because it uses an exact (base ten) floating point number repesentation with an (more-or-less) unbounded/unlimited mantissa (base ten), no guard digit(s), no binary representation of numbers. REXX knows nothing of IEEE-anything floating point. -- [[User:Gerard Schildberger|Gerard Schildberger]] 21:25, 13 August 2012 (UTC)
 
::::: No. That REXX floating point is exact for fixed length decimal fractions. However, you cannot represent the result of dividing 1 by 3 exactly. For example. Well, you can, but not using that numeric representation. --[[User:Rdm|Rdm]] 21:35, 13 August 2012 (UTC)
 
:::::: Yes, I wasn't talking about the ''result'' of an arithmetic operation (notably division), just a floating-point number. Sorry 'bout any confustion. -- [[User:Gerard Schildberger|Gerard Schildberger]] 21:41, 13 August 2012 (UTC)
 
::::::: That was sort of my point -- that floating point numbers (regardless of the base used) are necessarily approximations in a wide variety of contexts. When dealing with measurements of distance, for example, this is assumed (since the measurements themselves are going to be approximations). That said, the task description just says "decimal number" and not "floating point". Still... the same holds there: finite length decimal numbers can only approximate fractions whose denominators are not representable exactly as powers of 2 and 5. --[[User:Rdm|Rdm]] 22:08, 13 August 2012 (UTC)
 
== What do you mean by ''decimal number''? ==
 
This task confuses me. I was told at school that a decimal number is a rational number which, once written in decimal notation, has a finite number of decimals.
 
So a decimal number has an easy rational way of writing it. For instance:
 
<math>1.1007 = {11007\over 1000}</math>
 
If you consider repeating decimals, then you're talking about rationals, and the task then consists in finding the numerator and the denominator of a rational, given its integer part and its possibly infinite, but repetitive list of decimals. This should be clarified imho.--[[User:Grondilu|Grondilu]] 00:21, 19 November 2012 (UTC)
 
== Task needs clarification / splitting up ==
 
Years after the above discussions, the task is still not clear. The solutions I checked have interpreted it in one of the three following ways:
 
# Take an '''exact''' rational number with a '''terminating decimal''' representation, and convert this representation to a fraction.
#: <small>This is what we've probably all had to do in math class in middle school. Multiply numerator and denominator by the appropriate power of ten to get an integer fraction, then reduce to lowest terms.</small>
# Take an '''exact''' rational number with a '''[[wp:Repeating_decimal|repeating decimal]]''' representation, and convert this representation to a fraction.
#: <small>Also middle-school level stuff, but slightly more interesting.</small>
# Take an '''inexact (floating-point) approximation''' of a rational number, and try to find the fraction that best matches it under certain parameters (e.g. limited digit size of the numerator/denominator).
#: <small>This one is more involved.</small>
 
This means that many of the solutions are currently not comparable with each other. I flagged the task with [[Template:Clarify task]] for now, but how should it be resolved? One idea would be to make this task about (1), with (2) as extra credit, and split off (3) as a separate task called "Approximate floating-point numbers as fractions" or similar. Thoughts?<br>
--[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 15:55, 21 August 2016 (UTC)
Anonymous user