# Lua 5.3: Should min/max return a float, if it is given integer? Classic List Threaded 18 messages Open this post in threaded view
|

## Lua 5.3: Should min/max return a float, if it is given integer?

 print(math.min(1,2), math.max(1,2))--1.0, 2.0I would have expected integers.-Andrew
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 2014-06-04 18:48 GMT+02:00 Andrew Starks <[hidden email]>: > print(math.min(1,2), math.max(1,2)) > --1.0, 2.0 > I would have expected integers. RTFM. "Unless stated otherwise, all functions in this library operate with and return floats."
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On Wed, Jun 4, 2014 at 3:52 PM, Dirk Laurie wrote: 2014-06-04 18:48 GMT+02:00 Andrew Starks <[hidden email]>: > print(math.min(1,2), math.max(1,2)) > --1.0, 2.0 > I would have expected integers. RTFM. "Unless stated otherwise, all functions in this library operate with and return floats." If "should" == "The Fine Manual says so" then I guess it's a dumb question. -Andrew
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On 4 June 2014 18:27, Andrew Starks <[hidden email]> wrote: > > > > On Wed, Jun 4, 2014 at 3:52 PM, Dirk Laurie <[hidden email]> wrote: >> >> 2014-06-04 18:48 GMT+02:00 Andrew Starks <[hidden email]>: >> > print(math.min(1,2), math.max(1,2)) >> > --1.0, 2.0 >> > I would have expected integers. >> >> RTFM. >> >> "Unless stated otherwise, all functions in this library operate with >> and return floats." >> > > If "should" == "The Fine Manual says so" then I guess it's a dumb question. That's of course not the case. Dirk's bluntness was uncalled for, and as far as I know 5.3work2 is not the final release version so treating the work manual as dogma is a bit premature. In an informal quiz here at the lab, everyone expected math.max() to return an integer when given all integers. When I told them it returns a float, everyone went "oh..." and when I asked them how should it behave when given an integer and a float, opinions were mixed. Given that the operation is closed in integers, it was reasonable to assume that math.max is overloaded, like for instance `+` (hence expecting an integer when passing two integers). And like `+`, it's fair to assume that in the comparison `i < f` the integer value is promoted to float. On the other hand, given a sequence of numbers s, it can be a bit surprising that math.max(table.unpack(s)) may not return an element of s. However, in light of other behaviors such as table keys, relying on subtype preservation when dealing with a mixed bag of ints and floats is probably not a very good idea already, and I assume that if one is mixing ints and floats they are already thinking of them as floats in general. Lua 5.3 already makes some effort to preserve integers as integers when working exclusively with them in its operators. And let's recap that little "ranking" of math functions by use I posted recently :  http://lua-users.org/lists/lua-l/2014-04/msg00354.htmlHere's the Top 7. (I chose 7 because math.sin is the first fully float-to-float function there) 1) math.floor 44679 2) math.random 27874 3) math.min 16661 4) math.abs 16297 5) math.max 14023 6) math.ceil 12714 7) math.sin 11376 The landslide victory goes to math.floor, which was our main "cast to int" operator until now; with integers in the language it's safe to assume this number will go down in the future. Second place goes to math.random, which does have an integer mode of operation already. Positions 3, 4 and 5 go to functions that are often used to operate on ints, and that are quite useful for "non-mathematical" code (one can think of a gazillion uses: comparing network packet identifiers, character codepoints, etc.) Entry #6 is the leader's poor cousin. And only then the "fully float" functions start in the list. math.abs has the least compelling argument for having an integer mode since one can do ~x+1 but I know that I'd be using math.abs in my code instead of that (or code my own abs if math.abs remains float-only...). But the argument of having math.max and math.min preserve integers (and their precision) has, in my opinion, a very strong case. (Especially since math.max and math.min _are_ convenience functions after all, so the "roll your own" answer does not apply.) -- Hisham
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 Speaking as someone who doesn't understand the science behind the integer<->float conversion for various operations, my interpretation has been thus: When precision "can" be lost to represent a number as an integer, it is.  Operating on integers always seems to be faster than operating on floats/doubles so I understood this to be the motive behind introducing integers in 5.3 "where they can appear". 2.5 + 2.5 + 2 -> 2.5 + 2.5 + 2.0 -> 5.0 + 2.0 -> 7.0 -> 7
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 In reply to this post by Andrew Starks Am 04.06.2014 18:48 schröbte Andrew Starks: > print(math.min(1,2), math.max(1,2)) > --1.0, 2.0 > > I would have expected integers. It's the same with strings:      print(type(math.max("1", "2"))) > > -Andrew > Philipp
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On Wed, Jun 4, 2014 at 9:31 PM, Philipp Janda wrote: Am 04.06.2014 18:48 schröbte Andrew Starks: print(math.min(1,2), math.max(1,2)) --1.0, 2.0 I would have expected integers. It's the same with strings:     print(type(math.max("1", "2"))) -Andrew Philipp I'd be very surprised if math.max(a, b) behaved any differently from:function max(a, b)     if a > b then return a    else return b    endendi.e. no changing of types involved (and for that matter, not caring at all about types, as long as the operands have > defined). (Of course it's slightly trickier since math.max() accepts any number of values except zero, but the principle is the same.)-- Sent from my Game Boy.
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On Wed, Jun 4, 2014 at 10:37 PM, Rena wrote: On Wed, Jun 4, 2014 at 9:31 PM, Philipp Janda wrote: Am 04.06.2014 18:48 schröbte Andrew Starks: print(math.min(1,2), math.max(1,2)) --1.0, 2.0 I would have expected integers. It's the same with strings:     print(type(math.max("1", "2"))) -Andrew Philipp I'd be very surprised if math.max(a, b) behaved any differently from:function max(a, b)     if a > b then return a    else return b    endendi.e. no changing of types involved (and for that matter, not caring at all about types, as long as the operands have > defined). (Of course it's slightly trickier since math.max() accepts any number of values except zero, but the principle is the same.) -- Sent from my Game Boy. It's a brave new world when...local big = 2^63 -2  local bigger = 2^63 -1print((big < bigger) == (math.min(big, bigger) < math.max(big, bigger)))--> false local big = 2.0^63 -2 local bigger = 2.0^63 -1print((big < bigger) == (math.min(big, bigger) < math.max(big, bigger)))--> true I don't want to type too much opinion about this, lest this be something that just didn't make the cut for Work 2. I'll only say that the math library can be simple, but it has to be reasonably predictable. This would fall short of that, IMHO. -Andrew
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 In reply to this post by Rena On Jun 4, 2014, at 8:37 PM, Rena <[hidden email]> wrote: > > I'd be very surprised if math.max(a, b) behaved any differently from: > function max(a, b) >     if a > b then return a >     else return b >     end > end > > i.e. no changing of types involved (and for that matter, not caring at all about types, as long as the operands have > defined). > > (Of course it's slightly trickier since math.max() accepts any number of values except zero, but the principle is the same.) > > -- > Sent from my Game Boy. I think the problem here is the historical placement of min/max in the math library. If Lua had global min() and max() functions then I suspect most people would expect what you say to be true, allowing for polymorphic min/max functions (for any type that defined < or __le). However, placement in the math library seems kinda-sorta to suggest that they work as floating point in keeping with the rest of this library. If it were me, I’d go with the polymorphic form, but I doubt that this will happen. —Tim
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 In reply to this post by Andrew Starks We have had this discussion about math.max/math.min tow months ago:   http://lua-users.org/lists/lua-l/2014-04/msg00489.html-- Roberto
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On Wed, Jun 4, 2014 at 11:43 PM, Roberto Ierusalimschy wrote: We have had this discussion about math.max/math.min tow months ago:   http://lua-users.org/lists/lua-l/2014-04/msg00489.html -- Roberto Thank you. I did a search, but obviously not a very good one. -Andrew
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 In reply to this post by Hisham 2014-06-05 2:02 GMT+02:00 Hisham <[hidden email]>: > But the argument of having math.max and math.min preserve integers > (and their precision) has, in my opinion, a very strong case. > (Especially since math.max and math.min _are_ convenience functions > after all, so the "roll your own" answer does not apply.) Maybe there is a case for taking them out of the math library and putting them back into global, with `max(a,b)` meaning exactly the same as "(b>a) and b or a" so that they will apply to anything, particularly strings.
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On 5 June 2014 17:03, Dirk Laurie wrote: 2014-06-05 2:02 GMT+02:00 Hisham <[hidden email]>: > But the argument of having math.max and math.min preserve integers > (and their precision) has, in my opinion, a very strong case. > (Especially since math.max and math.min _are_ convenience functions > after all, so the "roll your own" answer does not apply.) Maybe there is a case for taking them out of the math library and putting them back into global, with `max(a,b)` meaning exactly the same as "(b>a) and b or a" so that they will apply to anything, particularly strings. Note that max is max(...), not max(a, b).
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 In reply to this post by Dirk Laurie-2 Le 04/06/2014 22:52, Dirk Laurie a écrit : > 2014-06-04 18:48 GMT+02:00 Andrew Starks <[hidden email]>: >> print(math.min(1,2), math.max(1,2)) >> --1.0, 2.0 >> I would have expected integers. > RTFM. > > "Unless stated otherwise, all functions in this library operate with > and return floats." > Can you please stay polite?
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 On Thu, Jun 5, 2014 at 11:23 PM, David Demelier <[hidden email]> wrote: > Can you please stay polite? I don't see what's impolite about that.  Firstly, acronyms are usually written in capital letters -- I don't think he was "shouting". http://en.wikipedia.org/wiki/RTFM : - Read The F-cking Manual - Read The Fine Manual - Read The Friendly Manual - Read The Flaming Manual (take your pick) Any of these fit the acronym, so why choose one that offends you? Kind of makes you a glass-half-empty sort of person  :o)
Open this post in threaded view
|

## Re: Lua 5.3: Should min/max return a float, if it is given integer?

 Le 06/06/2014 08:40, Coroutines a écrit : > On Thu, Jun 5, 2014 at 11:23 PM, David Demelier > <[hidden email]> wrote: > >> Can you please stay polite? > I don't see what's impolite about that.  Firstly, acronyms are usually > written in capital letters -- I don't think he was "shouting". > > http://en.wikipedia.org/wiki/RTFM : > > - Read The F-cking Manual > - Read The Fine Manual > - Read The Friendly Manual > - Read The Flaming Manual > > (take your pick) > > Any of these fit the acronym, so why choose one that offends you? > Kind of makes you a glass-half-empty sort of person  :o) > Everybody knows that RTFM is the original acronym of "read the fucking manual". We are on a friendly-list where explanations are better than just links thrown on faces.