Re: Need some opinions on base behavior
At 4:26 PM +0100 8/24/04, Nicholas Clark wrote: On Tue, Aug 24, 2004 at 10:49:37AM -0400, Dan Sugalski wrote: As for rounding, I'm open to changes there too. Standard for computing is round-to-zero, since it's easy (drop the fractional part) but I was always taught round-to-closest-int. Too many physical sciences classes, I expect. Either way's arguably correct, and arguably horribly wrong, so I can see it being a big tossup there. I'd be confused if a computer language didn't truncate towards zero. Despite being a physical scientist by training. Fair enough -- we'll round to zero then. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
At 11:29 AM -0400 8/24/04, Matt Fowles wrote: Dan~ I'm thinking now that multiplication of integers should upgrade to a float (which is large enough to hold the result with no loss of precision), division of integers should return a bignum (or a bigrat), and all float operations should produce floats. The destination PMC type can downconvert if it wants, so: Pint = Pint / Pint Are you sure that you mean PInt * Pint -> Pfloat or do you mean to say PInt * Pint -> Pbigint Bah, I was mis-thinking. I had it in my head that a float could hold the worst-case size of an int*int, but it can't. Bignum's the thing here, I think. Or either an int or bignum, depending on the size of the result. (No bigints. It's all bignums. We may do bigrats, but I doubt it) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
Dan~ > I'm thinking now that multiplication of integers should upgrade to a > float (which is large enough to hold the result with no loss of > precision), division of integers should return a bignum (or a > bigrat), and all float operations should produce floats. The > destination PMC type can downconvert if it wants, so: > > Pint = Pint / Pint Are you sure that you mean PInt * Pint -> Pfloat or do you mean to say PInt * Pint -> Pbigint Maybe I had been debugging too long and am just brainfried. But if you could summarize your current thinking in the form bigint / bigint -> bigrat int / int -> float It would facilitate my following your exact plans. Thanks, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Re: Need some opinions on base behavior
On Tue, Aug 24, 2004 at 10:49:37AM -0400, Dan Sugalski wrote: > As for rounding, I'm open to changes there too. Standard for > computing is round-to-zero, since it's easy (drop the fractional > part) but I was always taught round-to-closest-int. Too many physical > sciences classes, I expect. Either way's arguably correct, and > arguably horribly wrong, so I can see it being a big tossup there. I'd be confused if a computer language didn't truncate towards zero. Despite being a physical scientist by training. Nicholas Clark
Re: Need some opinions on base behavior
At 11:05 AM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: I'm up for some discussion on this one. I'm tempted to leave integer binary ops integers, I've already outlined that Python as well as Perl6 silently promote to BigInt. I'd rather have Integer as the common base type that implements most of these two languages' integer type. And BTW divistion by zero behavior needs to be nailed down too. And inf handling too. Okay, here's my thought. Basic PMC operations which result in a division by zero, or operations which'd produce either an infinite or not-a-number result, throw an exception. The default MMD functions for math will do this, and folks who want a different result can override the MMD table. (Which could be made scoped, if we really wanted to, though I'm not sure I do) This doesn't address the issue of low-level ops with numbers, but we can get there later. I'm thinking now that multiplication of integers should upgrade to a float (which is large enough to hold the result with no loss of precision), division of integers should return a bignum (or a bigrat), and all float operations should produce floats. The destination PMC type can downconvert if it wants, so: Pint = Pint / Pint would produce a bignum which'd then be converted to an integer as part of the store. (I'm not that tied to the production of a bignum though. Feel free to argue me out of it if you want) As for rounding, I'm open to changes there too. Standard for computing is round-to-zero, since it's easy (drop the fractional part) but I was always taught round-to-closest-int. Too many physical sciences classes, I expect. Either way's arguably correct, and arguably horribly wrong, so I can see it being a big tossup there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Need some opinions on base behavior
Dan Sugalski <[EMAIL PROTECTED]> wrote: > I'm up for some discussion on this one. I'm tempted to leave integer > binary ops integers, I've already outlined that Python as well as Perl6 silently promote to BigInt. I'd rather have Integer as the common base type that implements most of these two languages' integer type. And BTW divistion by zero behavior needs to be nailed down too. > ... We could do them all, but... that seems more > than a little excessive. Besides the MMD table entries, there'd be a > lot of flag checking (or a *really* big set of MMD tables) which is > sub-optimal. Yep. leo
Re: Need some opinions on base behavior
On Mon, 2004-08-23 at 18:13, Dan Sugalski wrote: > The unary behavior of the types is reasonably straightforward. What > I'm puzzling over right now is the binary behavior. It's the edge > cases that are troublesome, of course -- what to do on overflow, and > what to do with fractional results. > > Fractions are an issue mainly with integer division -- in the case of > int/int, should the result be an int, or a float of some sort? Just the other day you were wondering about multidispatch on return types. Here's your chance! -- c
Re: Need some opinions on base behavior
Dan~ I was originally going to say do them all or do the integer division/no overflow check option, but then something occurred to me. We already have I registers. If someone wants speed they should be using them anyway. If someone doesn't care about speed, but wants those semantics, their compiler can emit code of the form set I0, P0 set I1, P1 add I2, I0, I1 set P2, I2 and even then the code should not slow too much (I hope) Thus, I think that I will vote for int/int -> float and int*int -> [big]int What I vote against is float + float -> int. I don't care if the result float happens to be an int, I have an unreasoning dislike of it. Also, if people are not satisfied with the options they can (and probably will) write their own PMCs to extend them. Actually that might be an argument for implementing everything, cause someone surely will so we might as well provide it. But I don't really like that, so I am sticking with my first answer. Matt On Mon, 23 Aug 2004 21:13:46 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote: > Leo's been nudging me to get the behaviours of the basic types > defined, so I'm working on updating PDD 17 with them. > > The unary behavior of the types is reasonably straightforward. What > I'm puzzling over right now is the binary behavior. It's the edge > cases that are troublesome, of course -- what to do on overflow, and > what to do with fractional results. > > Fractions are an issue mainly with integer division -- in the case of > int/int, should the result be an int, or a float of some sort? > > Overflow's an issue to some extent with addition and subtraction, but > moreso with multiplication. Should the result be promoted to a larger > type (either unconditionally, or on overflow), which one, and what > counts as overflow? (Is it exceeding the limits of the type, or > losing precision?) > > I'm up for some discussion on this one. I'm tempted to leave integer > binary ops integers, binary ops with one or two floats a float, and > binary ops with a bignum as a bignum and to heck with overflow, but I > can see arguments for a more precise answer, as well as providing a > way to specify whether you want accuracy or speed (potentially with > or without throwing an exception where promotion'd otherwise take > place and we don't). We could do them all, but... that seems more > than a little excessive. Besides the MMD table entries, there'd be a > lot of flag checking (or a *really* big set of MMD tables) which is > sub-optimal. > > This'd be a good time to make cases, folks! > -- > Dan > > --it's like this--- > Dan Sugalski even samurai > [EMAIL PROTECTED] have teddy bears and even >teddy bears get drunk > -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
Need some opinions on base behavior
Leo's been nudging me to get the behaviours of the basic types defined, so I'm working on updating PDD 17 with them. The unary behavior of the types is reasonably straightforward. What I'm puzzling over right now is the binary behavior. It's the edge cases that are troublesome, of course -- what to do on overflow, and what to do with fractional results. Fractions are an issue mainly with integer division -- in the case of int/int, should the result be an int, or a float of some sort? Overflow's an issue to some extent with addition and subtraction, but moreso with multiplication. Should the result be promoted to a larger type (either unconditionally, or on overflow), which one, and what counts as overflow? (Is it exceeding the limits of the type, or losing precision?) I'm up for some discussion on this one. I'm tempted to leave integer binary ops integers, binary ops with one or two floats a float, and binary ops with a bignum as a bignum and to heck with overflow, but I can see arguments for a more precise answer, as well as providing a way to specify whether you want accuracy or speed (potentially with or without throwing an exception where promotion'd otherwise take place and we don't). We could do them all, but... that seems more than a little excessive. Besides the MMD table entries, there'd be a lot of flag checking (or a *really* big set of MMD tables) which is sub-optimal. This'd be a good time to make cases, folks! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
