CoCoA » CoCoALib

I've just removed the explicit keyword from the BigInt ctor. CoCoALib compiled fine (no problems with ambiguity); same also for the tests (which all passed).

It seems that I had forgotten about this task. I will try to finish it now.

As a check I reinserted the explicit keyword and tried to compile: two (minor) problems arose in NumTheory.C where I checked for equality to 0 and to 1 of MachineInt variable -- the code should have been checking a long value which had been extracted from the MachineInt, so technically the mistakes were "slugs" (logically correct, but needelessly inefficient).

I also checked to see which functions in IntOperations.H would benefit from the automatic conversion from a machine integer to a BigInt and there were only a few. Many of the functions were able to be more efficient if one of the args was a machine integer.

Sometimes a return value could be made simpler i.e. remove the explicit call to the BigInt ctor... but perhaps I prefer to see that there is a conversion when creating the return value.

So now I'm not so convinced of the possible benefits of automatic conversion.

There could be some minor benefit to NumTheory.H especially PowerMod which has 8 different signatures to cover all possible combinations, even though I expect that only 2 of them would suffice for almost all uses: "all MachineInt" and "all BigInt".

Similarly gcd and lcm could perhaps be reduced to 2 signatures.

Overall, I now think that the potential benefit would be fairly slight... but Christof did point out that it would make life easier for contributors.

Undecided; it is probably not that important either way.

On several occasions the design of CoCoALib has preferred the path of "ease of use" over that of "absolute speed". Since this issue is really about such a choice, it would make sense to prefer also here "ease of use" over "absolute speed". Indeed if there is some case where a significant speed penalty arises, we can always make a separate function for MachineInt. The only tricky aspect is determining when a "significant speed penalty" occurs -- my guess is that most such cases have already been handled in IntOperations.

This point of view supports removing explicit.

• ILogBase --> need just 1 signature
• mantissa, exponent, NumDigits would also work for machine ints
• RoundDiv --> just 2 signatures
• iroot --> just 1 or 2 signatures
• IsExactIroot --> just 2 signatures
• IsSquare and IsPower --> just 1 signature each

• PowerMod
• lcm --> just two signatures

I have found a catch...
If a and b are variables of type int, and the only signature for lcm expects two BigInt values then lcm(a,b) does not compile!

The problem is that there is no direct "conversion" from int to BigInt; instead, as currently implemented, the int must first be converted to MachineInt and then to BigInt. However C++ allows only a single stage of conversion when doing automatic conversions.

The obvious solution is to define direct conversions (i.e. new ctors) to BigInt from each of the built-in integral types in the same way we have done for the ctors of MachineInt. Tedious!

John Abbott wrote:

However C++ allows only a single stage of conversion when doing automatic conversions.

well, I'm pleased to hear that...

The obvious solution is to define direct conversions (i.e. new ctors) to BigInt from each of the built-in integral types in the same way we have done for the ctors of MachineInt. Tedious!

Tedious, but it makes sense.
One option is to write them and leave them commented out. Meanwhile we try to decide if we really want them or not. Maybe also doing some speed tests.

I have just encountered a bigger problem...
Line 167 of BigInt.C wants to evaluate the expression N > 0 where N is of type BigInt. The compiler complains that this is ambiguous: it matches equally well operator>(BigInt,BigInt) and operator>(BigInt,MachineInt)

• (A) undo: i.e. no implicit coversion from MachineInt to BigInt
• (B) eliminate operator>(BigInt,MachineInt)

Option (A) takes us back to known territory... it's not too bad.
Option (B) means that every comparison between a BigInt and a machine integer will construct a BigInt object... not too tempting :-(

John Abbott wrote:

Right now I do not see any good way out of this:

• (A) undo: i.e. no implicit coversion from MachineInt to BigInt
• (B) eliminate operator>(BigInt,MachineInt)

(A) undo

There is an option (C) but it is not realistic: I could define operator> between BigInt and each of the actual machine integer types. Or I could even define a template function: template <typename T> bool operator>(BigInt,T) but that is pretty ugly, and might well require a lot of code to be put into IntOperations.H

I'll think about it overnight, but suspect that "undo" is the best (=least bad) solution.

So to make sure I got it right. You implemented the constructures BigInt(long) and so on, and now get this ambiguity?
I didn't know you have this MachineInt type. In this case I also see no easy solution.

Maybe you then can add a MachineInt version to some functions. I don't remember where I wanted to have this, maybe multiplying a RingElem with or taking some power, or constructing a RingElem.