In surreal numbers [1], the midpoint between 0 and infinity would be the simplest number greater than 0, which is { 0 | } = 1 [1] https://en.wikipedia.org/wiki/Surreal_number
On a log scale 1 is also halfway between 0 and infinity.
1.5 is the midpoint between 0 and infinity in Ruby
41–50 of 125 posts
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#42Clearly 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…
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.
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/fde88d4019ab83716...)
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#43In surreal numbers [1], the midpoint between 0 and infinity would be the simplest number greater than 0, which is { 0 | } = 1 [1] https://en.wikipedia.org/wiki/Surreal_number
Some other senses in which 1 can be thought of as the "midpoint" between 0 and ∞ come from the many common ways to invertibly map an interval onto (0, ∞), in which the midpoint of that interval maps onto 1. For example:
• tan maps (0, π/2) onto (0, ∞), and tan(π/4) = 1.
• f(x) = x/(1 - x) maps (0, 1) onto (0, ∞), and f(1/2) = 1.
• exp is an isomorphism from the reals under addition to the positive reals under multiplication. 0 is the natural "midpoint" of the reals under addition, and exp(0) = 1.
(Closely related to that last one: when dealing only with positive numbers (and their limits 0 and ∞), it's natural to think of their group operation, multiplication, for which 1 is the identity, creating a symmetry between the numbers smaller than 1 and the numbers larger than 1 under reciprocation.)
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#44Earlier quoted context omitted.
What you describe is a common problem for video games, because if the engine uses "absolute" floats for everything in the game you effectively lose precision as you move away from the origin. If your maps get very large it gets very noticeable. I remember for instance in No Man's Sky when you traveled very far in a system you'd start to see the various animations become very jerky because the precision would become t…
> A common fix for this issue is to use two sets of coordinates: you can for instance represent your world as a grid with fixed-size cells, then you translate all your models into the local cell before computing anything, this way you always have good enough precision since you effectively limit the amplitude of your floats. Isn't this in practise creating a double-precision float by adding a second "significant figu…
You can think of it that way, sure, but since you want your computations to remain as fast as possible you don't want to use the full "double-precision" float everywhere, so that's where it gets tricky. You essentially want to translate everything to your local referential once and for all, then do everything with local coordinates if possible.
It's somewhat reminiscent of segmented memory in a way.
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#45Earlier quoted context omitted.
TIL: apart from infinity (number, larger than any real number in absolute value) there are infinitesimal (number, less than any real number in absolute value and not a zero). Edit: also, those infinitesimals were the subject of political and religious controversies in 17th century Europe, including a ban on infinitesimals issued by clerics in Rome in 1632.
Those clerics were ahead of their time. They probably would have banned large cardinals as well (infinites so large we can't prove whether or not they exist.)
You win the internet, sir.
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#46Earlier quoted context omitted.
TIL: apart from infinity (number, larger than any real number in absolute value) there are infinitesimal (number, less than any real number in absolute value and not a zero). Edit: also, those infinitesimals were the subject of political and religious controversies in 17th century Europe, including a ban on infinitesimals issued by clerics in Rome in 1632.
Those clerics were ahead of their time. They probably would have banned large cardinals as well (infinites so large we can't prove whether or not they exist.)
I think a lot of cardinals around then were quite large, actually.
https://www.alamy.com/portrait-of-cardinal-flavio-chigii-163... https://www.pinterest.com/pin/462252349233672807/
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#47Earlier quoted context omitted.
TIL: apart from infinity (number, larger than any real number in absolute value) there are infinitesimal (number, less than any real number in absolute value and not a zero). Edit: also, those infinitesimals were the subject of political and religious controversies in 17th century Europe, including a ban on infinitesimals issued by clerics in Rome in 1632.
Those clerics were ahead of their time. They probably would have banned large cardinals as well (infinites so large we can't prove whether or not they exist.)
Not sure whether 'large cardinals' phrase in your message is intentional or accidental pun.
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#48Earlier quoted context omitted.
What you describe is a common problem for video games, because if the engine uses "absolute" floats for everything in the game you effectively lose precision as you move away from the origin. If your maps get very large it gets very noticeable. I remember for instance in No Man's Sky when you traveled very far in a system you'd start to see the various animations become very jerky because the precision would become t…
> A common fix for this issue is to use two sets of coordinates: you can for instance represent your world as a grid with fixed-size cells, then you translate all your models into the local cell before computing anything, this way you always have good enough precision since you effectively limit the amplitude of your floats. Isn't this in practise creating a double-precision float by adding a second "significant figu…
>> a grid with fixed-size cells
> creating a double precision float ... ?
This added top-level is uniformly distributed - so yes, it's a more precise float, but no, it's not a direct analogue.
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#49Earlier quoted context omitted.
What you describe is a common problem for video games, because if the engine uses "absolute" floats for everything in the game you effectively lose precision as you move away from the origin. If your maps get very large it gets very noticeable. I remember for instance in No Man's Sky when you traveled very far in a system you'd start to see the various animations become very jerky because the precision would become t…
This video goes into something vaguely related with how the coordinate system works in Mario 64: https://youtu.be/kpk2tdsPh0A There's a lot of interesting problems that arise when making a 3d game vs a 2d one.
This channel is a fantastic resource for anyone interested in SM64 hacking, here is another of his videos that specifically deals with floating point rounding error glitches: https://www.youtube.com/watch?v=9hdFG2GcNuA
Re: 1.5 is the midpoint between 0 and infinity in Ruby
#50Earlier quoted context omitted.
What you describe is a common problem for video games, because if the engine uses "absolute" floats for everything in the game you effectively lose precision as you move away from the origin. If your maps get very large it gets very noticeable. I remember for instance in No Man's Sky when you traveled very far in a system you'd start to see the various animations become very jerky because the precision would become t…
> A common fix for this issue is to use two sets of coordinates: you can for instance represent your world as a grid with fixed-size cells, then you translate all your models into the local cell before computing anything, this way you always have good enough precision since you effectively limit the amplitude of your floats. Isn't this in practise creating a double-precision float by adding a second "significant figu…
Kind of but you get significantly better precision than if you just use a normal double float type because doubles only push the issues further out. Especially in games you're likely already breaking the world into cells for streaming chunks into/out of memory anyways.