incorrect promotes

[pzinn]

The principle of promote is that promote(R,S) exists if there is a natural map (typically, an inclusion) from R to S. In particular, the graph of promote has to be acyclic -- e.g., if both promote(R,S) and promote(S,R) we're in trouble because what are we supposed to do with r+s with r in R and s in S?
Unfortunately there are several current promotes that fail these basic premises. I intend to fix this in #3903.

There is one particularly problematic case, and since there was a debate on zulip, I want to summarise it here.

Currently promote(RR,QQ) exists. Now obviously there's no natural map from RR to QQ so it shouldn't.

Now the argument is that secretly RR is not really the real numbers but rather ZZ[1/2] and so it sits inside QQ.
First I strongly disagree with this argument, for many reasons:

• The philosophy of Macaulay2 is that objects should be as close to their true mathematical counterparts, irrespective of implementation.
• The argument could be made that RR_* is ZZ[1/2], and similarly for say RR_53, but these are different.
• Even so, this is problematic, because RR_* is supposed to be a field, and ZZ[1/2] isn't.

Anyway, to be the devil's advocate, suppose RR is actually ZZ[1/2]. Then there is no map from QQ to RR, which means we should remove promote(QQ,RR). Is that reasonable? obviously not.

So the only logical conclusion is that one should remove promote(RR,QQ). It can be renamed to something different if people think it's useful.

I've only found one use of promote(RR,QQ), which is in Nauty (well, two, since NautyGraphs is a fork of Nauty -- I'm a little confused why we have two packages, one a fork of the other, in the official version of M2. anyway), where a probability is first promoted to QQ before being rounded -- the former can be removed with no visible effect.