CoCoA » CoCoA-5

One piece of software printed out a message every time a Normaliz function was called: this produced thousands of messages -- too many I think.

Another piece of software printed out a "detailed" message the first time a foreign function was called, but not for any subsequent calls. This does mean that the output of a top-level function call may depend on what functions have been called earlier in the session. Of course, these informative messages are somehow different from the standard output -- the standard output is the same, but there may be some "incidental" output.

Personally I do not much like the idea of printing out "incidental" messages in the middle of a computation.

I propose printing out a message about external libraries at the same time as the banner is printed out -- and the message should be suppressed if the banner is suppressed.

I would like a very short message such as:

CoCoA with external libs: NORMALIZ, FROBBY

Perhaps there could be a second line explaining how to find out more about the external libs. Presumably it can just say to look up the extlib name in the on-line manual.

NOTE should there also be a "credit" for GMP?

We would like authors to cite CoCoA when they use in the their research. Presumably then they should also cite any external libs which were used. But how can they know whether an external lib was used?

One possibility would be to have counters (one for each external lib) which increment every time CoCoALib calls a function from an external lib. Then you can check the counters before your computation, and again afterwards; those counters which changed indicate which external libs were used (and "how much" they were used).

Is it is a sane idea to create such (global) counters? Implementation might be messy (especially in a threadsafe manner).

Anna Maria Bigatti wrote:

Done in init.cpkg5.... but that's not good: it does not see the "--no-preamble" flag :-(
undoing it.

not elegant but done in Banner.C

I spoke to Christof about the idea of recording when ext libs are actually used (e.g. see my suggestion of counters in note 4).

Christof thinks that a boolean for each ext lib is more useful than a counter. The counter would simply count how many calls, and could not easily distinguish between a simple call to set a flag, and a complex call to compute a Hilbert basis...

It would be helpful to have a command for resetting all the flags; so the expected use would be:

• reset all flags;
• perform your computation;
• check the flags to see which ext libs were used.

These flags should exist in CoCoALib too; I suppose a std::map is probably the most appropriate structure.

Now I'm less sure about using a std::map since it might be difficult and/or costly to make it threadsafe.

Probably a global vector<int> is a better solution. I would like that simultaneous setting of several flags in the vector produces the correct output: i.e. at the end all of the flags are set. If an int is write-atomic then this should work out OK. Perhaps vector<double> is safer?

Or maybe separate global flags can be used for each ext lib? But how can this be done in a simple/automatic/scalable/safe manner?

I also want to be able to reset all flags for ext libs (without knowing precisely which ones are actually present).

If we do implement some scheme for recognising use of external libraries, probably we should also do something similar for contributed packages -- that way, those who do contribute to CoCoA could get some recognition. Then if we do it for contributed packages, what about contributed parts of CoCoALib?

Mmm, tricky. :-/

The Normaliz header of the development version that will soon become 3.3.0 now lists the external packages compiled into libnormaliz, at the moment the candidates are CoCoALib and SCIP. See example below. libnormaliz does not know which packages are compiled into it.

\.....|
                    Normaliz 3.3.0                   \....|
                                                      \...|
     (C) The Normaliz Team, University of Osnabrueck   \..|
                    February  2017                      \.|
                                                         \|
------------------------------------------------------------
with paackage(s) CoCoALib