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]