[coyotos-dev] [PATCH included] Test infrastructure for bignum

[Thomas Stratmann]

Shap,

don't worry. I could see you were active at a different place...

Jonathan S. Shapiro wrote:
> Thomas:
> 
> I do not mean to be ignoring you, and I did not anticipate that the
> delay would be this long. I am pushing very hard to get a particular
> piece of the Coyotos kernel working so that we can test a new board that
> just came out of prototype fabrication, and that is taking a bit longer
> than I had anticipated. I'm still working on it, but I didn't want to
> let this dangle.
It's time to gather a bigger community that can take over some of the 
bug hunting and documentation stuff ;-)

> 
> The patch survived, and I have just looked at it. If I understand the
> change correctly, then I don't understand why it is correct.
> 
> 1. I want to confirm my understanding of the sign bug, because I
>    did not see it initially. I think the problem is not that the sign
>    is being lost. It's that the logic of the accumulation operation here
>    is completely wrong. Given:
> 
>      BigNum("-15")
> 
>    we get
> 
>      negative = true
>      *this = (-0 * 10) => -0
>              + 1 => 1
> 
>    and the sign is immediately lost. Is this the problem?
Algorithmically, you're correct. The initial 'negative = true' does not 
have any effect.

If you don't like saving the sign until the end, I think

*this = *this * radix + sign * thisDigit;

with sign initialized to +1, -1 would do it as well.

 From a language perspective, I'd say it is rather dirty using a 
half-initialized object (remember we're inside the constructor here!) 
for operations (my patch has the same problem). Cleaner would be to use 
a temporary BigNum...

> 
> 2. Good catch on -0. In all other cases that is caught by the "BigNum
>    from digits" constructor. I missed it here.
Of course this could only be detected once the above problem was 
fixed... I rubbed my eyes when I actually saw a -0 coming out of my -0 
input fixture...

> 
> 
> One small issue. The correct processing for "all other cases" is to
> immediately terminate the attempt to look for further digits. So if we
> are going to adopt your logic (which is conceptually fine), then the
> last bit needs to be
> 
>    if (c != '0') break;  // end of digits in input string.
> 
> Do you agree?
It is a matter of convention, or API promise.

When constructing a BigNum from a string, I would say that it is an 
error if the string does not properly represent a bignum in the first 
place (the reason I am making this claim is that there is no way to 
return the actual valid read length, or equivalent). Am I guessing right 
that you would not like raising an exception here?

A different case IMHO is reading from an istream (this case needs to be 
discussed as well, as mentioned earlier). Here we want to be tokenizer 
friendly. Being called from a tokenizer means "here (in the stream) 
begins a bignum. parse it and return when done", and "done" can be 
interpreted to happen at eof or at the first non-digit character.

The latter case should be looked at by someone who regularly builds 
parsers and such...

Corner cases that must be clarified as well:
* when called with a base, ignore leading zeroes?
* when called without a base, the first leading zero indicates octal 
base, further ones are to be ignored?

Thomas