Talk:Division algorithm

"Anderson Earle Goldschmidt Powers algorithm" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Anderson Earle Goldschmidt Powers algorithm. Please participate in the redirect discussion if you wish to do so. D.Lazard (talk) 14:30, 24 October 2019 (UTC)

Recurrence relation at top of "Slow Division Methods"

Where is this relation coming from? I have seen R[i+1] = R[i] + q[i] * D * B^i, but not this one. — Preceding unsigned comment added by Mikecondron (talk • contribs) 19:07, 4 February 2020 (UTC)

Non-restoring division

Did anyone check the pseudocode for Division algorithm#Non-restoring division? The cited sources do not contain any pseudocode AFAIK. The code does not match the division algorithms I know, and does not specify the number format. Dimawik (talk) 09:12, 21 December 2024 (UTC)

There's some pseudocode in doi:10.1109/ACCESS.2021.3055735 if you want to take a closer look. –jacobolus (t) 05:25, 1 January 2025 (UTC)

Thank you! The hardware version you have pointed to is correct. With the help of AI transformed the buggy code into a similar but correct one. If someone can do better than AI, they are welcome. Dimawik (talk) 07:31, 30 December 2025 (UTC)

Should we add a section on pencil-and-paper algorithms?

Currently, this article deals with algorithms, but only to the extent that they are implemented in pseudocode. There is no mention of pencil-and-paper algorithms, except in the hatnote:

This article is about algorithms for division of integers. For the pencil-and-paper algorithm, see Long division.

However, long division is not the only pencil-and-paper division algorithm. There are also short division and galley division, as well as chunking. I feel like this fails WP:NPOV, especially if these other division algorithms are also still being taught and used.

There's currently no article that I can find that discusses pencil-and-paper algorithms for division. So I think it would make sense to include a section for algorithms for dividing by hand. Cf. Multiplication algorithm, which does include such a section. Edderiofer (talk) 11:21, 12 June 2026 (UTC)

I like this idea. Presumably sources would not be too difficult to find. Stepwise Continuous Dysfunction (talk) 21:18, 12 June 2026 (UTC)

Ancient Egyptian division could be covered, too. There's an accessible introduction in Reimer, David (2014). Count Like An Egyptian. Princeton University Press. pp. 9–12. ISBN 978-0-691-16012-2. Stepwise Continuous Dysfunction (talk) 21:26, 12 June 2026 (UTC)

There's also good material in Gillings (1972) Mathematics in the Time of the Pharaohs. –jacobolus (t) 23:37, 12 June 2026 (UTC)

Terminology: "slow/fast" vs. the cited taxonomy

The lead and section headings classify methods as "slow division" and "fast division". These labels can be misleading. They describe order of convergence, not actual latency, which depends on implementation and the cost of the underlying multiplier. Iteration count trades off against per-iteration cost, so a digit-recurrence ("slow") method such as high-radix SRT is widely used even in high-performance dividers. Mechanism-based names avoid implying a speed ranking, which can mislead readers. The academic literature — including Oberman & Flynn and Ercegovac & Lang, both already cited here — generally uses "digit recurrence" and "functional iteration" (sometimes "division by convergence"). I'd suggest adopting those as the primary terms and keeping "slow/fast" as commonly-used alternative labels noted in parentheses. Thoughts? ~2026-35596-36 (talk) 10:49, 19 June 2026 (UTC)

"Slow" and "fast" are well established terms in computational complexity theory and refer to the asymptotic complexity. In short, if ⁠$n$⁠ is the total number of bits of the dividend and the divisor, an algorithm is slow, if its complexity is ⁠$O(n^{2})$⁠ and fast if the complexity involves a lower exponent. So, Newton's method is slow if used with standard multiplication and fast if used with a fast multiplication algorithm, for example using Fast Fourier transform.

The problem of deciding which is the fastest algorithm on a given architecture and a given input size is a different (much harder) problem.

The article should, for each algorithm, say under which conditions it is efficient and useful (usefulness includes easiness of implementation and historical importance). The article is very poor on this point of view, and I find the fast/minor issue much less important than other isses of the article. D.Lazard (talk) 17:18, 19 June 2026 (UTC)