Integer patch

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

Integer patch

Gavin Wraith
Thanks to all for the well intentioned advice about Asko
Kauppi's Integer patch. Unfortunately it has exactly the wrong
behaviour for my purposes. My OS assumes 32-bit integers with
no overflow behaviour. -1 must be the same as 0xffffffff, for
example. #defining LUA_NUMBER to int solves the problems of
calling OS routines at a stroke, but leaves me with no
floats. Lisa Parratt has confirmed what I was coming to suspect,
that major recoding is necessary to have two numeric types.
It is probably not worth the effort. I did use the mapm library
to implement bignums at one stage, but again it was not really
worth the candle.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
Reply | Threaded
Open this post in threaded view
|

Re: Integer patch

David Jones-2

On Apr 06, 2006, at 12:12, Gavin Wraith wrote:

> Thanks to all for the well intentioned advice about Asko
> Kauppi's Integer patch. Unfortunately it has exactly the wrong
> behaviour for my purposes. My OS assumes 32-bit integers with
> no overflow behaviour. -1 must be the same as 0xffffffff, for
> example. #defining LUA_NUMBER to int solves the problems of
> calling OS routines at a stroke, but leaves me with no
> floats. Lisa Parratt has confirmed what I was coming to suspect,
> that major recoding is necessary to have two numeric types.
> It is probably not worth the effort. I did use the mapm library
> to implement bignums at one stage, but again it was not really
> worth the candle.

Is userdata (boxed 32-bit unsigned ints, yay!) too slow or too
cumbersome for your requirements?

drj

Reply | Threaded
Open this post in threaded view
|

Re: Integer patch

Gavin Wraith
In message <[hidden email]> you wrote:

>
> On Apr 06, 2006, at 12:12, Gavin Wraith wrote:
>
> > Thanks to all for the well intentioned advice about Asko
> > Kauppi's Integer patch. Unfortunately it has exactly the wrong
> > behaviour for my purposes. My OS assumes 32-bit integers with
> > no overflow behaviour. -1 must be the same as 0xffffffff, for
> > example. #defining LUA_NUMBER to int solves the problems of
> > calling OS routines at a stroke, but leaves me with no
> > floats. Lisa Parratt has confirmed what I was coming to suspect,
> > that major recoding is necessary to have two numeric types.
> > It is probably not worth the effort. I did use the mapm library
> > to implement bignums at one stage, but again it was not really
> > worth the candle.
>
> Is userdata (boxed 32-bit unsigned ints, yay!) too slow or too
> cumbersome for your requirements?

Yes. 98% of my arithmetic usage is integer. I would rather not have
the tail wag the dog.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
Reply | Threaded
Open this post in threaded view
|

Re: Integer patch

Adam D. Moss
Gavin Wraith wrote:
>> Is userdata (boxed 32-bit unsigned ints, yay!) too slow or too
>> cumbersome for your requirements?
>
> Yes. 98% of my arithmetic usage is integer. I would rather not have
> the tail wag the dog.

Well, okay, don't have the tail wag the dog - use an integer
luanumber type and just use userdata for the float maths.

--adam
Reply | Threaded
Open this post in threaded view
|

Re: Integer patch

Gavin Wraith
In message <[hidden email]> you wrote:

> Gavin Wraith wrote:
> >> Is userdata (boxed 32-bit unsigned ints, yay!) too slow or too
> >> cumbersome for your requirements?
> >
> > Yes. 98% of my arithmetic usage is integer. I would rather not have
> > the tail wag the dog.
>
> Well, okay, don't have the tail wag the dog - use an integer
> luanumber type and just use userdata for the float maths.

Yes, I think that is the best solution. When I used the mapm
library to provide bignums that was in effect what I was doing.

--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/