Lua 5.3 work1 Considering math.isinteger or type()

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Miles Bader-2
Thijs Schreijer <[hidden email]> writes:
> Then I would rather have a single type() function and replace its
> number' return value with the new types. Big incompatibility but the
> new integer division operator already is. Incompatible but clean.

Predicates are actually _more_ clean, and yet aren't incompatible
("isnumber" and "isinteger"/"isfloat" can exist simultaneously).

If you are worried about function namespace pollution (I'm not,
particularly, but ...), it's also possible to use a predicate-style
solution with a separate type namespace, e.g. "istype(OBJ, TYPE)",
where TYPE is 'number', 'float', 'table', etc.

-miles

--
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Philipp Janda
Am 24.07.2013 06:41 schröbte Miles Bader:

> Thijs Schreijer <[hidden email]> writes:
>> Then I would rather have a single type() function and replace its
>> number' return value with the new types. Big incompatibility but the
>> new integer division operator already is. Incompatible but clean.
>
> Predicates are actually _more_ clean, and yet aren't incompatible
> ("isnumber" and "isinteger"/"isfloat" can exist simultaneously).
>
> If you are worried about function namespace pollution (I'm not,
> particularly, but ...), it's also possible to use a predicate-style
> solution with a separate type namespace, e.g. "istype(OBJ, TYPE)",
> where TYPE is 'number', 'float', 'table', etc.

How about a compromise:

If called like this:

     type( v )

the `type` function returns one of the eight basic type names like it is
now.
If called with extra string arguments:

     type( v, "integer" )

it returns the first extra string argument that matches the type of the
value, or nil if none matches.

This way we can use it as predicate for overlapping types:

    if type( v, "float" ) then ... end

and still dispatch on the type:

    callbacks[ type( v ) ]( x, y, z )

and even combine those two methods:

    callbacks[ type( v, "callable", "indexable" ) or type( v ) ]( x, y, z )

But I think the reason to introduce type predicates (virtual types such
as "callable") is a reason to *not* use them for the integer/float
distinction: there may be other objects that implement float-like or
integer-like interfaces, and we would still have the same problem as
with functions and is_callable ...

IMHO, virtual types would be better handled with something like:

    has"__index,__newindex,__len,__ipairs"( v )    --> array-like type
or table
    has"__call"( f )   --> callable type or function

with some additional logic to handle the predefined capabilities of
numbers, strings, tables, and functions.

>
> -miles
>

Philipp




Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Andrew Starks
On Wed, Jul 24, 2013 at 1:45 AM, Philipp Janda <[hidden email]> wrote:
> Am 24.07.2013 06:41 schröbte Miles Bader:
>

<snip>

>
> How about a compromise:
>
> If called like this:
>
>     type( v )
>
> the `type` function returns one of the eight basic type names like it is
> now.
> If called with extra string arguments:
>
>     type( v, "integer" )
>
> it returns the first extra string argument that matches the type of the
> value, or nil if none matches.

I'm still not sure why `type.isfloat(x)` (etc) isn't getting any love,
but this works too and as you point out...

>
> This way we can use it as predicate for overlapping types:
>
>    if type( v, "float" ) then ... end
>
> and still dispatch on the type:
>
>    callbacks[ type( v ) ]( x, y, z )
>
> and even combine those two methods:
>
>    callbacks[ type( v, "callable", "indexable" ) or type( v ) ]( x, y, z )

... has the advantage of being able to check it against multiple type
properties.

>
> But I think the reason to introduce type predicates (virtual types such as
> "callable") is a reason to *not* use them for the integer/float distinction:
> there may be other objects that implement float-like or integer-like
> interfaces, and we would still have the same problem as with functions and
> is_callable ...
>
> IMHO, virtual types would be better handled with something like:
>
>    has"__index,__newindex,__len,__ipairs"( v )    --> array-like type or
> table
>    has"__call"( f )   --> callable type or function
>
> with some additional logic to handle the predefined capabilities of numbers,
> strings, tables, and functions.
>
>>
>> -miles
>>
>
> Philipp


This all points to a larger conversation about Lua's type system, as
opposed to what one can slightly change/add in order to find out if a
number is a float.

Does Lua need facilities beyond a string name associated with a
value's basic (sometimes vague) type?

I think I'm saying mostly the same thing, but how about "interfaces",
which I think gets at "has" and answers most of what subtypes is
after.

