[FlopCpp] Question on indexing constraints

[Michal Kaut]

[Looks like I had sent it to a wrong email, so here it goes again...]

Dear Tim,

thanks a lot for the explanation. Finally, I have a feeling I almost
understand it, except one thing:
Why does not "sum(AB(ab), dAB(ab) * xAB(ab))" in getIndx2 work, while
"sum(AB, dAB(AB) * xAB(AB))" works?
Recall that
: MP_subset<2> AB(A,B);
: MP_data dAB(AB);
: MP_variable xAB(AB);
: MP_index ab;

Otherwise, the fact that a subset of two-dimensional set uses only
single index creates one more problem, which I still have not managed to
solve: how do I get access to the members AB?
By a trial-and-error method I found that for given (i,j) from A*B, I can 
test if (i,j) is a member of AB: since AB(i,j) returns the index of 
(i,j) in AB and -2 otherwise, one can check "if (AB(i,j) >= 0)"...

This, however, can be a waste of time if AB is a sparse subset of A*B. 
Hence, I would like to ask whether there is a direct way of getting the 
two components (i,j) of the k-th element of set AB?
[Note that this question has just been asked by Berit Løfstedt.]


In addition to the indices, I have noticed there are also MP_domain and
related objects. The documentation says that they are "one of the main
public interface classes", but none of the examples use them. So I just
wanted to ask whether/wow they can be useful for modelling?

> "eval subsetref"; oops. some debug stuff committed by mistake, removed
> in stable now
Thanks for that. However, I should have mentioned that each "eval
subsetref" line was followed by two numbers (each on a separate line).
You removed the "eval subsetref", but the numbers remained...
BTW: Should I be using stable, or some other branch?


Once more, thanks a lot for the help.


Regards,
Michal Kaut


Tim Hultberg wrote:
> Hi Michal,
>    flopc++ is "GAMS-influenced" in the sense that sets can act as
> indices, but "AMPL-influenced" in the sense that you dont have to use
> sets as indices. [ sum(S, ...) is just a shorthand notation for
> sum(S(S),...) where the first S acts as a set and the second S acts as
> an index]
> 
> Looking at your example, I see that the real problem is NOT the use of
> sets or indices, but rather that you are using the wrong number of
> indices (no matter whether declared as MP_index or MP_set).
> 
> For example, after declaring MP_data dAB3(AB) you shouldnt reference it
> with two indices as in dAB3(A,B) [so why doesnt flopc++ complain nor at
> compilation time nor at runtime? Thats a long story, if I get time I'll
> add more about this at the end of the mail*]
> 
> This (using the wrong number of indices) explains most of your "not
> working" cases. Except:
> 
> a)The second group (with forall) where in fact all 3 examples "works",
> you just forgot to use dBC2 and dBC3 in the last two examples.
> 
> b)		cABC1(AB,C)  =  xAC(A,C) + xABC(AB,C) == dBC(B,C);
> here the number of the indices are ok, but A and B are not bound. There
> is absolutely no static association of indices to sets in flopc++
> (allthough the shorthand notation mentioned before might give you that
> impression) so you need to tell what indices to are bound to the subsets
> of AB as you do correctly one line above.
> 
> c)    cAs2(As)  =  xA(As) <= dA(As);
> here As is bound but indexing is based on subset indices not the
> corresponding superset indices (i.e if  As={5,9} As will be bound to 0
> and 1, not to 5 and 9. If both is needed, use cAs2(As(A))).
> [If xA and dA are not used anywhere else you could of course also
> declare them over the subset, then this would be ok]
> 
> Summing up: this could (should) be documented if I'll get ever get some
> time for making better doc. flopc++ error handling (when for example
> using wrong number of indices) could be improved [but there are some
> tricky issues here]. 
> 
> Anyway I hope this helps you understand whats going on.
> 
> Slow compilation: a lot of code is the hpp files which could be moved
> to cpp to spped up compilation.
> 
> "eval subsetref"; oops. some debug stuff committed by mistake, removed
> in stable now
> 
> Cheers, Tim
> 
> 
> 
> 
> 
> 
>>>> Michal Kaut <mail at michalkaut.net> 11/06/2007 10:14 >>>
> Hello,
> 
> I forgot to attach the example file to my previous email, so I am 
> sending it again - so please ignore the previous one. I apologize for 
> any inconvenience...
> 
> 
> I have been struggling to understand the indexing of FlopC++
> constraints
> and must admit I still do not understand it properly. What confuses me
> most is that for each type of constraints I wanted to test, I was able
> to find several "seemingly equivalent" formulations, all of which
> compile, but only one of which gives the expected results.
> 
> I have tried to demonstrate it on the attached example, where the
> constraints with a name differing only in number are supposed to do
> the
> same thing, but only those that have "WORKS" in the comment actually
> generate the expected result. (I should probably confess that I am an
> AMPL user, so I have probably different understanding what an "index"
> means, compared to the GAMS-influenced designers of FlopC++.)
> - Could someone try to explain to me why the bad formulations do not
> work, i.e. what they actually do? (They do something, as they
> compile.)
> - Note that the example is only to illustrate indexing, the resulting
> model is not supposed to make any sense.
> 
> 
> In addition, I was rather disappointed by the compilation speed (i.e.
> the lack of it): this very small example takes over a minute to
> compile
> on mu 3GHz Pentium 4 machine with gcc 3.4.5 (mingw on WinXP).
> Of this time, 39 seconds are spend on the last three sets of
> constraints
> (getIndx1-3), i.e. the compile+link time is 26 seconds without those
> constraints. Is this normal/expected behaviour?
> (Another interesting thing is that adding each of the three sets of
> constraints individually adds 5s, 10s and 10s respectively, i.e. 25
> seconds in total, while adding all three adds 39 seconds to the
> compilation time...)
> 
> 
> And one more question: is it possible to get rid of the "eval
> subsetref"
> messages? Even with this small example, I get hundreds of them and
> setting model.silent() does not switch them off...
> 
> 
> Thanks a lot in advance.
> 
> Regards,
> Michal Kaut
>