Re: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: John Siracusa [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? I thought about that during BigInt hacking. It could be a nice optimization if we go: Int - Int64 - BigInt on 32-bit systems that have 64-bit integer support. OTOH it makes type promotion a bit more complicated and dependent on configuration settings. Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? Either way, it'll definitely be a boon to fast integer math if 64-bit ints are used to stave off promotion to BigNum when possible. This may be especially true for languages like Perl 6 which (AFAIK) doesn't have an int64 native type specifier. So either Perl 6's int type is 64-bit where possible, or is a 32-to-64-auto-promoting type. -John
Re: Numeric semantics for base pmcs
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: At 10:56 AM -0400 8/26/04, John Siracusa wrote: Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? If you've built parrot to use 64 bit ints, it will. Hm, but does that also mean that it'll expect all ints to be 64 bit? I'm thinking of hybrid situations like Mac OS X on a G5, where the OS and all system libs are still 32-bit, but the CPU can handle 64-bit integers. We still have to generally address the whole 64 bit integer question. I've been avoiding it, but I'm not sure that's ultimately feasable. Obviously someone needs to buy you a G5 in order to adequately motivate you... ;) -John
Re: Numeric semantics for base pmcs
Felix Gallo [EMAIL PROTECTED] wrote: Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: Not the best idea. The same argument would hold for all operations that could overflow. With such a strategy will end with MMD tables that blow all processor caches. If you need a more customized behavior you can always override e.g. multiplication. If you need that really fast to, you can provide a custom PMC. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. BigNums grow on demand. It depends on value and precision. F. leo
Re: Numeric semantics for base pmcs
John Siracusa [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? I thought about that during BigInt hacking. It could be a nice optimization if we go: Int - Int64 - BigInt on 32-bit systems that have 64-bit integer support. OTOH it makes type promotion a bit more complicated and dependent on configuration settings. -John leo
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that adding or multiplying to integers give a BigInt on overflow. While at num vs int: do we automatically downgrade to int again? 6.0/2.0 = 3.0 or 3 ? leo
Re: Numeric semantics for base pmcs
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. Ah, ok. BigInt as a degenerated BigNum. I still prefer the notion that adding or multiplying to integers give a BigInt on overflow. While at num vs int: do we automatically downgrade to int again? 6.0/2.0 = 3.0 or 3 ? No. Once a real, always a real. I see no harm in collapsing appropriate rationals to ints mind...
RE: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 08:40:32 -0400, Gay, Jerry [EMAIL PROTECTED] said: Leopold Toetsch [EMAIL PROTECTED] wrote: BigNums grow on demand. It depends on value and precision. can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a double (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo
RE: Numeric semantics for base pmcs
BigNum is an arbitrary precision decimal number (Think BCD -- Binary Coded Decimal ala the Unix utility BC) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 9:12 AM To: [EMAIL PROTECTED] Subject: RE: Numeric semantics for base pmcs On Wed, 25 Aug 2004 08:40:32 -0400, Gay, Jerry [EMAIL PROTECTED] said: Leopold Toetsch [EMAIL PROTECTED] wrote: BigNums grow on demand. It depends on value and precision. can BigNum then start at sizeof(int)? overflow would auto-grow the BigNum to the appropriate size, and most integer math operations will keep space usage as low as possible. in fact, then int is just a degenerate case of BigNum, one that doesn't grow and throws an exception instead. or, maybe that's the case already, i should probably read the docs. ~jerry What is the most reasonable paradigm for scientific/high precision applications? It seems to me that this type of thing has been hashed out before, and it should be designed in a way that makes it attractive/sellable for scientists, engineers, etc. One handicap that Perl has (by reputation only) in the sciences is that it is not good for precision math. I know this is not true, and you all know this is not true, but the community(ies) at large do not know - they are stuck in the land of Fortran, and from my experience people are by-passing Perl for things like Python when they do venture out. Just out of curiosity, is BigNum like a double (16 bit) or is it just limited by the precision of the machine, i.e. 32 or 64 bit? Thanks, Brett Perl6 ToDo: http://www.parrotcode.org/todo The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Simon
RE: Numeric semantics for base pmcs
At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
Dan~ -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs 10) The destination PMC is responsible for final conversion of the inbound value I know there has been a lot of grumbling in the past about the need to create PMCs to be the LHS of operations. I don't have a real suggestion here, but I just wanted to draw attention to this recurring theme, since now would be a good time to deal with it. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
RE: Numeric semantics for base pmcs
Shouldn't 4 also have potential to produce BigInt? -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Numeric semantics for base pmcs
Oops. I meant BigNum. -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:47 PM To: Butler, Gerald; '[EMAIL PROTECTED]' Subject: RE: Numeric semantics for base pmcs At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 24, 2004 1:34 PM To: [EMAIL PROTECTED] Subject: Numeric semantics for base pmcs Okay, so: 1) We round to zero when going from float to int 2) Overflows, underflows, and division by zero throws an exception 3) All-float operations produce floats 4) Addition and subtraction of ints produces an int 5) Multiplication of two ints produces a bignum or an int, depending on the result 6) Division of two ints produces a bignum 7) Strings are treated as floats for math operations 8) Any operation with a float and an int, string, or bool produces a float 9) Any operation with a bignum produces a bignum 10) The destination PMC is responsible for final conversion of the inbound value That seem reasonable? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Numeric semantics for base pmcs
At 1:39 PM -0400 8/24/04, Simon Glover wrote: On Tue, 24 Aug 2004, Dan Sugalski wrote: 6) Division of two ints produces a bignum Surely it should only produce a bignum as a last resort. For instance, shouldn't: 4 / 3 produce a float? A float or a bignum, both are reasonable. There's that whole issue of speed, though. (And to some extent precision) Also, what about a case like: 4 / 2 Does that produce an int, a float or a bignum? Good question. 9) Any operation with a bignum produces a bignum Should there be some way to test whether a bignum can be downgraded into a float? Probably, yeah. At the moment I'm somewhat loathe to drop down to floats because of the loss of precision. The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. I don't have a choice I think is right, though I'm leaning towards an answer that's got a consistent output type, though I'm not sure what that type should be. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? -John
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. /s
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? leo
Re: Numeric semantics for base pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. What about bitwise ops BTW, e.g. left shift. That seem reasonable? Else yes. leo
Re: Numeric semantics for base pmcs
At 8:45 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 1:42 PM -0400 8/24/04, Butler, Gerald wrote: Shouldn't 4 also have potential to produce BigInt? Nope -- we don't have bigints. :) Pardon, sir? We've got the big number code, but I don't see much reason to distinguish between integers and non-integers at this level -- the only difference is exponent twiddling. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, so: 4) Addition and subtraction of ints produces an int ??? Yeah, that was wrong. Later fixed. :) 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. Int op Int gives Bigint or Int (whatever fits) for op in (abs, neg, add, sub, mul) And don't forget corner cases. I think we've got the corner cases dealt with. I think... What about bitwise ops BTW, e.g. left shift. Gah! Haven't gotten there yet. We're still working on basic math... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 6) Division of two ints produces a bignum Where bignum means both bigger than 32-bit integer and rational number? So Yes. 4 / 2 == Bignum(2/1) which doesn't get automatically downgraded to a normal int. Ok. 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Numeric semantics for base pmcs
On Tue, Aug 24, 2004 at 03:08:21PM -0400, Dan Sugalski wrote: At 8:56 PM +0200 8/24/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: 5) Multiplication of two ints produces a bignum or an int, depending on the result Why that difference? At this point I'm tempted to not have the difference and unconditionally produce a bignum. 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Nicholas Clark
Re: Numeric semantics for base pmcs
Nick writes: 2 * 3 give a bignum. That feels evil. Except that the way that $a = 2 * 3 will work is that the assignment of the bignum temporary to $a will cause $a to drop it back to an int (for most languages' choice of target PMC) ? Dan, any feeling about RISC vs. CISC? Because to me, this seems like a good place to punt, and provide two, maybe three mults: multbig: returns bignum, relies on PMC smart autounboxing multint: returns int-or-die, no unboxing multsmallest: returns parrot-defined 'smallest type that fits', balancing speed vs. compiler/interpreter autoboxing/ autounboxing hinting Most people in Perl would be happy with multbig, because frankly they don't care that their math takes .1 ms rather than .0001 ms (or whatever). But the set of people that really would rather have superfast math could drop over to multint. And, a notional Perl6 optimizing compiler could use multsmallest when it detects the conditions are right. Another concern besides speed might be sizeof(PMC) for each of the options...some of the genome/nasa guys could get kinda twitchy if bignum is 1k per, etc., etc. F.
Re: Numeric semantics for base pmcs
At Tue, 24 Aug 2004 15:19:52 -0400, Dan Sugalski wrote: At 11:47 AM -0700 8/24/04, Sean O'Rourke wrote: At Tue, 24 Aug 2004 13:33:45 -0400, Dan Sugalski wrote: 7) Strings are treated as floats for math operations I think we can do better than this by first converting a string to the least reasonable numeric type (with int float bignum), then re-dispatching to the appropriate numeric x numeric operation. Always treating strings as floats means we lose both when 2+3 != 2+3 and when one of the strings is too large to be a floating-point number. Also, doing this redispatch means that the printed and internal representations of numbers will always behave the same way. I'm still not sure about doing dynamic down-typing (or whatever it's called) to get the tighest possible type. I'm getting the distinct feeling that it's what most people want, though. :) This doesn't have to involve dynamic down-typing, only a string-to-numeric converter that returns the most specific type. After that, operations between two numeric objects are welcome to do whatever they want. I actually agree with you that it's just not worth it to check for possible down-conversions. /s
