Talk:Greedy algorithm for Egyptian fractions: Difference between revisions
Talk:Greedy algorithm for Egyptian fractions (view source)
Revision as of 14:25, 1 February 2023
, 1 year ago→Still incorrect as is
(Restored visibility of task description formulae) |
|||
| (5 intermediate revisions by 4 users not shown) | |||
Line 10:
::: I disagree with your definition of what a cop-out is. A choice of practicality and/or expediency doesn't make it a cop-out; there's isn't any need to use pejorative words. Whether or not anybody talks about Egyptian fractions for improper fractions (or not) doesn't change the fact that the use of same is part of this Rosetta Code task. It's there. If you want to solve the improper fraction your way, please feel free to do so. it'll be very interesting to see your solution for the 3<sup>rd</sup> fraction, the vulgar one. You can repeat that phrase about ''any rational number ···'' as much as you want, I'm not disagreeing with you. You're beating a dead horse. I don't understand your comment about ''it's (the integer part) not there to begin with''. An improper fraction ''has'' an integer part, it's just expressed as part of the improper fraction, I just chose to have the integer part split off from the fraction part of the number before converting it to an Egyptian fraction. As for making something up to prevent ···, I didn't. That's not what I did, and that's not what I intended. Nothing is preventing any rebellion. Programmers are still free to express/display the unit fractions in any matter they want. So far, only unit fractions with a 1 (unity) over a solidus ('''/''') are being used (to date) in the programming examples' outputs. I included the new part of the task to answer/rebuttal your flagging of examples as incorrect. I also would like the ceasing of name-calling and incorrect characterizations of what I have done or have responded to; it's not professional nor civil. Whether it be narrow-minded, lame, or other ill-chosen words, it's just not polite and sets a wrong tone for conversations/discussions on Rosetta Code, whether it be in talk pages or elsewhere. These conversations will be around for a long time. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:37, 3 April 2014 (UTC)
:We are asked to find the Egyptian fraction with the largest number of terms, finding a solution which matches the task description: 97/53->1+1/2+1/4+1/13+1/307+1/120871+1/20453597227+1/697249399186783218655+1/1458470173998990524806872692984177836808420 but 8/97->0+1/13+1/181+1/38041+1/1736503177+1/3769304102927363485+1/18943537893793408504192074528154430149+1/538286441900380211365817285104907086347439746130226973253778132494225813153+1/579504587067542801713103191859918608251030291952195423583529357653899418686342360361798689053273749372615043661810228371898539583862011424993909789665 using the standard definition for a term in an Egyptian fraction both have 8. The task description causes 97/53 to have an extra term because it is improper, which is nonsense.--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 14:25, 1 February 2023 (UTC)
== Request for task clarification ==
Line 29 ⟶ 30:
<br>As for the 1- and 2-digit integers thingy requirement
For (the above), I meant, all proper fractions (that was implied) for one and two digit (positive) integers, such as:
Line 60 ⟶ 61:
: Visibility of formulae to Chrome, IE/Edge, Safari etc restored by reverting task description to state before under-tested cosmetic edits of 02:50, 16 August 2016. The editor may wish to restore some of these cosmetic edits, testing their real effects in Google, Microsoft and Apple's browsers, but the the most practical immediate solution is simply to return to the state before visibility of formulae was lost. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 00:29, 17 October 2016 (UTC)
== Rename and rewrite task as "Greedy algorithm for Egyptian fractions" ==
This task is (and should be) about
[[wp:Greedy_algorithm_for_Egyptian_fractions|the greedy Egyptian expansion]]
and not about
[[wp:Egyptian_fraction|Egyptian fractions]].
Above, [[User:Gerard Schildberger|Gerard Schildberger]] wrote:
: > "Whether or not that's true, I haven't seen an example showing an Egyptian fraction example for an improper fraction."
[[wp:Egyptian_fraction#Motivating_applications|Wikipedia]] has an example, namely: 13/12 = 1/2 + 1/3 + 1/4.
Furthermore, that Wikipedia page covers several calculation methods and shows a "much better expansion" (their words) for 5/121 = 1/33 + 1/121 + 1/363.
The task currently says:
:* show '''''the''''' Egyptian fractions for: <math> \tfrac{43}{48} </math> and <math> \tfrac{5}{121} </math> and <math> \tfrac{2014}{59} </math>
but as shown above there is not a unique Egyptian fraction for a given positive rational number.
I think this task should be renamed and rewritten to be only about the narrower [[wp:Greedy_algorithm_for_Egyptian_fractions|Greedy algorithm for Egyptian fractions]],
and only for proper fractions.
A more general task about Egyptian fractions (if desired) should probably encourage giving the "better" expansions by using other/multiple methods.
The task also currently says:
:* '''for all''' proper fractions, <math>\tfrac{a}{b}</math> where <math>a</math> and <math>b</math> are positive one-or two-digit (decimal) integers, '''find and show an''' Egyptian fraction that has:
::* the largest number of terms,
::* the largest denominator.
Since a given number can have multiple valid Egyptian fraction expansions, as written, the task seems to imply you want output for each proper fraction the results of a search through all possible expansions looking for large number of terms and large denominators.
Existing solutions (mostly) instead calculate the greedy Egyptian expansion for each proper fraction looking for the largest number of terms and largest denominator.
This should be what the rewritten task actually asks for.
—[[User:dchapes|dchapes]] ([[User talk:dchapes|talk]] | [[Special:Contributions/dchapes|contribs]]) 21:56, 7 June 2018 (UTC)
:The "search through all possible expansions" will be time consuming as it is always an uncountable infinity. Using the example "5/121 = 1/33 + 1/121 + 1/363" and say 1=1/2 + 1/3 + 1/6 then 1/363 must equal 1/2*363 + 1/3*363 + 1/6*363 so 5/121 must equal 1/33+1/121+1/726+1/1089+1/2178. I can repeat for 1/2178 etc. for ever. I choose the the last term to ensure I don't accidently repeat the denominator ever. I could choose a different expansion of unity.--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 18:07, 30 January 2023 (UTC)
==A problem with the current Python result ?==
The task requirement (bullet 2) begins:
''for all '''proper''' fractions'' ...
but the candidate result offered for the ''largest number of terms'' by the Python script appears to be an '''improper''' fraction (97/53).
Perhaps an oversight ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 15:36, 27 March 2019 (UTC)
| |||