Hacker News Reader

Comment by cozzyd | Hacker News Reader

Lookup table seems silly when you can take advantage of the floating point format. In C, I think you can more or less just do something like:

    uint64_t e = (1023-mj) << 52; 
    double exp = *((double*) &e)

edit: Whether or not there's a way to express that in Scala, I don't know...

View on HN

In C you can use scalbn(), which a good compiler would hopefully optimize to something equivalent to what you wrote. Java has scalb(), presumably based on the C function.

It doesn't look like gcc (4.8.3) inlines scalbn on -O3 (unless I need another flag...). I see callq(scalbn) in the disassembly.

That's not a legal optimization as it gets all sorts of edge cases wrong. For example scalbn(0, anything) is zero, whereas simply adding to the exponent will produce some arbitrary power of two or infinity.

Scala has bitewise operators

http://www.tutorialspoint.com/scala/scala_bitwise_operators....

So the "<<" is easy enough to cover.

I do not know what the * is going, if it involves pointer something something then it may not be possible to replicate.

I'm just reinterpreting the 64-bit integer as a double-precision floating point number (there are other ways to do this in C, for example using a union).

Java has a type called bytebuffer that might do the trick: http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer...

I don't know how that would get optimized by the jit at runtime though.

Don't be silly. These functions are built into `Float` and `Double`.

http://docs.oracle.com/javase/7/docs/api/java/lang/Double.ht...

Both are marked as native functions in OpenJDK 7:

http://grepcode.com/file/repository.grepcode.com/java/root/j...

From the article, she says they tried "1.0 / (1 << mj)", which turned out to be slower than the lookup table. May or may not be equivalent to java.lang.Math.scalb, I dunno.

That doesn't look like valid Scala code.

> In C

So, not valid Scala then.

Reply on news.ycombinator.com