Is Proper Ratio Support on the Roadmap?

[BSlug]

Currently, I believe e.g. (/ 9 2) evaluates to 4. I’ve read that float support is unlikely to happen for portability reasons, but ratios could offer a middleground.

[l4haie]

We’re actively working towards supporting floats in ribbit, hopefully this will be done by the end of summer!

[BSlug]

Will there be a way to easily exclude floats from the numerical stack, for systems such as microcontrollers where the float routines would increase the binary size considerably?

[leo-ard]

yes ! This will be done through the feature system of ribbit. To have proper floats, you will need to enable the "float" feature.

It will use the underlying implementation when available. For example, if running on the C RVM, the already existing implementation of floats can be reused. Only conversions between Scheme and C need to be handled.

For hosts that don't have native support for floats, I'm not yet sure what we are going to do as emulating them would be quite a challenge and would probably result in pretty slow implementation of IEEE-754 floats. Maybe a scheme library that support ratios could be a good middle-ground

[raviqqe]

I've recently implemented 62-bit floating-point numbers which is called flonums internally in Ruby in my Scheme implementation following Ribbit Scheme's architecture. That might be also interesting for Ribbit Scheme because it appears to be faster for boxing/unboxing integers and cons pointers than traditional NaN boxing on 64-bit floats.

• Add float62 feature raviqqe/stak#2323
• https://github.com/raviqqe/nonbox/blob/d5e7e6900abb2dc9acd95b1875e2e3c1097c7c77/src/f62.rs

@l4haie was also working on the float/bignum implementation. But the PR seems to be forsaken now...

[leo-ard]

Hey @raviqqe! Thanks for sharing your implementation of float62. I read through it and as I understand it you embed the tags inside the 2 highest bits of the matissa of a classical IEEE float64 (with the rotation operator). Then for operations you need to unbox/rebox them each time and reuse the rust operations to make it work (without any allocations, which is nice). Is this what is used in Ruby? It seems similar to self-tagging (https://arxiv.org/pdf/2411.16544)

@l4haie was indeed working on a float/bignum implementation. Most of the work here was for the number->string/string->number functions and bignums. We wanted to have a solution that is potable to all 16 hosts, thus implementing this logic in scheme. We choose to only keep operations on floats as host-specific, because emulating them in scheme would be a huge performance bottleneck. I still have plans to reintroduce the work that @l4haie did last summer this summer and might tweek it so that Ribbit can avoid allocations for floats (which would be very nice!)

[raviqqe]

@leo-ard Thank you for sharing the fantastic research work of Ribbit Scheme too :)

Is this what is used in Ruby?

Yes, I think this is still used in Ruby. In this rb_num2dbl function, there are two function calls of rb_float_flonum_value for tagged-value floats and rb_float_noflonum_value for boxed floats. The name of flonum is a bit confusing, but it specifically indicates the unboxed 62-bit floats.

It seems similar to self-tagging

Thank you for sharing the paper too. It looks similar to the 62-bit floats in Ruby while self-tagging doesn't need the extra rotation for most integers and Ruby's flonum also includes many non-integer float values.

We choose to only keep operations on floats as host-specific, because emulating them in scheme would be a huge performance bottleneck.

I see that integer/flonum/bignum checks are implemented completely in Scheme in the PR. Are you planning to continue with the solution? While I'm implementing the 64-bit floating-point numbers, I've noticed that number type checks can degrade performance even when they are implemented in the host language of Rust if I don't escape the checks into a separate path.

[leo-ard]

@raviqqe Thanks for the additional info! I shared it with people from my lab and apparently people discussed this on HN: https://news.ycombinator.com/item?id=42267058 and https://news.ycombinator.com/item?id=42267041. I didn't know Ruby had 62 bits floats!

I see that integer/flonum/bignum checks are implemented completely in Scheme in the PR. Are you planning to continue with the solution? While I'm implementing the 64-bit floating-point numbers, I've noticed that number type checks can degrade performance even when they are implemented in the host language of Rust if I don't escape the checks into a separate path.

This is a good question. Type checks can indeed be quite heavy in terms of performance. We though of replacing the existing primitives by "check-aware" primitives. For example, the ##+ host primitive could be replaced by ##+? that would return false if the two types are not fixnums (check in the host language). We have a partial implementation here:

ribbit/src/lib/nums/nums.scm

Lines 230 to 249 in 7924058

	(define (+ a b)
	(if-feature (and (not nums/bignum) (not nums/flonum))
	(##+ a b)
	(if-feature (and nums/bignum (not nums/flonum))
	(or (##+? a b)
	(bn-norm
	(##bn+ (if (bignum? a) a (fixnum->bignum a))
	(if (bignum? b) b (fixnum->bignum b)))))
	(if-feature nums/flonum
	(or (##+? a b) ;; #f if a or b is not a fixnum or if there's an oveflow
	(if (or (flonum? a) (flonum? b))
	(##fl+ (if (exact-integer? a)
	(##exact-integer->inexact-integer a)
	a)
	(if (exact-integer? b)
	(##exact-integer->inexact-integer b)
	b))
	(bn-norm ;; fixnums with overflow or either a or b is a bignum
	(##bn+ (if (bignum? a) a (fixnum->bignum a))
	(if (bignum? b) b (fixnum->bignum b))))))))))

Note that in this implementation, if-feature are run at compile time. With that in mind, the goal would be that the + operator become something like this after macro expansion (if bignums and flonums are enabled):

(define (+ a b)
  (or (##+? a b)
        (##fl+? a b)
        (##bn+? a b)
        (... other dispatch with conversions between values)))

There would be a fast path for both fixnum-fixnum and flonums-flonums operations, which I think are the most common operations. Others could be implemented by checking the types in scheme, which would be slow but less frequent.

I'm still unsure about this being the best way to do things as it would need to redefine a set of primitives for all hosts that want to be "fast". Any input would be helpful:)

[raviqqe]

The check-aware primitives look really smart! It's great that fallbacks are done only by if and call instructions against primitives although I'm not sure how big their performance impact is.

In Stak Scheme, I implemented the let-like syntaxes using the reference implementations in the R7RS specification document which are like the ones in normal lambda calculus. ;) Maybe I should revert the primitive-based let implementation back...