CoCoA » CoCoALib

The problem is that all the member functions accept any integral type, but most should accept only SmallFpImpl::value_t.

The function myReduce is designed to accept any integral type, while the "seemingly identical" function myNormalize expects only a SmallFpImpl::value_t. Of course, my buggy code called the wrong one... and the compiler issued no warning or error.

Ideally the interface to SmallFpImpl should be designed so that type-incorrect code does not compile.

It is not true that approach (1) allows the user to use 0 and 1 as arguments to the memfns. In fact, the only use in CoCoALib was to compute reciprocals; so I have added a myRecip memfn.

At this point I believe that approach (2) is more sensible, clearer and safer.

Why did I interfere with working code? Well, it's not working now; it's not even compiling! :-(

Well, SmallFpImpl compiles OK, but a main user (DUPFp) does not.

One significant problem is that I have frequently made comparisons of the form c = 0 and c = 1 where c is a SmallFpImpl::value. I have also used both 0 and 1 as values to assign to SmallFpImpl::value.

I think this is a good choice: it is exactly what we do for ring, so the code is overall more coherent

I now disagree with my comment number 3. I think that the impl using new types (classes) to represent the values is clearer and safer.

There are two classes: one for reduced values and one for non-reduced values (e.g. for computing inner products more quickly). After an initial period learning the two classes and their meanings, the rest of the code should be easy to understand.

• SmallFpImpl::value is the class for reduced values
• SmallFpImpl::uvalue is the class for non-reduced values.

I am reasonably happy with value, but less convinced about uvalue.

Does anyone have any better suggestions for the names?

I like all types in CoCoALib to be printable; naturally this includes value and uvalue.

SmallFpImpl offers the choice of "export convention" between SymmResidues and NonNegResidues; these are heeded by the mem fn myExport. However, they cannot be heeded by direct printing since the modulus and chosen convention are in the SmallFpImpl object, which is not present in direct printing.

• (A) disallow direct printing; the user must call myExport explicitly?
• (B) allow direct printing, but print in a manner indicating that the value printed is an internal representation?

Currently, a uvalue is printed between exclamation marks, but a value is printed out as a plain integer.

Right now my preference is to allow direct printing as that makes debugging simpler; if it were disallowed then the poor debugger fellow would probably have to look up in the doc why the value cannot be printed directly -- probably not a welcome hindrance when tracking down a bug!

Another, more verbose possibility would be to print value(n) and uvalue(n); perhaps that would be too verbose?

• GlobalSettings::SymmResidues
• GlobalSettings::NonNegResidues

What about removing the GlobalSettings prefix?
Is it desirable? Is it technically feasible? (pros and cons?)

When a SmallFpImpl is printed currently it appears as SmallFpImpl(p) where p is the prime. Should the export convention also appear in the print out?

John Abbott wrote:

There is a question about names:

• SmallFpImpl::value is the class for reduced values
• SmallFpImpl::uvalue is the class for non-reduced values.

I am reasonably happy with value, but less convinced about uvalue.

NonRedValue
CrudeValue
RoughValue
?
u makes me think of unsigned.

I quite like NonRedValue; it is quite clear, and a bit long (to discourage "casual use"). I'll try changing the code to see how I feel about it :-)

I have resolved the mystery of the two identical functions running at different speeds: my test program was giving (very slightly) different inputs... sigh!

In NumTheory.H there is a fn called InvMod which expects two MachineInt; internally it calls the fn InvMod_private that actually does the work (on two unsigned long). The function SmallFpImpl::myRecip needs to call InvMod but I already know that the inputs are good: they are unsigned long and satisfy all the "safety" criteria.

If I call InvMod, the test program takes about 7.1s, but if I call InvMod_private it takes about 6.4s -- approx 10% faster. Anyway, the "correct" implementation should call InvMod_private. But how to do this?

I want InvMod_private to be implemented just once, but also to be available to (at least) 2 different .C files... which implies that it should be declared in some .H file. But I'm not sure how publicly visible InvMod_private should be: it is less safe than most public CoCoALib fns.

Of course, if I find it useful to have access to the "unsafe" function (because it's faster), perhaps some other implementer would also want access...?

So maybe the fn should be public but with a special name?

I am thinking of the name InvModNoCheck; it is pretty clear; it is a bit long, so that ought to discourage "casual users".

What do you think?

John Abbott wrote:

I am thinking of the name InvModNoCheck; it is pretty clear; it is a bit long, so that ought to discourage "casual users".

What do you think?

yes! go for it!
I thought we had used NoCheck somewhere else, but cannot find it. I only found RootBoundNoChecks in REalRoots.cpkg5)