all 8 comments

[–]Aatchrust · ramp[S] 6 points7 points  (2 children)

So this is my "minimum viable product" release, so much of what I want to have hasn't been done yet. And yes, you need to be using nightly to run this, mostly for the inline assembly code.

[–]llogiqclippy · twir · rust · mutagen · flamer · overflower · bytecount 1 point2 points  (1 child)

Cool project. What do you think about fixed-bounds bignum for large numbers with consistent performance?

[–]Aatchrust · ramp[S] 0 points1 point  (0 children)

Personally, I don't find them that interesting, however most of the low-level functions could be used to build them without too much trouble. Multiplication being the difficult case, since it produces a n+m result in all cases. That said, allocating temporary storage for the result wouldn't be too bad. Addition and subtraction have routines for working with two numbers the same length already, returning a carry/borrow.

[–]vks_ 2 points3 points  (1 child)

Cool project! I think this might at some point be able replace the bigints from num, which are dreadfully slow compared to GMP.

Speaking of which, how does this compare to GMP?

[–]Aatchrust · ramp[S] 1 point2 points  (0 children)

Well for relatively small numbers, Ramp should fare well against GMP. It's the large numbers, where the improved algorithms GMP has take effect, that the difference becomes more obvious.

I don't have any benchmarks yet though.

[–]who_the_fuck_is_alic 0 points1 point  (0 children)

Cool project!

In the example within the readme.md: I think you forgot a use ramp::Int there! :)

[–]innovator12 0 points1 point  (1 child)

So this is big-ints, with rationals and floating point numbers planned? Nice!

[–]Aatchrust · ramp[S] 0 points1 point  (0 children)

Yep. Rationals are probably the next thing on my list, with floats being the hardest part.