errors for nonlinear fit

@Thomas Dean Here's my interpretation. The wikipedia page you cited makes clear  is the notation for a ring, modulo n. So for the additive group modulo n, the order is n, but for the multiplicative group, 0 is excluded and the order is n-1. So your ord=12, mod 13, is Z/13Z.

This is how you used it in your original post.

@Thomas Dean Your original table didn't have 0 in the multiplicative case, so I emulated that without thinking too much about it. The Wikipedia page talks about integers 0..n-1 mod n. So that may be part of it. But notice that you are doing ord=12, which is mod 13, which is prime. If you change ord to 11, so mod 12, you get an error message, since the default is to check that it is a group. Try other values, some work and some don't.

@Thomas Dean 

Download Group.mw

I tried to find this out a while ago, but concluded it wasn't possible. You can use FileTools:-ListDirectory to find a list of all *.mw files in the interface(worksheetdir) directory, but there seems not to be a simple way to find which one is running. I suppose there must be some system-dependent system calls to figure out which programs are running.

@mmcdara Much, much simpler than mine!

@gharouce So, to be clear, you never want the actual numbers out, but just to evaluate some special algebra in which e^2=1, e^3=e etc for one specific variable e in an expression? That is easy to do if your expression is a polynomial in e, but requires more work if you want it to work for, say, e/sin(e^2). Here's the polynomial case:

Download Xn.mw

For the more general case

evalpm:=proc(expr,var)
        local p,pwr;
        p:=collect(expr,var);
        evalindets(p,`^`,
            proc(pwr) local res; 
              if op(1,pwr)=var then
                if op(2,pwr)::even then
                    res:=1
                elif op(2,pwr)::odd then
                    res:=var
                else
                    res:=pwr
                end if
              else
                res:=pwr;
              end if;
               res;
             end proc
        );
   end proc:

@gharouce You can only set X to one value at a time. But you can do something like this:

s:=X^3*Y + X^2*Z + X;
eval(s,X=1);
eval(s,X=-1);

or you can do something like this:

solve({s=X^3*Y + X^2*Z + X,X^2=1},{s,X});

which gives the two possibilities

@Ronan I originally had ModuleUnload remove the types, thinking that when I did unwith() the module would unload and the types would be removed. But the types still existed - unwith only gets rid of the global names (exports) the package created. The ModuleUnload procedure "is called when the module is destroyed. A module is destroyed either when it is no longer accessible and is garbage collected, or when Maple exits".

So my conclusion is that it isn't really useful.

@Ronan Here's a working example:

Download MyThings.mw

Download test.mw

Deciding whether or not a given cut is minimal (breaks the graph only into two components) is the slow part for the above algorithm; the test uses ConnectedComponents that needs to perform an algorithm that searches through the graph. In the description of the above algorithm two cases were mentioned where this hard test could be avoided. One was that the fundamental cuts were minimal by construction. The second was for ring sums between two fundamental cuts: if the ring sum was between two edge sets with no common edges, it was not minimal and the hard test was not required.

I speculated that this might be possible to simplify for ringsums of more than two cuts. The following algorithm accumulates the ringsums incrementally, and at each stage tests for lack of common edges.

We need to test all 2^r subsets of the set of r fundamental cuts (except the empty set). Let's code the subsets by a list of integers that index the fundamental sets. For example the index [1,2,4,5] will mean evaluating the ring sum of the first, second, fourth and fifth subsets. The subsets iterator in the combinat package can iterate through all subsets of integers in the list [1,2,3,...,r], thereby successively finding all subsets. More importantly, it does it in an order that means we can use previously evaluated ringsums to find new ones. The order is all subsets with zero elements, then one element, then two elements, etc., and in numerical order within those cases, e.g., for r=3 this is [], [1], [2], [3], [1,2], [1,3], [2,3], [1,2,3]. So as an example (for r>4), when we come to evaluate the ringsum of subsets [1,2,3,7,9] we find the ringsum of subsets [1,2,3,7] has already been done, and so we can evaluate the ringsum between the [1,2,3,7] result and fundamental cut [9], and store the result in cutsets[1,2,3,7,9] for later use. If the [1,2,3,7] and [9] edge sets have no common edges, this will not be minimal and we can avoid the hard test in this case.

This was implemented using a Maple table cutsets that was indexed with the lists of integers. All 2^r cutsets need to be stored, so there is a larger memory requirement. Profiling the algorithm on @Icz's graph with 20 vertices  and 72 edges and 314415 minimal cuts showed that the time saved by incrementally doing the ringsums was approximately offset by the extra complexity of the algorithm. For this graph at least, although many more hard tests were avoided, this was still a small fraction of the total.

                       Old         New
fundamental             19          19
easy (no common edges) 104       25063
hard tests          524164      499205
total = 2^19-1      524287      524287

The total times were appromimately the same. 342 out of the 370 seconds (92%) was spent on hard tests, so those are still limiting here. The number of hard tests was reduced by only 5%.

Edit: This analysis suggests that testing all pairs out of 2^r may be the way to go, or perhaps avoid a brute-force method using the much more complicated algorithm of @Icz's ref [1].

Update: testing all pairs is much, much slower, so the mixed strategy here or above seems to be optimum for a brute force method. 

Download MinEdgeCutsNewIterProfile.mw

@lcz The new method discussed here is about 35% faster for your graph.

@lcz I'm not sure how to interpret the claims in Ref [1]. It doesn't have many citations, and a quick look at those suggests they are not about improved algorithms, so perhaps it is not a significant paper (or perhaps it is just unnoticed).

I improved the efficiency slightly in a new version. There are 2^(n-1) partitions to test for minimality, and IsConnected() does a breadth-first search, so will depend on size also. 

I am looking at doing this through combining fundamental cutsets. There is an algorithm to find these from a spanning tree, and combine them to make all (not just minimal) 2^(n-1) cutsets. Then there will be the same number of minimality tests, but it might be possible to easily do some, or the test may be more efficient.

@lcz The cutset problem between two vertices seems more common, since it has applications in fault theory in networks, which made it hard to find references for the above problem.

@dharr The Print routine for Iterator:-Combination incorrectly shows zero-relative ranks, which led to a duplcate partition in my original code. (SCR submitted.)

Download IteratorRank.mw