combinatorial functions as in-built

[gennaro-tedesco]

Very often I find myself defining the same combinatorial functions in each new session: combinations of n elements k by k, permutations of n elements, dispositions and so forth; as such, I wondered if said functions were not general enough (as in used by the general public) to be promoted to in-built. Especially binomial coefficients are often presents even in basic calculations (did I overlook them in the docs or are they not present?): do you believe this has a use case to propose them as new features?

Along the same lines I have seen this discussion about persistent sessions, which may be a workaround for it since users may store and keep their definitions (or perhaps going in the direction of a scripting config file, say ./config/insect/insectrc where we can define our own functions loaded at start-up?): curious to see if this has been discussed already and what is the take on it.

Anyway, insect together with most of your other work is a blessing: thank you for your dedication and attention to details!

[sharkdp]

I wondered if said functions were not general enough (as in used by the general public) to be promoted to in-built.

The main problem I have is that Insect is a numerical calculator. It's not a full blown CAS and it doesn't actually distinguish between integers and non-integers. Combinatorial functions would therefore be prone to inaccuracies (for sufficiently large integers). Did you experience problems of this sort?

Along the same lines I have seen this discussion about persistent sessions

see also #107 and #248. But note that I haven't released a new version since then (see also #271 (comment)).

[sharkdp]

Anyway, insect together with most of your other work is a blessing: thank you for your dedication and attention to details!

Thank you very much!

[gennaro-tedesco]

Did you experience problems of this sort?

I have not experienced numerical inaccuracies, however I have not used "big numbers" either (say most of my calculations are of the order of 10^4 at most). This said, would this be a counter-argument for defining this type of in-built functions? Because the users would still go ahead and define them by themselves (and run into numerical inaccuracies anyway, should they occur) - but I do understand that you do not want to offer capabilities that you feel may be prone to errors.

From #248 I take that this does exist already, it just needs to be released?

[sharkdp]

I have not experienced numerical inaccuracies, however I have not used "big numbers" either (say most of my calculations are of the order of 10^4 at most). This said, would this be a counter-argument for defining this type of in-built functions?

Maybe not. But it's probably worth documenting. In this sense, I'd be okay with adding new builtin functions.

What kind of functions would you like to see? Let's focus on the most important ones first maybe. binomial(n, k)?

I just tried it out and it shows the expected inaccuracy problems even at moderate inputs:

> binomial(n,k)=n!/(k!*(n-k)!)

  binomial(n, k) = (n!) / ((k!) × ((n - k)!))

> binomial(36,6)

   = 1947790

(answer should be 1947792)

But maybe we could be more accurate with a different method of (internal) computation.

From #248 I take that this does exist already, it just needs to be released?

Yes.

[gennaro-tedesco]

Hmm, I see the error - and yes, the functions are more or less binon(n,k) and P(n,k)=n!∙(n-1)!∙...∙(n-k+1)!.

I will focus on #248 for the moment then, this was just some food for thought in case the same is (or will be) raised by other users too :)

[sharkdp]

Ok. Due to the concerns raised above, I suggest we close this for now. But I'm happy to reconsider if others should chime in.