# Rounding problems

Hi,
I have some rounding problems when coding binomial coefficient.

We should only have integers.

In Python, I don't have those problems because of the integer division //.

def k_parmi_n(k,n):
... return 1 if k == n else reduce(lambda a,b: a * b,range(k+1,n+1)) // reduce(lambda a,b: a * b,range(1,n-k+1))

And I do have any problem :

list(map(lambda a: k_parmi_n(a,50),range(0,50)))
[1, 50, 1225, 19600, 230300, 2118760, 15890700, 99884400, 536878650, 2505433700, 10272278170, 37353738800, 121399651100, 354860518600, 937845656300, 2250829575120, 4923689695575, 9847379391150, 18053528883775, 30405943383200, 47129212243960, 67327446062800, 88749815264600, 108043253365600, 121548660036300, 126410606437752, 121548660036300, 108043253365600, 88749815264600, 67327446062800, 47129212243960, 30405943383200, 18053528883775, 9847379391150, 4923689695575, 2250829575120, 937845656300, 354860518600, 121399651100, 37353738800, 10272278170, 2505433700, 536878650, 99884400, 15890700, 2118760, 230300, 19600, 1225, 50]

Am I obliged to add a round() function on my script to do this ? It seems so weird...

Could you please add an integer division to the basic operators ? Thank you.

There's a library for solving exactly this kind of problem--the Bignums, rationals, complex #s library. Then again, ROUND is much simpler, especially because (it seems) all of the outputs are supposed to be integers.

I think the underlying problem is that Javascript, in which Snap! is implemented, doesn't have an integer data type at all, so the only way we could provide an integer division capability would be to use FLOOR (not ROUND, since integer division in other languages truncates).

I concur with the suggestion to use bignums.

Thank you @warped_wart_wars and @bh for your answers. I didn't want to use bignums but I see I will have too !

@bh Can't you create an integer division // using bignums so that it would be totally transparent for users ?

[offtopic]
I have an 8 1/2 cm long baby carrot and an 11 1/2 cm long one. (~3 1/4" and ~4 1/2")

Oh and have you checked the new Lists OF help screen I just made? Edit: I see you're replying to it right now.
[/offtopic]

We could put one in the bignum library, but if "totally transparent" means you wouldn't have to load the library, then no.

I have very strange things using bignums.

Bignums off

Bignums on

As You see is a long number ~$$10^{64}$$.
Maybe this block will be usefull for small numbers

.
With BigNums, you can convert the fraction to a more readable format for display.

Very nice! Thank you @dardoro .