You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given that the Lurk reduction performs the bit decomposition anyway, it should be very cheap to make this available directly. This is not an idle consideration because iterating bits is an important operation. For example:
(letrec ((odd? (lambda (x) (< (/ x 2) 0)))
(fastexp (lambda (b e)
(if (= e 0)
1
(if (odd? e)
(* b (fastexp (* b b) (/ (- e 1) 2)))
(fastexp (* b b) (/ e 2)))))))
(fastexp 3 3))
We could just implement odd?, which would be cheap and yield high value. This might not be the globally best answer, but it's an obvious and simple way to solve the immediate problem at hand.
A complementary idea that might be useful in slightly different circumstances would to just return the value of the least-significant bit, as a Num and/or u64. Implementing both would be annoying, and it's probably enough to just use u64 — since that will behave 'as if' a Num when used in such a context. Extending that logic to consider future UInt types, I suppose the natural thing do here would be to return a U1 — which we obviously don't currently have.
For now, I think just implementing odd? would be valuable.
The text was updated successfully, but these errors were encountered:
It's great that we can get a handle on the underlying bit decomposition through trickery like this:
But even if inlined manually (which is pretty cryptic), this costs 6 iterations.
Given that the Lurk reduction performs the bit decomposition anyway, it should be very cheap to make this available directly. This is not an idle consideration because iterating bits is an important operation. For example:
We could just implement
odd?
, which would be cheap and yield high value. This might not be the globally best answer, but it's an obvious and simple way to solve the immediate problem at hand.A complementary idea that might be useful in slightly different circumstances would to just return the value of the least-significant bit, as a
Num
and/oru64
. Implementing both would be annoying, and it's probably enough to just useu64
— since that will behave 'as if' aNum
when used in such a context. Extending that logic to consider futureUInt
types, I suppose the natural thing do here would be to return aU1
— which we obviously don't currently have.For now, I think just implementing
odd?
would be valuable.The text was updated successfully, but these errors were encountered: