# FindDivisions behavior changed?

Bug introduced in 8.0.4 or sooner and fixed in 10.4.1

I seem to recall using FindDivisions as a quick way to get all numbers in an interval that are divisible by a member of some set of integers, e.g.

FindDivisions[{1,100,{2,3,5}}]


gave me lists of all in the range divisible by 2, then 3, then 5, at least if I remember correctly.

Just doing this, I got

FindDivisions::argtu: FindDivisions called with 1 argument; 2 or 3 arguments are expected. >>

A quick look at the docs shows indeed this is the correct format for this operation.

Trying to force the issue with

FindDivisions[{1, 100, {2, 3, 5}}, All, 10]


resulted in

FindDivisions::fdargs: The arguments in DeveloperFindDivisions[{1,100,{2,3,5}}, All, 10] are not supported.>>

There are of course simple ways to do the same, I'm just curious when this changed (and why it's still documented), or is it a bug and it should work.

• @Lou:Ah, no. That is a completely different result (and documented as such). – ciao Mar 30 '15 at 5:08
• something is wrong here. docs shows your call should work as written. Last entry in help. !Mathematica graphics btw, I get same error in V 9 as in V 10.02 – Nasser Mar 30 '15 at 5:09
• In version 8.0.4 I observe exactly the same behavior as in version 10.0.2. – Alexey Popkov Apr 1 '15 at 11:37
• Another documented usage FindDivisions[{1, 100, {2, 3, 5}}, {30, 50}]` also throws an error. – george2079 Dec 23 '15 at 17:11

## 2 Answers

I submitted this issue to the attention of Wolfram tech support. I received their answer this morning. I quote the relevant part.

I was able to reproduce the issue, and consequently I filed a report with our development team raising the issue.

On the basis of this reply I am tagging the question with .

Although it is not entirely clear from the brief reply I received, I infer that WRI is treating this as an implementation bug and not as a documentation bug.

From version 10.4.1, the corresponding usage line has been removed,

and the front end shows that the syntax is incorrect: