Re: Some remarks on modulo.cpp

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-06-12 17:24:56

Paris (U.E.), le 12/06/2001

        Hi!

--- In boost_at_y..., Christoph Koegl <yahoo_at_f...> wrote:
> Hi (especially to Daryle).

[SNIP]

                The file you are refering to come from an E-mail exchange 
between Daryle and me. It is perhaps prematurate that they appear in 
the vault.

                In particular, for what I had in mind (more about that 
later), I believe a better functionality would come from the use of two 
template parameters, as in "template <typename T, T endpoint> class 
congruency {...}".

> Anyway, here are some remarks on modulo.cpp from the files section.
> 
> 1.
> The choice of "Ring" as the main template parameter name is somewhat misleading IMO.
> "Modulus" would be more on target and more in accordance with common mathematical
> vocabulary. The class template implements some aspects of the rings Z/(n) (or Z/n
> for brevity), and most literature refers to n as the modulus.
> 
> 2.
> Let me evilly question the need for such a library. There are proven, efficient lib-
> raries out there for the task at hand (GMP, NTL, CLN, libI, Piologie, Pari-GP), and
> these were optimized over many years. Why reeinvent some part of these?

                The class you saw came from the fact that I submited classes 
for quaternions and octonions which were meant to behave like their R, 
C, H, O counterparts, but which were partly meaningless when 
instanciated on integers. There is in fact one problem domain where 
such "quaternions" instanciated on integers could be (research pending 
:-)  ) meaningfull: cryptography, error-correcting codes and the like. 
In that context, a good congruency functionnality is necessary. So I 
suggested Daryl write that part, since he had  contributed a  CRC 
library. That way we could have a full package to propose, and not have 
rely on non-boost and non-std libraries. We would also need a "huge" or  
illimited-precision integer class upon which to instanciate (maybe 
"rational" fits the bill for that one, I did not have the time yet to 
study the code, unfortunately).

> As for the many-valued logic functionality: There are many multi-valued logics out
> there. What applications are you alluding to in the rationale specifically? You
> seem to implement something like Lukasiewicz's many-valued logics. But there are many
> more many-valued logics that "behave" differently (i.e. the computation of their
> truth values is different). I think the "lumping-together" of concerns (as opposed
> to the worthy goal of separation of concerns) needs more justification. Is it just
> for "sharing of implementation" purposes as you seem to suggest (you talk about
> "[using] similar implementations, [...] so they have been merged to save space").
> Perhaps we should have separate classes for modular arithmetic (together with
> some ordering functionality, which is only there for being able to store modulo's in
> associative containers, right?) and for many-valued logic operations. The m.-v. logic
> class then uses the modulo class in its implementation.

[SNIP]

                I guess (that was my first thought) N-ary logic should indeed 
be in a separate class. But maybe Daryl has some knowledge of uses 
which could benefit from having simultaneously both types of 
functionality.

                As I said, this is a very preliminary version. Comments most 
welcome!

                        Hubert Holin
                        Hubert.Holin_at_[hidden]