4
1
As you may know, the typical binary floating point numbers in a computer language are quite different than the typical integer numbers in a computer language. Floating point numbers can represent a much larger range, and can represent fractional amounts, however there is a trade-off that is frequently elided.
The distance between integers is constant, and in fact the value of that constant is one. The distance between floating point numbers, however, is variable, and increases the further one travels down the number line, away from the origin at 0. At some point, that distance is so large that the floating point numbers start skipping over integers, and many integers that are technically less than the maximum value of the floating point numbers, cannot actually be represented by floating point numbers.
The challenge:
Write a program that when given the number n, will print out the first n positive integers that cannot be represented by a floating point number in your language of choice.
"First n positive integers" means, lowest in value, closest to the origin, and distinct from each other.
Infinite precision floating point numbers are not allowed.
It doesn't matter whether you choose 32 bit floats, 64 bits floats, or some other type of float, as long as it is a non-infinite precision floating point number in your language of choice, on your machine of choice.
Order of numbers does not matter
This is Code Gofl. Smallest number of characters wins.
Good luck and have fun
Example:
In Rust, using 32 bit floating point builtin type 'f32':
n=4, result = [16777217,16777219,16777221,16777223]
(updated - 1 order doesnt matter - 2 Golf->Gofl)
Smallest number of characters wins
I think you meanbytes
. If not, is there a reason you're using characters? – Jo King – 2019-02-26T05:26:36.477i just love unicode? – don bright – 2019-02-26T05:28:19.537
Do we use single precision floating point or double? – Embodiment of Ignorance – 2019-02-26T06:15:05.570
Could you please remind us how a positive integer is represented as a float? I know I can look it up, but challenges specifications should be self-contained and it would save readers the time. – xnor – 2019-02-26T06:17:21.677
1@xnor I don't think it should include this just because most language use IEEE754 floating point numbers. Other form of floating point numbers should be allowed although I don't know one. – tsh – 2019-02-26T09:03:09.260
2@donbright I recommend scoring in bytes. The reason is that, otherwise, the full code in ASCII-only golfing languages (such as CJam or Pyth) can be compressed in a unicode string that will unpack to the ASCII-only code, therefore saving characters, but not bytes. Furthermore, the byte is the actual unit of digital data storage, while "character" is a term that depends on the encoding the solution uses, and one character can even take up 6 bytes, for example. This is how the "packing" mentioned before worked before we changed the default scoring method for [tag:code-golf] to the byte count. – Erik the Outgolfer – 2019-02-26T20:45:30.087
Do the numbers have to be output in order? Or would your example be valid if it output, for example,
[16777223,16777221,16777219,16777217]
? – Sara J – 2019-02-26T23:14:22.4431@Sara-J order does not matter. Updated, thanks. – don bright – 2019-02-26T23:43:27.073
@EriktheOutgolfer sorry, Jo King already used this in their perl answer so I am kind of stuck... . For now i changed it to "Code Gofl" to indicate its not technically Code Golf. – don bright – 2019-02-26T23:56:06.070
@donbright Alright, your call. BTW it's not that code golf is strictly scored in bytes, it was in characters for a long time many years ago, it's just that I recommended scoring in bytes based on my personal experience. – Erik the Outgolfer – 2019-02-27T10:42:41.890
@EriktheOutgolfer yeah i see what you mean... next time ill probably do bytes – don bright – 2019-03-04T01:50:35.247
I don't mind switching my code to score in bytes if you want – Jo King – 2019-03-04T03:09:33.053