Is this a bug or is it a known behavior?
Subdivide[{5,10},2]
gives
{0,{5/2,5},{5,10}}
isn't expected to give {0,0} as first element?
$\begingroup$
$\endgroup$
2
-
1$\begingroup$ It's undocumented behavior, but not a bug. See my answer. $\endgroup$ – m_goldberg Nov 23 '17 at 13:11
-
2$\begingroup$ I would say is a bug since it works but inconsistently. I see no reason why the second and the third results are lists, while the first one is a not a list. Even worst bug in case of your answer below. Completely inconsistent also because symbolically gives the right answer, so what about providing a list? BUGGY! $\endgroup$ – Fabio Nov 23 '17 at 15:20
Add a comment
|
$\begingroup$
$\endgroup$
1
Subdivide has rather sparse documentation, but ...
There is no documented behavior for list arguments, so I'm surprised that it even accepts lists and more surprised that it does something intelligent with them.
If only two arguments are given they are interpreted as subdivision-max and number divisions with zero assumed for subdivision-min, which explains the behavior you see.
If you supply
{0, 0}as subdivision-min. you will get what you expect.
Subdivide[{0, 0}, {5, 10}, 2]
{{0, 0}, {5/2, 5}, {5, 10}}
answered Nov 23 '17 at 13:06
-
1
$\begingroup$
$\endgroup$
To decide whether the behaviour is resonable, let us think about a straightforward way to implement this function. I would do this:
Clear[subdivide]
subdivide[xmin_, xmax_, n_] := Table[xmin + (xmax - xmin) k/n, {k, 0, n}]
subdivide[xmax_, n_] := subdivide[0, xmax, n]
subdivide[n_] := subdivide[1, n]
I left out the check that n is a positive integer.
Just like Subdivide, it works for any input, even symbolic ones.
subdivide[a, 5]
(* {0, a/5, (2 a)/5, (3 a)/5, (4 a)/5, a} *)
Subdivide[a, 5]
(* {0, a/5, (2 a)/5, (3 a)/5, (4 a)/5, a} *)
But this straightforward implementation behaves much more reasonably with list inputs:
subdivide[{5, 10}, 2]
(* {{0, 0}, {5/2, 5}, {5, 10}} *)
It seems to me that Subdivide could behave better without having to make compromises.
I would contact Wolfram Support and let them know about this behaviour. Hopefully, it will be improved in future versions.
All that is really needed is to make the first element of the result be not 0 but 0 + xmax * 0/n.
The following experiment shows that Subdivide uses the xmin + (xmax - xmin) k/n formula for all elements except the first and the last, which are taken as xmin and xmax.
In[3]:= Subdivide[{0, 0}, {5}, 3]
During evaluation of In[3]:= Thread::tdlen: Objects of unequal length in {0,0}+{5/3} cannot be combined.
During evaluation of In[3]:= Thread::tdlen: Objects of unequal length in {0,0}+{10/3} cannot be combined.
Out[3]= {{0, 0}, {5/3} + {0, 0}, {10/3} + {0, 0}, {5}}
It would be more consistent to apply the formula for the first and last element as well, and let Mathematica's rules for arithmetic take care of handling various types of inputs (number, symbol, list, association, etc.)
I'd lean towards calling the current behaviour a bug.
