CoCoA » CoCoALib

• and which is equivalent to "minimum"
• or which is equivalent to "maximum"

where true3 > uncertain3 > false3 (for instance they could have the values 1, 0.5 and 0).

I suggest names and3 and or3.

I note that BOOST does offer such functions for its tribool class, but they have chosen to use the usual C++ syntax (namely && and ||).

JAA prefers not to use the C++ syntax, as it could mislead someone reading the code into thinking that the args are true booleans.

Part of the motivation comes from Anna's rectification of code for ideal arithmetic (see issue #870).

For example when computing the sum of two ideals, the member flag IhaveMonomialGens can be updated using and3 of the two arguments' corresponding fields.

BOOST also offers a "not" operation. It would be trivial to implement not3 (giving value 1 - arg).

If we do offer and3 and or3 then a user would probably also expect not3.

I am much less convinced about other possible operations such as xor3.

I'm against this idea. Indeed it might be handy, but dangerous as well: while working on fixing a bug on the bool3 flag IhaveMonomialGens3Value I first wished to have the operations, but at the end I was convinced that the expected answer of these operations depends on the context/meaning.
As soon as I can think of an example I'll post it here (now I need to go to my lecture!).

I expect in some cases we want
uncertain3 and false3 = false3 (sum of ideals has monomial generators)
and other times
uncertain3 and false3 = uncertain3 (sum of ideals is monomial ideal)
Having an automatism might induce to use it (...and get the wrong answer)

The "monomial generators" case is easy.
The "is a monomial ideal" is hard in any case: even if both ideals are not monomial, their sum could be (e.g. ideal(x-y)+ideal(x+y) assuming 2 is invertible). I see this as a complication in the notion of "is monomial", which is anyway a costly characteristic to determine.

I could argue that having and3 is safer than not. Currently you must write 3-4 lines of code to calculate the result of and3, and a careless programmer might think that the same applies to "is monomial ideal" and consequently copy those lines. A later reader would then see some (not too) complicated code, and presume that the author had actually thought about it (rather than simply copying it from somewhere else). In any case, someone reading that code would take a few seconds (at least) to understand that it was just and3, and not the correct "complicated code".

Well, that was rather waffly.

I think that the definition of and3 is reasonably intuitive (also for or3 and not3). While I can see the temptation to use and3 also for the "monomialness" of a sum of ideals, I also think the algorithmic bug would be more evident if there was an explicit line

IamMonomial = and3(I1.IamMonomial, I2.IamMonomial);

(Maybe this is what you had in mind from the beginning)
I think the only safe definition for and3 is the and between true3/false3, and uncertain3 whenever one argument is uncertain3.

I would like that the definitions of and3 and or3 behave just like the built-in logical operators operator&& and operator|| if the arguments do not involve uncertain3.

This make matters slightly tricky because the built-in operators have the special property of evaluating the second arg only if necessary. This means that and3 and or3 cannot be implemented as normal functions (since by definition all args are evaluated before the function is called).

So the way to achieve this, that I can see, is to implement via preprocessor macros: not pleasant :-(

I think the following is a correct (but rather contorted) implementation:

#define and3(arg1, arg2) \
   (IsFalse3(arg1) : false3 : (IsTrue3(arg1) : arg2 : (IsFalse3(arg2) : false3 : uncertain3)))

The corresponding (contorted) implementation for or3 is the following:

#define or3(arg1, arg2) \
   (IsTrue3(arg1) : true3 : (IsFalse(arg1) : arg2 : (IsTrue(arg2) : true3 : uncertain3)))

Yuk!

On the other hand, if we choose not to be "clever" then we can use normal (inline?) functions which always evaluate all their args.

This is the same impl as in the previous comment (but I find this much more readable)

inline bool3 and3(bool3 arg1, bool3 arg2)
{
  if (IsFalse3(arg1)) return false3;
  if (IsTrue3(arg1)) return arg2;
  if (IsFalse3(arg2)) return false3;
  return uncertain3;
}

A possibly "neater" solution would be something like this:

inline bool3 and3(bool3 arg1, bool3 arg2)
{
  return static_cast<Bool3TruthValueSet>(min(arg1, arg2));
}