# [FUN] Codegolf: convert float to integer

10 messages
Open this post in threaded view
|

## [FUN] Codegolf: convert float to integer

 This post is just for fun.Global variable "x" contains some integer number in float format.Your task is to convert it to integer datatype.The code must be compatible with Lua 5.1, 5.2 and 5.3:1) on Lua 5.1/5.2 variable x doesn't change its value;2) on Lua 5.3 variable x converts its float value to corresponding integer value.This is not a solution (due to syntax error is raised on Lua 5.1):x=x|0Obvious solution takes 15 bytes:x=math.floor(x)Less obvious solution takes 14 bytes:x=math.ceil(x)There exist non-obvious solution in 13 bytes.Find it.
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 On Tue, May 21, 2019 at 3:30 PM Egor Skriptunoff <[hidden email]> wrote: > > This post is just for fun. > > Global variable "x" contains some integer number in float format. > Your task is to convert it to integer datatype. > > The code must be compatible with Lua 5.1, 5.2 and 5.3: > 1) on Lua 5.1/5.2 variable x doesn't change its value; > 2) on Lua 5.3 variable x converts its float value to corresponding integer value. > > > This is not a solution (due to syntax error is raised on Lua 5.1): > x=x|0 > > Obvious solution takes 15 bytes: > x=math.floor(x) > > Less obvious solution takes 14 bytes: > x=math.ceil(x) > > There exist non-obvious solution in 13 bytes. > Find it. Took me a few minutes, but I found it: x=next{[x]=0}
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 In reply to this post by Egor Skriptunoff-2 On 2019-05-21 22:29, Egor Skriptunoff wrote: > This post is just for fun. > > Global variable "x" contains some integer number in float format. > Your task is to convert it to integer datatype. > > The code must be compatible with Lua 5.1, 5.2 and 5.3: > 1) on Lua 5.1/5.2 variable x doesn't change its value; > 2) on Lua 5.3 variable x converts its float value to corresponding > integer value. > > > This is not a solution (due to syntax error is raised on Lua 5.1): > x=x|0 > > Obvious solution takes 15 bytes: > x=math.floor(x) > > Less obvious solution takes 14 bytes: > x=math.ceil(x) Program bytes or bytecode? I throw x=x-x%1 into the game, but I only tested it on lua5.2, ignore me when it doest work on other versions, also missed your goal of 13 bytes.         Christian
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 On Tue, May 21, 2019 at 4:01 PM Christian Thaeter <[hidden email]> wrote: > > On 2019-05-21 22:29, Egor Skriptunoff wrote: > > > This post is just for fun. > > > > Global variable "x" contains some integer number in float format. > > Your task is to convert it to integer datatype. > > > > The code must be compatible with Lua 5.1, 5.2 and 5.3: > > 1) on Lua 5.1/5.2 variable x doesn't change its value; > > 2) on Lua 5.3 variable x converts its float value to corresponding > > integer value. > > > > > > This is not a solution (due to syntax error is raised on Lua 5.1): > > x=x|0 > > > > Obvious solution takes 15 bytes: > > x=math.floor(x) > > > > Less obvious solution takes 14 bytes: > > x=math.ceil(x) > > Program bytes or bytecode? > > I throw > > x=x-x%1 > > into the game, but I only tested it on lua5.2, ignore me when it doest > work on other versions, also missed your goal of 13 bytes. > >         Christian In Lua 5.3, that fails to convert x to an integer. It remains a float.
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 In reply to this post by Jonathan Goble On Tue, May 21, 2019 at 10:55 PM Jonathan Goble <[hidden email]> wrote: Took me a few minutes, but I found it: x=next{[x]=0} Correct!
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 May be you save 1 byte in source code, but at runtime it's horrible: you create a new table object to use the double value as a key (which is then converted to integer using an unspecified rounding mode...) initialized to a dummy value 0. Then you use the next iterator to extract that key, and the table will be garbage collected. This needlessly stresses the memory allocator and the GC. And it will be very slow compared to math.floor() or math.ceil().I'm also not really sure that a table index is necessarily an integer and cannot be a double value.The only restriction being that it should not be a NaN value, because it is not comparable. But any other double value can be potentially be used as valid index (including non-integers, infinites, and denormals which are comparable and ordered within the set of doubles minus NaNs). So this pseudo-"technic" is very likely to not be portable/supported.The official doc currently says "Any value can be used as a key (not just numbers and strings) just make sure it's not `nil` or NaN (Not a Number)".It means that a table like {[0]='A', [0.1]='B'} is valid and contains two distinct pairs because keys 0 and 0.1 are both valid and distinct.You are probably using an implementation of Lua which adds the restriction to number keys for forcing them to be native integers (and then allow the backing store to be optimized by not requiring a storage vector for all integers keys, but only for numeric keys that are not part of a sequence) and otherwise store string lkeys separately.So, next{[0.1]=2} should return 0.1 (the single key which is not nil and not NaN), and not 0 (some other rounded integer key)...And your code "x=next{[x]=0}" MUST certainly fail with a runtime exception, if ever x is NaN or nil (invalid key): nothing will be stored in x, and the next iterator will not even be called, or an empty table may be silently created and the next iterator will return nil (no more keys in table) and then x will be assigned a nil value (which will be different "nil" type and no longer a "number" type).Le mar. 21 mai 2019 à 22:14, Egor Skriptunoff <[hidden email]> a écrit :On Tue, May 21, 2019 at 10:55 PM Jonathan Goble <[hidden email]> wrote: Took me a few minutes, but I found it: x=next{[x]=0} Correct!
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 > You are probably using an implementation of Lua which adds the restriction to number keys for forcing them to be native integers The Lua 5.3 and 5.4 behavior is that some floats are converted to integers when used as table keys, as noted in the manual: > The indexing of tables follows the definition of raw equality in the language. The expressions a[i] and a[j] denote the same table element if and only if i and j are raw equal (that is, equal without metamethods). In particular, floats with integral values are equal to their respective integers (e.g., 1.0 == 1). To avoid ambiguities, any float with integral value used as a key is converted to its respective integer. For instance, if you write a[2.0] = true, the actual key inserted into the table will be the integer 2. — Gabriel On Tue, May 21, 2019 at 4:33 PM Philippe Verdy <[hidden email]> wrote: > > May be you save 1 byte in source code, but at runtime it's horrible: you create a new table object to use the double value as a key (which is then converted to integer using an unspecified rounding mode...) initialized to a dummy value 0. Then you use the next iterator to extract that key, and the table will be garbage collected. This needlessly stresses the memory allocator and the GC. And it will be very slow compared to math.floor() or math.ceil(). > I'm also not really sure that a table index is necessarily an integer and cannot be a double value. > The only restriction being that it should not be a NaN value, because it is not comparable. But any other double value can be potentially be used as valid index (including non-integers, infinites, and denormals which are comparable and ordered within the set of doubles minus NaNs). So this pseudo-"technic" is very likely to not be portable/supported. > > The official doc currently says "Any value can be used as a key (not just numbers and strings) just make sure it's not nil or NaN (Not a Number)". > It means that a table like {[0]='A', [0.1]='B'} is valid and contains two distinct pairs because keys 0 and 0.1 are both valid and distinct. > You are probably using an implementation of Lua which adds the restriction to number keys for forcing them to be native integers (and then allow the backing store to be optimized by not requiring a storage vector for all integers keys, but only for numeric keys that are not part of a sequence) and otherwise store string lkeys separately. > So, next{[0.1]=2} should return 0.1 (the single key which is not nil and not NaN), and not 0 (some other rounded integer key)... > > And your code "x=next{[x]=0}" MUST certainly fail with a runtime exception, if ever x is NaN or nil (invalid key): nothing will be stored in x, and the next iterator will not even be called, or an empty table may be silently created and the next iterator will return nil (no more keys in table) and then x will be assigned a nil value (which will be different "nil" type and no longer a "number" type). > > > Le mar. 21 mai 2019 à 22:14, Egor Skriptunoff <[hidden email]> a écrit : >> >> On Tue, May 21, 2019 at 10:55 PM Jonathan Goble <[hidden email]> wrote: >>> >>> Took me a few minutes, but I found it: >>> >>> x=next{[x]=0} >>> >> >> Correct! >>
Open this post in threaded view
|

