At 07:10 PM 7/5/2001 -0400, Bryan C. Warnock wrote:
>On Thursday 05 July 2001 02:11 pm, Dan Sugalski wrote:
> > =begin question
> >
> > Should we scrap the buffer pointer and just tack the buffer on the end
> > of the structure? Saves a level of indirection, but means if we need
> > to make the buffer bigger we have to adjust anything pointing to it.
> >
> > =end question
D'oh! I thought I'd chopped those question sections out!
>This is probably silly to consider, and it may have been brought up before,
>and, of course, I'm bringing it up *after* you've already closed it out, but
>leaving it as a buffer pointer could make string->number->string conversions
>almost as simple as a pointer copy.
Yep, it could. Not likely, but possible. What is likely is that we'll see a
bigint->bigfloat conversion that consists of swapping vtable pointers in
the main PMC and (maybe) setting the flags in the number struct.
>Taken to its extreme, you could run all conversions through bignum (or
>bigfloat), if you decided not to rely on platform support for it. This
>would give you a single piece of code to handle number detection and
>manipulation, which means potential modularization (perhaps a third-party
>lib), consistent results across platforms, and, well, just one piece of code
>to tweak and maintain. (I think that that could also include bigocts,
>bighexs, and bigbins, too.) Taken to its extreme extreme, there wouldn't
>even really need to be a big* type - just big* code, a flag, and builtin
>logic to treat a regular string as a big*.
I should point out that the internal representation of large numbers isn't
going to be huge strings of ASCII characters--we'll probably be an array of
15-bit integers. (As Hong pointed out a while ago, doing that makes
handling multiplication reasonably simple. Might go to arrays of 31-bit
integers on 64-bit platforms) Though I might be misreading you here. (I
probably am)
I think making bigint and bigfloat separate things is a reasonable
performance win, but I might be wrong here.
>Taken to its not-so-extreme-case, if you make an assumption (which may be
>bad Bad BAD!) that most numeric work would have an implicit exponent of
>10^0, then it *is* a simple pointer copy - at least until the big* decides
>to normalize it to something else. That would cause the big* and the string
>value to get out of sync, but you're going to need to address the conversion
>back anyway.....
Assumptions are A Bad Thing. Explicit guarantees, however... If it turns
out that an implicit exponent of 10^0 for bigints is warranted (and I don't
see why it'd be a bad thing, though performance would probably be a little
dodgy doing 10^45 + 10^46) then I'm all for doing that.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