Example: A number supports the float and integer interface.

Example: My object, with all of the arithmetic metamethods defined,
includes this field in its metatable:

mt.__interface = "number"


Now libraries that respect interfaces know that my object can be
treated as a number.

For multiple interfaces:

mt.__interface = {"ordinal", "string"}

I'm not sure how it could look, but one could imagine functions having
an interface that included supported arguments and expected return
values. I would imagine that this would not be in the language. It
would only be facilitated by this sort of thing.


-Andrew


On Wed, Jul 24, 2013 at 1:45 AM, Philipp Janda <[hidden email]> wrote:

> Am 24.07.2013 06:41 schröbte Miles Bader:
>
>> Thijs Schreijer <[hidden email]> writes:
>>>
>>> Then I would rather have a single type() function and replace its
>>> number' return value with the new types. Big incompatibility but the
>>> new integer division operator already is. Incompatible but clean.
>>
>>
>> Predicates are actually _more_ clean, and yet aren't incompatible
>> ("isnumber" and "isinteger"/"isfloat" can exist simultaneously).
>>
>> If you are worried about function namespace pollution (I'm not,
>> particularly, but ...), it's also possible to use a predicate-style
>> solution with a separate type namespace, e.g. "istype(OBJ, TYPE)",
>> where TYPE is 'number', 'float', 'table', etc.
>
>
> How about a compromise:
>
> If called like this:
>
>     type( v )
>
> the `type` function returns one of the eight basic type names like it is
> now.
> If called with extra string arguments:
>
>     type( v, "integer" )
>
> it returns the first extra string argument that matches the type of the
> value, or nil if none matches.
>
> This way we can use it as predicate for overlapping types:
>
>    if type( v, "float" ) then ... end
>
> and still dispatch on the type:
>
>    callbacks[ type( v ) ]( x, y, z )
>
> and even combine those two methods:
>
>    callbacks[ type( v, "callable", "indexable" ) or type( v ) ]( x, y, z )
>
> But I think the reason to introduce type predicates (virtual types such as
> "callable") is a reason to *not* use them for the integer/float distinction:
> there may be other objects that implement float-like or integer-like
> interfaces, and we would still have the same problem as with functions and
> is_callable ...
>
> IMHO, virtual types would be better handled with something like:
>
>    has"__index,__newindex,__len,__ipairs"( v )    --> array-like type or
> table
>    has"__call"( f )   --> callable type or function
>
> with some additional logic to handle the predefined capabilities of numbers,
> strings, tables, and functions.
>
>>
>> -miles
>>
>
> Philipp
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Tom N Harris
On Wednesday, July 24, 2013 09:57:55 AM Andrew Starks wrote:
> This all points to a larger conversation about Lua's type system, as
> opposed to what one can slightly change/add in order to find out if a
> number is a float.
>

Does Lua's type system even differentiate between float and integer, or is
this just an implementation detail? If the later, then exposing the difference
should not be done outside of the debug library.

--
tom <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Thijs Schreijer
In reply to this post by Andrew Starks
the missing love (from my part) is because the proposed isxxxxx() functions can be easily created on top of the most minimal required function to detect the difference of types.

Having read most of it I think my preference would be a ˋsubtype()ˋ function, that would honor an ˋ__subtypeˋ metamethod (and, optionally, in absence of ˋ__subtypeˋ would return the name of a metatable).

everything else can be easily built as an extension on top of this.

Thijs

sorry for top posting, on mobile...


Andrew Starks <[hidden email]>schreef:


On Wed, Jul 24, 2013 at 1:45 AM, Philipp Janda <[hidden email]> wrote:
> Am 24.07.2013 06:41 schröbte Miles Bader:
>

<snip>

>
> How about a compromise:
>
> If called like this:
>
>     type( v )
>
> the `type` function returns one of the eight basic type names like it is
> now.
> If called with extra string arguments:
>
>     type( v, "integer" )
>
> it returns the first extra string argument that matches the type of the
> value, or nil if none matches.

I'm still not sure why `type.isfloat(x)` (etc) isn't getting any love,
but this works too and as you point out...

>
> This way we can use it as predicate for overlapping types:
>
>    if type( v, "float" ) then ... end
>
> and still dispatch on the type:
>
>    callbacks[ type( v ) ]( x, y, z )
>
> and even combine those two methods:
>
>    callbacks[ type( v, "callable", "indexable" ) or type( v ) ]( x, y, z )

