Talk:Egyptian division
Perhaps no need to ask for more than one array ?
The description seems attached to the use of two distinct arrays – does that seem necessary ? ( One list/array of tuples/pairs/records might seem more natural in some languages) Hout (talk) 14:49, 10 August 2017 (UTC)
- Indeed. In the Perl6 example, I use an array of pairs rather than two separate arrays. Seems to me that _how_ the values are stored is an implementation detail that isn't critical to the task. --Thundergnat (talk) 15:18, 10 August 2017 (UTC)
- Two arrays, one table of "pairs" would be fine. I would like a such a semblance of the description to be used to aid in example comparison . Thanks. --Paddy3118 (talk) 16:24, 10 August 2017 (UTC)
- Fair enough – it's essentially a hylomorphism [1], and it seems reasonable / sufficient to ask people not to fuse the building up and the stripping down to the extent that the intermediate data structure is concealed. In the Haskell, JS, and AppleScript versions I've pulled that out and named it 'rows' rather than fusing it out of sight. I hope that seems enough to you :-) Hout (talk) 19:09, 10 August 2017 (UTC)
- A fused composition of the unfold and the fold, in which the rows were implicit but not directly visible, might look something like:
- <lang Haskell>import Data.List (unfoldr)
- A fused composition of the unfold and the fold, in which the rows were implicit but not directly visible, might look something like:
- Fair enough – it's essentially a hylomorphism [1], and it seems reasonable / sufficient to ask people not to fuse the building up and the stripping down to the extent that the intermediate data structure is concealed. In the Haskell, JS, and AppleScript versions I've pulled that out and named it 'rows' rather than fusing it out of sight. I hope that seems enough to you :-) Hout (talk) 19:09, 10 August 2017 (UTC)
egyptianQuotRem
:: Integral a => a -> a -> (a, a)
egyptianQuotRem m n =
foldr
(\(i, x) (q, r) ->
if x < r
then (q + i, r - x)
else (q, r))
(0, m) $
unfoldr
(\(i, x) ->
if x > m
then Nothing
else Just ((i, x), (i + i, x + x)))
(1, n)
main :: IO () main = print $ egyptianQuotRem 580 34</lang> Hout (talk) 19:35, 10 August 2017 (UTC)
- Is this the solution you are going with? On the page you write 'In Haskell we could lazily take the rows we need from an infinite list'. The task requires that you work backwards through the list, a clever trick on an infinite list. The list has been fully and non lazily realized in rows before the calculation begins. Is (2 ^) exponentiation? see below--Nigel Galloway (talk) 12:21, 11 August 2017 (UTC)
- Not quite the solution I am going with – I've pulled the composition of foldr and unfoldr apart, to expose a value named 'rows'. I take your point about using exponentiation, and it gives me an excuse to remove the first of my 3 versions – the one which started by taking a finite number of rows from an infinite list. Hout (talk) 14:22, 11 August 2017 (UTC)
- Is this the solution you are going with? On the page you write 'In Haskell we could lazily take the rows we need from an infinite list'. The task requires that you work backwards through the list, a clever trick on an infinite list. The list has been fully and non lazily realized in rows before the calculation begins. Is (2 ^) exponentiation? see below--Nigel Galloway (talk) 12:21, 11 August 2017 (UTC)
Number Systems
The Egyptian number system essentially precludes multiplication and division, but they required both. They therefore designed methods that required only addition. I am willing to accept that n*2 is essentially equivalent to n+n but I must take exception to 'dbls.append(pwrs[-1] * divisor)' in the Python solution. They could not have multiplied by a variable like (say 34). As for exponentiation, well let's just say the Perl 6 is not Egyptian--Nigel Galloway (talk) 12:01, 11 August 2017 (UTC)
- This makes a nice point, and perhaps suggests a simpler and deeper formulation for the task description ? I've used it as a welcome excuse to delete the first of my 3 Haskell versions, which included an exponentiation operator.
- Given that the 'Egyptian' algorithm is specifically a derivation of division from addition and subtraction, and assumes a dearth of more ambitious arithmetic operators, perhaps an edit (to that effect) to the task description – requiring parsimony in the set of arithmetic operators – no multiplication, division or exponentiation operators ? Hout (talk) 14:33, 11 August 2017 (UTC)