## Re: [FUN] Codegolf: convert float to integer

 In reply to this post by Philippe Verdy Op Di. 21 Mei 2019 om 23:33 het Philippe Verdy <[hidden email]> geskryf: Maybe you don't know what code golf is. It is a _game_ in which the object is write the shortest possible program, measured in bytes, that can achieve a given task. All that matters is whether it works. Maybe you also did not read the statement of the problem well enough. It was explicitly stated that the x' is an integer in float format. It can't be an invalid key. > May be you save 1 byte in source code, but at runtime it's horrible: you create a new table object to use the double value as a key (which is then converted to integer using an unspecified rounding mode...) initialized to a dummy value 0. Then you use the next iterator to extract that key, and the table will be garbage collected. This needlessly stresses the memory allocator and the GC. And it will be very slow compared to math.floor() or math.ceil(). > I'm also not really sure that a table index is necessarily an integer and cannot be a double value. > The only restriction being that it should not be a NaN value, because it is not comparable. But any other double value can be potentially be used as valid index (including non-integers, infinites, and denormals which are comparable and ordered within the set of doubles minus NaNs). So this pseudo-"technic" is very likely to not be portable/supported. > > The official doc currently says "Any value can be used as a key (not just numbers and strings) just make sure it's not nil or NaN (Not a Number)". > It means that a table like {[0]='A', [0.1]='B'} is valid and contains two distinct pairs because keys 0 and 0.1 are both valid and distinct. > You are probably using an implementation of Lua which adds the restriction to number keys for forcing them to be native integers (and then allow the backing store to be optimized by not requiring a storage vector for all integers keys, but only for numeric keys that are not part of a sequence) and otherwise store string lkeys separately. > So, next{[0.1]=2} should return 0.1 (the single key which is not nil and not NaN), and not 0 (some other rounded integer key)... > > And your code "x=next{[x]=0}" MUST certainly fail with a runtime exception, if ever x is NaN or nil (invalid key): nothing will be stored in x, and the next iterator will not even be called, or an empty table may be silently created and the next iterator will return nil (no more keys in table) and then x will be assigned a nil value (which will be different "nil" type and no longer a "number" type). > > > Le mar. 21 mai 2019 à 22:14, Egor Skriptunoff <[hidden email]> a écrit : >> >> On Tue, May 21, 2019 at 10:55 PM Jonathan Goble <[hidden email]> wrote: >>> >>> Took me a few minutes, but I found it: >>> >>> x=next{[x]=0} >>> >> >> Correct! >>