... has the advantage of being able to check it against multiple type
properties.

>
> But I think the reason to introduce type predicates (virtual types such as
> "callable") is a reason to *not* use them for the integer/float distinction:
> there may be other objects that implement float-like or integer-like
> interfaces, and we would still have the same problem as with functions and
> is_callable ...
>
> IMHO, virtual types would be better handled with something like:
>
>    has"__index,__newindex,__len,__ipairs"( v )    --> array-like type or
> table
>    has"__call"( f )   --> callable type or function
>
> with some additional logic to handle the predefined capabilities of numbers,
> strings, tables, and functions.
>
>>
>> -miles
>>
>
> Philipp


This all points to a larger conversation about Lua's type system, as
opposed to what one can slightly change/add in order to find out if a
number is a float.

Does Lua need facilities beyond a string name associated with a
value's basic (sometimes vague) type?

I think I'm saying mostly the same thing, but how about "interfaces",
which I think gets at "has" and answers most of what subtypes is
after.

Example: A number supports the float and integer interface.

Example: My object, with all of the arithmetic metamethods defined,
includes this field in its metatable:

mt.__interface = "number"


Now libraries that respect interfaces know that my object can be
treated as a number.

For multiple interfaces:

mt.__interface = {"ordinal", "string"}

I'm not sure how it could look, but one could imagine functions having
an interface that included supported arguments and expected return
values. I would imagine that this would not be in the language. It
would only be facilitated by this sort of thing.


-Andrew


On Wed, Jul 24, 2013 at 1:45 AM, Philipp Janda <[hidden email]> wrote:

> Am 24.07.2013 06:41 schröbte Miles Bader:
>
>> Thijs Schreijer <[hidden email]> writes:
>>>
>>> Then I would rather have a single type() function and replace its
>>> number' return value with the new types. Big incompatibility but the
>>> new integer division operator already is. Incompatible but clean.
>>
>>
>> Predicates are actually _more_ clean, and yet aren't incompatible
>> ("isnumber" and "isinteger"/"isfloat" can exist simultaneously).
>>
>> If you are worried about function namespace pollution (I'm not,
>> particularly, but ...), it's also possible to use a predicate-style
>> solution with a separate type namespace, e.g. "istype(OBJ, TYPE)",
>> where TYPE is 'number', 'float', 'table', etc.
>
>
> How about a compromise:
>
> If called like this:
>
>     type( v )
>
> the `type` function returns one of the eight basic type names like it is
> now.
> If called with extra string arguments:
>
>     type( v, "integer" )
>
> it returns the first extra string argument that matches the type of the
> value, or nil if none matches.
>
> This way we can use it as predicate for overlapping types:
>
>    if type( v, "float" ) then ... end
>
> and still dispatch on the type:
>
>    callbacks[ type( v ) ]( x, y, z )
>
> and even combine those two methods:
>
>    callbacks[ type( v, "callable", "indexable" ) or type( v ) ]( x, y, z )
>
> But I think the reason to introduce type predicates (virtual types such as
> "callable") is a reason to *not* use them for the integer/float distinction:
> there may be other objects that implement float-like or integer-like
> interfaces, and we would still have the same problem as with functions and
> is_callable ...
>
> IMHO, virtual types would be better handled with something like:
>
>    has"__index,__newindex,__len,__ipairs"( v )    --> array-like type or
> table
>    has"__call"( f )   --> callable type or function
>
> with some additional logic to handle the predefined capabilities of numbers,
> strings, tables, and functions.
>
>>
>> -miles
>>
>
> Philipp
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Andrew Starks
On Wed, Jul 24, 2013 at 3:34 PM, Thijs Schreijer
<[hidden email]> wrote:
> the missing love (from my part) is because the proposed isxxxxx() functions can be easily created on top of the most minimal required function to detect the difference of types.
>
> Having read most of it I think my preference would be a ˋsubtype()ˋ function, that would honor an ˋ__subtypeˋ metamethod (and, optionally, in absence of ˋ__subtypeˋ would return the name of a metatable).
>
> everything else can be easily built as an extension on top of this.
>
> Thijs

I see. Yes, it is trivial to make an adhoc isxxx function. What it
does provide is a clean what to accomplish what subtype accomplishes,
without leading to the inevitable, "what about subsubtype?"

Consider:

