1) Python has a complex builtin class. So we'll need one too. * Create a complex PMC. * Parse complex constants '4j' * Put these constants into the PBC?
2) We need a *array.sort (NCI) method(s) That's kind of a PITA: The fixed/resizable array PMCs don't have push/pop/unshift/shift ..., and shift/unshift will not really fly for these classes, but they have simple linear memory. The list.c based arrays OTOH have memory splitted into chunks, which complicates sorting. The compare function of sort must be overridable with PASM code.
I hope that's all finished, when I'm back from Germany on Thursday:)
"Leopold Toetsch" <l...@toetsch.at> wrote: > 1) Python has a complex builtin class. So we'll need one too. > * Create a complex PMC. > * Parse complex constants '4j'
j? I've always used i as the imaginary unit, though I believe j is used more in engineering fields ('cus they use i for current, or so I've heard). i for "imaginary" would make more sense to me, but that's just me. ;-)
Jonathan Worthington wrote: > "Leopold Toetsch" <l...@toetsch.at> wrote:
>>1) Python has a complex builtin class. So we'll need one too. >> * Create a complex PMC. >> * Parse complex constants '4j'
> j? I've always used i as the imaginary unit, though I believe j is used > more in engineering fields ('cus they use i for current, or so I've heard). > i for "imaginary" would make more sense to me, but that's just me. ;-)
> Jonathan
IMO the parser should understand both. And if noone else desperately wants to do it i'll be glad to help.
On Mon, 28 Jun 2004, Ion Alexandru Morega wrote: > Jonathan Worthington wrote: > > "Leopold Toetsch" <l...@toetsch.at> wrote:
> >>1) Python has a complex builtin class. So we'll need one too. > >> * Create a complex PMC. > >> * Parse complex constants '4j'
> > j? I've always used i as the imaginary unit, though I believe j is used > > more in engineering fields ('cus they use i for current, or so I've heard). > > i for "imaginary" would make more sense to me, but that's just me. ;-)
> > Jonathan
> IMO the parser should understand both. And if noone else desperately > wants to do it i'll be glad to help.
Cool, go for it. I'd think that for the set_(integer|number) vtable slots we'd set the real part and make the imaginary part 0, while the string version'd look for the "x + yi" version.
I think for now both i and j are fine for the imaginary part.
And I'm now thinking that we want to do mmd for assignment. Dammit. :(
Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski wrote: > <>Cool, go for it. I'd think that for the set_(integer|number) vtable > slots > we'd set the real part and make the imaginary part 0, while the string > version'd look for the "x + yi" version.
And have set_num_keyed set the real and the imaginary part (indexed as strings, say "real" and "imag") and maybe change the modulus and the argument independently. Also get_num_keyed will return the real part, imaginary part, modulus and argument (and maybe cache the last two).
>And I'm now thinking that we want to do mmd for assignment. Dammit. :(
You'll have to explain that to me. :)
I've done some more work on the String PMC and its tests, I'll send a patch later today.
MMD does the math then automatically, if the proper slots are filled. Happily, the tests don't use complex very often. It's just:
,--[ The Pie-thon README.txt ]----------------------------------------- | The benchmark here is intended to make Dan Sugalski's life difficult: `----------------------------------------------------------------------
>> And I'm now thinking that we want to do mmd for assignment. Dammit. :(
>Don't think so. We need, ehem, probably, set_complex, get_complex and so >on vtables. Complex is a basic type like integer, number, or bignum.
Probably. More a set_imaginary than set_compex, though. I don't think that's needed as such for the benchmark, though. (And should it take a BIGNUM or a NUMVAL?)
>MMD does the math then automatically, if the proper slots are filled.
Yeah. In this case, if the 1j constant is a PMC, it ought be a Complex PMC (or an Imaginary one) and then MMD should work out fine without needing slots.
>Happily, the tests don't use complex very often. It's just:
>,--[ The Pie-thon README.txt ]----------------------------------------- >| The benchmark here is intended to make Dan Sugalski's life difficult: >`----------------------------------------------------------------------
Ah, yeah, that's Guido--ever thoughtful. :) -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski wrote: > At 8:42 AM +0200 7/1/04, Leopold Toetsch wrote: > Probably. More a set_imaginary than set_compex, though. I don't think > that's needed as such for the benchmark, though. (And should it take a > BIGNUM or a NUMVAL?)
NUMVAL. But for now, I'm using strings, which works fine. Too less time to implement that whole stuff.