COMBINA() function should allow first argument non negative less than second argument non negative

for example combina(2,3) is 4 because combinations with repetitions 000,011, 001, 111. But present implementation do not allow first argument less than the second. combina(n,r)=combin(n+r-1, r). Please implement this.

Please file enhancement requests to https://bugs.documentfoundation.org/

Please also post a link to the bug report here as soon as you created it. The standard anchor for links to bug reports here is tdf#12345 where 12345 stands for the number your bug got. Giving the standatrd anchor (outside of preformatted text) will cause automatic creation of the link as soon as your post is saved.

The specification for COMBINA() is:

6.16.17 COMBINA
Summary: Returns the number of combinations with repetitions.
Syntax: COMBINA( Integer N ; Integer M )
Returns: Number
Constraints: N >= 0, M >= 0, N >= M; Evaluators may evaluate expressions where N >= 0, M >=
0 returns a non-error value.
Semantics: Returns the number of possible combinations of M objects out of N possible ones,
with repetitions allowed. Actual arguments that are not integers are truncated (using INT) before
use. The result is  
{Graphic formula not pasting here}
See also COMBIN 6.16.16   

The formula not pasting above is: image description
which should be equivalent to: image description
For what resons the (slightly) more complicated version was chosen, I don’t know. Anyway there is no reason to demand N>=M from the mathematical and practical points of view.

However, the specification expressly states the constraint N>=M, and therefore you need to raise your bug-report against the specification, not against the implementation.

===Amendment===
COMBINA() is unnecessary. Use COMBIN(A2+B2-1;B2) (A2 containing N, B2 containing M) instead.

The specification saying “Evaluators may evaluate expressions where N >= 0, M >= 0 returns a non-error value” means where the additional constraint N >= M is not met. Probably there are implementations that evaluate it that way. The additional constraint N >= M and “evaluators may” omitting it indicates that if all constraints are met the calls are fully interoperable. Calc could be adapted to not return an error on N < M.

Thanks! Strangely I missed to consciously read that line though I quoted it correctly. Sorry!
Anyway: Why doesn’t LibO Calc make use of the permission? Why are there implementations relying on the additional constraint? It’s agains standards as generally seen in mathematics, imo.

Don’t know, it looks like it has been implemented like this since the beginning.