type.isnumber(2.1) --> true
type.isfloat(2.1) --> true
type.isinteger(2.1) -->false

Then later, in some Haskel-esque version of Lua:

type.isordinal(2.1) -->true

A function gives you more power than what equality to a string can.
Also, this keeps type related stuff inside of `type` and it doesn't
break:

type(2.1) --> "number"

That said, I like:

type(2.1, "float", "number") --> true

much better.

I'm going to steal that idea for my personal monkeypatched `type`,
which has to be *the* most abused standard library function in Lua.

-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Petite Abeille
In reply to this post by David Demelier

On Jul 17, 2013, at 10:10 AM, David Demelier <[hidden email]> wrote:

> I just hope that one of these 2 solutions will be approved and added
> for the final Lua 5.3

What about neither?

Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent? And a number stays a number? Irrespectively of internal representation? Or?

Joshua Jensen, all the way back on July 6, 2 bazillions messages ago, in reply to "[ANN] Lua 5.3.0 (work1) now available", said:

"I played around with this a bit.  The only thing I found that appears to be missing is the ability to determine the actual type of the number. "

To which LHF replied:

"One shouldn't need to do this but you can do it as follows: … --[[ clever piece of Lua code here ]]--"






Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Jorge Visca
On 24/07/13 19:39, Petite Abeille wrote:
> On Jul 17, 2013, at 10:10 AM, David Demelier <[hidden email]> wrote:
>
>> I just hope that one of these 2 solutions will be approved and added
>> for the final Lua 5.3
> What about neither?

Me myself, haven't ever seen the necessity of knowing whether a number
is integer or not. In my own programs, at least. In application space,
if I need an "integer" I call floor().
A transparent internal integer representation for numbers, whenever the
VM considers appropriate, suits me perfectly. The more transparent, the
better.

Jorge

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Roberto Ierusalimschy
In reply to this post by Petite Abeille
> Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent? And a number stays a number? Irrespectively of internal representation? Or?

The difference between integers and floats should not bother most
programmers, but it is not transparent (e.g., you can distinguish them
using a clever piece of code). It is not totally unlike +0.0 versus
-0.0, which are equal all the time except when they are not.

(Actually, the only use I see for this functionality is when linearizing
data, so that we can save an integer as an integer and a float as a
float. I do not know of any other real use.)

The fact that most people should not bother with this difference was
the initial motivation to put the distinction in the debug library.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Jay Carlson
In reply to this post by Petite Abeille
On Jul 24, 2013, at 6:39 PM, Petite Abeille wrote:

> On Jul 17, 2013, at 10:10 AM, David Demelier <[hidden email]> wrote:
>
>> I just hope that one of these 2 solutions will be approved and added
>> for the final Lua 5.3
>
> What about neither?
>
> Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent?

No. For some numbers n>0, n+1==n. For other numbers, n+1<0.

In general, you can't tell by static inspection what will happen when the "+" operator is used.

> And a number stays a number? Irrespectively of internal representation? Or?

Yes, numbers stay numbers. Sometimes their behavior between the maximum precise integral float (probably 2^53) and the maximum unsigned int interpreted as a 2s complement number (probably 2^63-1) may produce unexpectedly precise results compared to Lua 5.2. The behavior above that range is...well, not intuitive to me.

I would guess just about all integer-oriented Lua 5.2 code starts blowing up at around 2^53, since if n+1==n, then (n+1)-1~=n, etc etc etc.

OpenWrt does have a "transparent, except for the ability to precisely represent [2^53+1, 2^63-1]" patch.

Jay
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

David Demelier
In reply to this post by Petite Abeille
2013/7/25 Petite Abeille <[hidden email]>:

>
> On Jul 17, 2013, at 10:10 AM, David Demelier <[hidden email]> wrote:
>
>> I just hope that one of these 2 solutions will be approved and added
>> for the final Lua 5.3
>
> What about neither?
>
> Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent? And a number stays a number? Irrespectively of internal representation? Or?
>
> Joshua Jensen, all the way back on July 6, 2 bazillions messages ago, in reply to "[ANN] Lua 5.3.0 (work1) now available", said:
>
> "I played around with this a bit.  The only thing I found that appears to be missing is the ability to determine the actual type of the number. "
>
> To which LHF replied:
>
> "One shouldn't need to do this but you can do it as follows: … --[[ clever piece of Lua code here ]]--"
>

The first idea was to add the complement of math.isfloat so it's
easier to use without the need to remember which function is available
to know the subtype.

