On Nov 4, 2004, at 10:30 PM, Brent 'Dax' Royal-Gordon wrote:
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:This is true. But how do you define a number? Do you include floating-point? Fixed-point? Bignum? Bigrat? Complex? Surreal? Matrix? N registers don't even begin to encompass all the "numbers" out there.
Floating point, and possibly integer. Those are the numeric primitives
of processors. Other aggregate mathematical types are always defined in
terms of those (in a computing context), one way or another.
Yes, but your decomposition (N2=P2; N3=P3; N1=N2+N3; P1=N1) doesn't take anything but the primitives into account.
Yes--see my subsequent message (just sent a moment ago), as that decomposition isn't what I meant. But you asked how I define a number--that's what I was answering above, from a computing perspective, not a more general question.
My point there, when I said "one way or another", was that for example, even in mathematics, you define addition, multiplication, etc. on complex numbers in terms of such operations over the real numbers. (That is, you define them in terms of operations on a pair of real numbers.) Based on the design of processors, and of Parrot, there's a good performance reason to define basic ops on integers and floating point numbers--namely, they'll often JIT down to single instructions. Such ops on PMCs won't have that performance benefit--they'll still involve table lookups and multiple function calls to execute. So a mechanism other than an op may be more appropriate there. There are a myriad of interesting mathematical types and operations, but they don't need dedicated ops to support them. (And even the seemingly "obvious" cases aren't: There are at least three different operations on vectors which could be called "multiplication". I don't think the "mul" op should be used for any of them.)
JEff
