5 ms·

Clearly we'll need to some work in TruffleRuby to be fully compatible. I really hope nobody's code depends on this. Infinity 8.988465674311579e+307 4.494

Clearly we'll need to some work in TruffleRuby to be fully compatible. I really hope nobody's code depends on this. Infinity 8.988465674311579e+307 4.4942328371557893e+307 2.2471164185778946e+307 1.1235582092889473e+307 5.6177910464447366e+306 ... 32767.999999999996 16383.999999999998 8191.999999999999 4095.9999999999995 2047.9999999999998 1023.9999999999999 511.99999999999994 255.99999999999997 127.99999999999999 63.99999999999999 31.999999999999996 47.99999999999999 39.99999999999999 43.99999999999999 41.99999999999999 42.99999999999999 42.49999999999999 42.24999999999999 42.12499999999999 42.06249999999999 42.03124999999999 42.01562499999999 42.00781249999999 ... 42.00000000000363 42.00000000000181 42.0000000000009 42.00000000000045 42.00000000000022 42.00000000000011 42.00000000000005 42.00000000000002 42.00000000000001 42.0 42.0

repsilat 6y ago
Interesting -- there are more rows (incl removed rows) in yours, because the first step in TFA halves the exponent. I guess it behaves more like binary searching the list of numbers than binary searching the range of numbers, which should be more efficient when the distribution is so heavily skewed.
- aardvark179 6y ago
  Yes, in fact we have a special version of bsearch to handle all the float corner cases, and part of that deals with the max being infinity [0], we can check that and then just try the largest finite floating point number. [0] (https://github.com/oracle/truffleruby/blob/fde88d4019ab837162e15b65f58b0b3b2fd7f65c/src/main/ruby/truffleruby/core/range.rb#L117 https://github.com/oracle/truffleruby/blob/fde88d4019ab83716...)
  - stingraycharles 6y ago
    Just a shout out that I really appreciate the work you guys are doing on GraalVM, especially the polyglot parts. It’s one of the more exciting parts of Graal that I don’t see too many people talk about, it’s usually all about native image and the JIT.
dr_zoidberg 6y ago
I'm left wondering if this is real behavior, or you're doing a Douglas Adams joke...
- syncsynchalt 6y ago
  The 42 comes from the article itself. Both solutions make sense... the blog post refers to a ieee<->integer representation hack that likely finds answers faster, because it more quickly finds the values that tend to be in realistic numbers. It works by doing a binary search of all possible values representable in floating point (of which there are more for smaller numbers, due to the design tradeoff of IEEE floating point). The TruffleRuby binary search solution is also "correct" in its own way, in that it's binary searching using the actual floating point values themselves.
  - croes 6y ago
    I doubt that 42.0 > 42
    - syncsynchalt 6y ago
      That's the list of checks made by the bsearch algorithm. It will have to do at least one check near the end that's <= 42.0. EDIT: It will also be probing to the ULP level, which the print could be rounding to 42.0. That could explain why there are at least two checks of "42.0".

repsilat 6y ago

Interesting -- there are more rows (incl removed rows) in yours, because the first step in TFA halves the exponent. I guess it behaves more like binary searching the list of numbers than binary searching the range of numbers, which should be more efficient when the distribution is so heavily skewed.

aardvark179 6y ago
Yes, in fact we have a special version of bsearch to handle all the float corner cases, and part of that deals with the max being infinity [0], we can check that and then just try the largest finite floating point number. [0] (https://github.com/oracle/truffleruby/blob/fde88d4019ab837162e15b65f58b0b3b2fd7f65c/src/main/ruby/truffleruby/core/range.rb#L117 https://github.com/oracle/truffleruby/blob/fde88d4019ab83716...)
- stingraycharles 6y ago
  Just a shout out that I really appreciate the work you guys are doing on GraalVM, especially the polyglot parts. It’s one of the more exciting parts of Graal that I don’t see too many people talk about, it’s usually all about native image and the JIT.

dr_zoidberg 6y ago

I'm left wondering if this is real behavior, or you're doing a Douglas Adams joke...

syncsynchalt 6y ago
The 42 comes from the article itself. Both solutions make sense... the blog post refers to a ieee<->integer representation hack that likely finds answers faster, because it more quickly finds the values that tend to be in realistic numbers. It works by doing a binary search of all possible values representable in floating point (of which there are more for smaller numbers, due to the design tradeoff of IEEE floating point). The TruffleRuby binary search solution is also "correct" in its own way, in that it's binary searching using the actual floating point values themselves.
- croes 6y ago
  I doubt that 42.0 > 42
  - syncsynchalt 6y ago
    That's the list of checks made by the bsearch algorithm. It will have to do at least one check near the end that's <= 42.0. EDIT: It will also be probing to the ULP level, which the print could be rounding to 42.0. That could explain why there are at least two checks of "42.0".