But then, a lot of user thought that better ideas could be used such
as __type metamethod and such.

--
Demelier David

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Sean Conner
In reply to this post by Petite Abeille
It was thus said that the Great Petite Abeille once stated:
>
> Out of curiosity… as the 46 (and counting) messages in this thread haven't
> made it very clear, at least to me… why do we even care if a number is an
> integer, float, real, double, whatnot? Isn't the purpose of that int vs.
> float dichotomy to be purely an implementation detail? Wholly transparent?
> And a number stays a number? Irrespectively of internal representation?
> Or?

  As a side project, I'm playing around with bindings to ptrace().  ptrace()
is a function that deals primarily with addresses [1].  On a 32-bit system
there is no real issues [2] but on a 64-bit system it really is an issue
[3].  But I'm willing to conceed that what I'm working on might be a bit out
there.

  -spc (But other than that, yes, I haven't really had an issue with Lua
        numbers ... )

[1] In another process no less!

[2] Well, addresses are technically 32 bit unsigned quantities but
        lua_Integer is a signed quantity.  I am trying to be very careful on
        how I write the interface to ptrace(), but it's still mostly
        untested code at this point.

[3] I did do a "proof-of-concept" 64-bit version of the code, but
        instead of:

                uint32_t addr = SOMEVALUE;
                lua_pushnumber(L,addr);

        I did:

                uint64_t addr = SOMEVALUE;
                lua_pushlstring(L,(char *)&addr,sizeof(addr));

        with some other minor tweaks to the Lua side of things.  It works,
        but I'm not fully happy with it.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Tim Hill
In reply to this post by Roberto Ierusalimschy

On Jul 24, 2013, at 4:48 PM, Roberto Ierusalimschy <[hidden email]> wrote:

> The difference between integers and floats should not bother most
> programmers, but it is not transparent (e.g., you can distinguish them
> using a clever piece of code). It is not totally unlike +0.0 versus
> -0.0, which are equal all the time except when they are not.
>
> (Actually, the only use I see for this functionality is when linearizing
> data, so that we can save an integer as an integer and a float as a
> float. I do not know of any other real use.)
>
> The fact that most people should not bother with this difference was
> the initial motivation to put the distinction in the debug library.
>

Will this remain true if (when?) the bit operator library gets extended to 64 bits? So far as I understand it, values between 2^52 and 2^64 are going to be a gray area in this case, since the "same" numeric value will behave differently depending on if its held as an integer or floating point?

--Tim



Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Lorenzo Donati-3
In reply to this post by Roberto Ierusalimschy
On 25/07/2013 1.48, Roberto Ierusalimschy wrote:
>> Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent? And a number stays a number? Irrespectively of internal representation? Or?
>
[snip]
>
> The fact that most people should not bother with this difference was
> the initial motivation to put the distinction in the debug library.

As someone else has proposed, it could be worth introducing in 5.3 a new
global table ("lua" or "sys", whatever - I like "lua" FWIW), to
avoid the "kitchen sink" approach to debug library.

In this way future functions that have no place in the global space or
other namespaces could be put there. This could be a small, but
significant addition to Lua.

Moreover, as Miles stated, for security reasons one should be able to
delete debug library without impairing functionalities which are not
debug-related and a security risk.

FWIW I'd also like to see a clean-up of the global namespace from less
used functions (I mean - less used in small scripts), like raw*,
set/getmetatable, collectgarbage, ...

This could be a first little step to that goal.

>
> -- Roberto
>
>


Cheers

-- Lorenzo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Enrico Colombini
On 25/07/2013 14.23, Lorenzo Donati wrote:
> As someone else has proposed, it could be worth introducing in 5.3 a new
> global table ("lua" or "sys", whatever - I like "lua" FWIW), to
> avoid the "kitchen sink" approach to debug library.

"reflection"?
(just bikeshedding)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Roberto Ierusalimschy
In reply to this post by Tim Hill
> > The fact that most people should not bother with this difference was
> > the initial motivation to put the distinction in the debug library.
> >
>
> Will this remain true if (when?) the bit operator library gets extended to 64 bits? So far as I understand it, values between 2^52 and 2^64 are going to be a gray area in this case, since the "same" numeric value will behave differently depending on if its held as an integer or floating point?

