I just learned that there are floating point numbers that have non-unique (positive) square roots:
>>>> s = {4.472135954999575e-155, 4.472135954999576e-155, 4.472135954999577e-155, 4.472135954999578e-155, 4.472135954999579e-155, 4.4721359549995795e-155, 4.47213595499958e-155}
>>>> len(s)
7
>>>> {x * x for x in s}
{2e-309}
(I suppose it's obvious in hindsight, but I still didn't expect it somehow)
@adrian@shwestrick Humm. I don't know the space but let's spitball at 2^24 cores then each would need to perform 2^40 (x2 for ref and candidate) functions. Well that can be shaved down an order or two with NaNs and if the func is odd or even.
I'd never noticed that a high percentage (~19.3%) of Warren's references in Hacker's Delight are just "personal communication with X". Random thought of the day.
Let me skip to the chase - it argues that x86 is shit because it's got variable-length encoding, is out-of-order, and does speculative execution. It then says ARM and RISC-V are much better.
Er... except they also do all those things in the fast chips. Which the writer clearly didn't know. So they're not just wrong, they're ignorant.
@TomF Perhaps sampling error but every time I've landed on hackaday it's been a bad take. The last time was some person wanting to compute exp(x)-1, did a bunch of math and came with with a worse version (that only looked better with their example cases) when expm1 was sitting there all along.
I think the root is my problem is I'm generating floats from n-m. I needs it to be blazing fast and it can't use any libs because I need 100% consistency across platforms.
@TomF@grumpygamer@arghdos 16-bits to give some "space" so that the product with (m-n) doesn't round? Anyway I'd want to reorder the product and use an explicit FMA (assuming that's good for target device).
Given a random number generator that generates points uniformly in the unit interval [0,1] can you generate uniformly distributed points in the unit circle using only algebraic functions? In a finite number of steps - so no rejection sampling, loops, recursion. No "almost always" finite either.
Just wondering about sitiations where it seems you can't avoid trig functions.
@modularformsboy@dpiponi This wouldn't be a good choice anyway. You can compute {sin(π x), cos(π x)} to very high accurate with few term using a minimax approximation. Add in the symmetry of the problem and you kill off the range reduction that would be needed for a "standard" sincospi function.
interesting problem: progressively mapping a cosmically high number of unique strings of arbitrary length to an ordered set so that we can assign an index to each string, extract a substring from each index, and filter strings not in the set.
evidently, this approach requires compression. the compressed result is functionally equivalent to a regular expression, or a schema validation system.
On twitter @sebbbi mentions a cheap approximation of sin(π x) on [-1,1]
sin(π x)/4 ≈ x - x |x|
Normally if we want a two term approximation of an odd function we're stuck with the form:
a(x) = c₁ x + c₃ x³
but if we move away from pure polynomials then another two term form is possible:
b(x) = k₁ x + k₂ x |x|
and this generalizes to however many term odd/even function approximations (filling in otherwise skipped powers with one as abs which spit into two subexpressions w & w/o abs)
Hey @mbr , I remember you did that LDS thing with integers where you had an integer representation of Phi.
How did you calculate that integer version of Phi?
Did you just multiply phi by the the maximum value the int could represent and convert to int (floor / round)?
@demofox So [0,N) where N is now not a power of two: t = NΦ, find 'd' which is the nearest integer to 't' which is coprime with N? 'd' is the additive constant and the iteration visits all the elements. Sounds right to me.