API design: fused function for `solve_for_update` and `update`

[matbesancon]

It seems that in solve_for_update, getsol = true is always necessary to obtain the pivot value to pass to the update call.

In that case, are there scenarios where getsol = true happens? It could be good to have a top-level updating function that takes the index and column to replace. The fact that solve_for_update takes either in separate methods is confusing

[amontoison]

@lschork2 What do you think of #22 and #23?

[matbesancon]

It's also not super Julia-idiomatic to use the same method for two different operations that have to be performed one after the other.

col = sparsevec([1], [1.0], m) # vector to be inserted into B
lhs = basiclu.solve_for_update(obj, col, getsol=true)
vmax, j = findmax(abs.(lhs))
piv = lhs[j]
basiclu.solve_for_update(obj, j)

There should be a function update_factor(obj, newcol, j) returning the pivot error directly?

[matbesancon]

and minimally change the name of one of the two solve_for_update methods

[lschork2]

There are two scenarios how basiclu is commonly used:

Scenario 1 (as in primal simplex):

col = sparsevec([1], [1.0], m) # vector to be inserted into B
ftran = basiclu.solve_for_update(obj, col, getsol=true)
j = choose_leaving(ftran) # any rule to decide which position in the basis to replace
piv = ftran[j]
basiclu.solve_for_update(obj, j)
piverr = basiclu.update(obj, piv)

Scenario 2 (as in dual simplex):

j = 1 # position in basis to be replaced
btran = basiclu.solve_for_update(obj, j, getsol=true)
col = generate_entering(btran) # any rule to get the entering column
piv = dot(btran, col)
basiclu.solve_for_update(obj, col)
piverr = basiclu.update(obj, piv)

In each scenario there is one call to solve_for_update with getsol=true and one call with getsol=false. The latter are significantly faster because they perform only a partial forward or backward solve.

Note also that a basiclu.solve_for_update(obj, ..., getsol=true) call is necessary in each scenario to choose the leaving position or the entering column, respectively. Therefore this call would also be needed before using the suggested update_factor(obj, newcol, j) (in any scenario that I am aware of). Hence by using update_factor(obj, newcol, j) the user would do one additional solve.

I had designed to basiclu functions to do as little work as possible in any of the two scenarios. But I understand that this might not be user friendly.

[matbesancon]

thanks for the clarification. I understand the need for the multi-step function better.

The main point would be to have different function names for the solve_for_update(obj, j) and solve_for_update(obj, col) but not sure what they could be.

[lschork2]

I agree to naming them differently.

A simplex developer would probably call them prepare_update_ftran(obj, col, getsol) and prepare_update_btran(obj, pos, gesol). But I am not sure whether "ftran" and "btran" are meaningful to other users. Maybe prepare_update_entering/prepare_update_leaving is better? When you have something more Julia-idiomatic in mind, this is also fine with me. I don't plan to change the C code.

[matbesancon]

Maybe prepare_update_entering/prepare_update_leaving is better? When you have something more Julia-idiomatic in mind, this is also fine with me

These sound nice and explanatory yes.