You do not need bit operators for that. As an example, for any x in this
gray area, (x + 1 == x) is true iff x is held as a float. My point is
that, most of the time, numbers will have the "expected" type, mainly
when they are in this gray area.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Andrew Starks
In reply to this post by David Demelier
On Thu, Jul 25, 2013 at 2:28 AM, David Demelier
<[hidden email]> wrote:

> 2013/7/25 Petite Abeille <[hidden email]>:
>>
>> On Jul 17, 2013, at 10:10 AM, David Demelier <[hidden email]> wrote:
>>
>>> I just hope that one of these 2 solutions will be approved and added
>>> for the final Lua 5.3
>>
>> What about neither?
>>
>> Out of curiosity… as the 46 (and counting) messages in this thread haven't made it very clear, at least to me… why do we even care if a number is an integer, float, real, double, whatnot? Isn't the purpose of that int vs. float dichotomy to be purely an implementation detail? Wholly transparent? And a number stays a number? Irrespectively of internal representation? Or?
>>
>> Joshua Jensen, all the way back on July 6, 2 bazillions messages ago, in reply to "[ANN] Lua 5.3.0 (work1) now available", said:
>>
>> "I played around with this a bit.  The only thing I found that appears to be missing is the ability to determine the actual type of the number. "
>>
>> To which LHF replied:
>>
>> "One shouldn't need to do this but you can do it as follows: … --[[ clever piece of Lua code here ]]--"
>>
>
> The first idea was to add the complement of math.isfloat so it's
> easier to use without the need to remember which function is available
> to know the subtype.
>
> But then, a lot of user thought that better ideas could be used such
> as __type metamethod and such.
>
> --
> Demelier David
>

I believe that the this thread was hijacked (I'm guilty) by a larger
discussion on type. Sorry about that!

-Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Tim Hill
In reply to this post by Roberto Ierusalimschy

On Jul 25, 2013, at 6:08 AM, Roberto Ierusalimschy <[hidden email]> wrote:

The fact that most people should not bother with this difference was
the initial motivation to put the distinction in the debug library.


Will this remain true if (when?) the bit operator library gets extended to 64 bits? So far as I understand it, values between 2^52 and 2^64 are going to be a gray area in this case, since the "same" numeric value will behave differently depending on if its held as an integer or floating point?

You do not need bit operators for that. As an example, for any x in this
gray area, (x + 1 == x) is true iff x is held as a float. My point is
that, most of the time, numbers will have the "expected" type, mainly
when they are in this gray area.

Sorry I didn't quite make myself clear. I was thinking of the case of something like this:

function mask64(x, y)
-- Insert checking code here???
return bit64.and(x,y) != 0
end

Assuming "bit64.and()" is a 64-bit aware bitwise AND function. Depending on how such a library works, won't SOMEONE (bit library or the above function) have to check if x/y are float or integer, for the gray area?

I think what I'm hearing is that (x+1 == x) is the "blessed" way to do this check going forward?

--Tim

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Eric Wing
In reply to this post by Petite Abeille
> Out of curiosity… as the 46 (and counting) messages in this thread haven't
> made it very clear, at least to me… why do we even care if a number is an
> integer, float, real, double, whatnot? Isn't the purpose of that int vs.
> float dichotomy to be purely an implementation detail? Wholly transparent?
> And a number stays a number? Irrespectively of internal representation? Or?

For me, knowing this is important for language binding/bridging.
Sometimes knowing the type is important for doing the more optimal
thing, and in a few cases doing the right thing. For example, in
Cocoa, I may need to know what the number type is to box it with the
correct incantation of NSNumber method constructors (i.e. is it a
double or integer).

It isn't the common case, but it does come up and this isn't a debug usage.

I see that the C API already has a lua_isinteger which suits my
particular needs already. However, if I implemented more of the
language bridge on the Lua side instead of the C side, this would be a
bigger issue for me.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.3 work1 Considering math.isinteger or type()

Jay Carlson
In reply to this post by Sean Conner
On Jul 25, 2013, at 3:43 AM, Sean Conner wrote:

>  As a side project, I'm playing around with bindings to ptrace().  ptrace()
> is a function that deals primarily with addresses [1].  On a 32-bit system
> there is no real issues [2] but on a 64-bit system it really is an issue
> [3].

Bet it isn't. Which architecture is handing you userspace pointers outside the range of precise 64-bit doubles? (Amusingly you even get additional range if the pointers are 4-byte aligned.)

Jay
1234