coldfix / citip Goto Github PK

I just noticed, the out-of-source cmake build errors if the build in the source directory is not cleaned up.

@r734: do you have any experience with this sort of problem by any chance?

Steps to reproduce

make
mkdir build
cd build
cmake ..
make

Error Message

[ 71%] Building CXX object CMakeFiles/Citip.dir/parser.cxx.o
In file included from /home/thomas/dev/project/Citip/location.hh:41:0,
                 from parser.y:60,
                 from /home/thomas/dev/project/Citip/scanner.hpp:6,
                 from parser.y:80:
position.hh:57:9: error: redefinition of ‘class yy::position’
   class position
         ^~~~~~~~
In file included from /home/thomas/dev/project/Citip/build/location.hh:41:0,
                 from parser.y:60,
                 from /home/thomas/dev/project/Citip/build/parser.cxx:46:
/home/thomas/dev/project/Citip/build/position.hh:57:9: note: previous definition of ‘class yy::position’
   class position
         ^~~~~~~~
In file included from /home/thomas/dev/project/Citip/location.hh:41:0,
                 from parser.y:60,
                 from /home/thomas/dev/project/Citip/scanner.hpp:6,
                 from parser.y:80:
...

Explanation:

This happens because cmake generates different directory-dependend include guards for the generated header files, e.g. build/parser.hxx checks YY_YY_HOME_THOMAS_DEV_PROJECT_CITIP_BUILD_PARSER_HXX_INCLUDED while parser.hxx checks YY_YY_PARSER_HXX_INCLUDED. Now, this becomes a problem because either file (build/parser.hxx or parser.hxx) may be included, depending on who includes them:

First, build/parser.cxx includes directly parser.hxx, so this is resolved into the build directory:

build/parser.cxx:46
 -> build/parser.hxx:49 (parser.y:60)
 -> build/location.hh:41
 -> build/position.hh:57

Next, parser.cxx includes scanner.hpp which exists only in the source directory. source/scanner.hpp now includes parser.hxx, so this is resolved in to the source directory:

build/parser.cxx:58 (parser.y:80)
 -> source/scanner.hpp:6
 -> source/parser.hxx:49 (parser.y:60)
 -> source/location.hh:41
 -> source/position.hh:57

I want to proof a inequality. However, I have many constraints, say 20 and 12 variables. Is there any easy way to run? Thank you.

For any expression EXPR that can be proven to be TRUE, it would be really nice to be able to obtain the proof for it, if interested. E.g. if an expression can be written as (or underestimated by) a linear combination of basic Shannon measures, print that linear combination.

This should be easy to accomplish by just printing the solution to the dual problem.

In the light of #4, I'd suggest something like dual I(X:Y) >= 0.

Might be nice in certain situations. Though, this requires a minor language redesign: inquiries can only be posted after the constraints are added, and there should be special syntax to distinguish them. I'm thinking of something like:

./Citip
> X/Y/Z
> check I(X:Y:Z) <= 0
...

On the command line use something like --inquire or --check (+short form). I don't think constraints should be required to be marked as such, but for explicity, one could add for example a --constraint option (although the short option is in conflict with the one of --check).

At least support --help and --version and don't just go into input mode when nothing is specified (that is, until REPL mode is there).

If the information expression consists of a basic Shannon information measure, the program will just tell you that. It is weird for a program to answer a trivial question with something equivalent to "This is trivial, go figure it out yourself" - and it successfully defies automation.

Instead, I'd like to handle the case "basic Shannon measures" exactly as other expressions, i.e.:

• Citip 'H(X)>=0' should exit with 0.
• Citip 'H(X)<=0' should exit with 1.

I didn't have a look at the itip1 and/or ITIP implementations in the source tree so far (just noting things to change for now), but I dearly hope this will be an easy thing to change.

The Xitip website claims that there will soon be a version available based on the Gnu LP Kit instead of QSopt. I think that's a great idea, but I take it the Xitip website is abandoned - as is probably the project with it. Anyway, if I can get into contact with the Xitip authors, they might already have some code which could be used as a starting point.