lapack: Add Dggbal and its test

[soypat]

Part of #1651

Please take a look.

Dggbal balances a pair of matrices. To do this it has two scale vectors to build the P matrix. I've not been able to port most of Dgebal's tests for use with Dggbal since there are various differences.

The tests do not test if the permutation matrix can be built correctly.

Any tip on how to build P is welcome.

[soypat]

Flaky test?

=== RUN   TestDsaturExact
    coloring_test.go:504: test ran too long for "sudoku problem"
    coloring_test.go:477: we ran out of time by "cs_shc"
    coloring_test.go:477: we ran out of time by "gis_hc"
    coloring_test.go:477: we ran out of time by "gis_shc|rs_shc"
    coloring_test.go:477: we ran out of time by "lf_hc"
    coloring_test.go:477: we ran out of time by "lf_shc"
    coloring_test.go:477: we ran out of time by "lfi_hc"
    coloring_test.go:504: test ran too long for "lfi_hc"
    coloring_test.go:477: we ran out of time by "lfi_shc|slf_shc"
    coloring_test.go:504: test ran too long for "lfi_shc|slf_shc"
    coloring_test.go:477: we ran out of time by "no_solo"
    coloring_test.go:477: we ran out of time by "sl_hc"
    coloring_test.go:504: test ran too long for "sl_hc"
    coloring_test.go:477: we ran out of time by "sl_shc"
    coloring_test.go:477: we ran out of time by "slf_hc"
    coloring_test.go:504: test ran too long for "slf_hc"
    coloring_test.go:477: we ran out of time by "sli_hc"
    coloring_test.go:504: test ran too long for "sli_hc"
    coloring_test.go:477: we ran out of time by "sli_shc"
    coloring_test.go:477: we ran out of time by "rsi_shc"
    coloring_test.go:477: we ran out of time by "V_plus_not_in_A_cal"
    coloring_test.go:477: we ran out of time by "queen5_5"
    coloring_test.go:477: we ran out of time by "queen6_6"
    coloring_test.go:504: test ran too long for "queen6_6"
    coloring_test.go:477: we ran out of time by "queen7_7"
    coloring_test.go:504: test ran too long for "queen7_7"
--- FAIL: TestDsaturExact (589.87s)
=== RUN   TestRandomized
panic: test timed out after 10m0s
running tests:
	TestRandomized (9s)

goroutine 50 [running]:
testing.(*M).startAlarm.func1()
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:2259 +0x3b9
created by time.goFunc
	/opt/hostedtoolcache/go/1.21.0/x64/src/time/sleep.go:176 +0x2d

goroutine 1 [chan receive]:
testing.(*T).Run(0xc0000076c0, {0x564ddc?, 0x4c065c?}, 0x5708d0)
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:1649 +0x3c8
testing.runTests.func1(0x678d60?)
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:2054 +0x3e
testing.tRunner(0xc0000076c0, 0xc00004fc48)
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:1595 +0xff
testing.runTests(0xc0000760a0?, {0x672be0, 0x7, 0x7}, {0x4129bf?, 0xc00004fd08?, 0x678540?})
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:2052 +0x445
testing.(*M).Run(0xc0000760a0)
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:1925 +0x636
main.main()
	_testmain.go:65 +0x19c

goroutine 29 [runnable]:
gonum.org/v1/gonum/graph/coloring.greedyColoringOf({0x59a0b8, 0x66d930}, {0x599b78, 0xc00037dc60}, 0xc00010cce0?)
	/home/runner/work/gonum/gonum/src/gonum.org/v1/gonum/graph/coloring/coloring.go:575 +0x310
gonum.org/v1/gonum/graph/coloring.Randomized({0x59a0b8, 0x66d930}, 0x66d930?, {0x599618, 0xc00035a690})
	/home/runner/work/gonum/gonum/src/gonum.org/v1/gonum/graph/coloring/coloring.go:332 +0xa5
gonum.org/v1/gonum/graph/coloring.TestRandomized(0xc000401520)
	/home/runner/work/gonum/gonum/src/gonum.org/v1/gonum/graph/coloring/coloring_test.go:515 +0x13c
testing.tRunner(0xc000401520, 0x5708d0)
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 1
	/opt/hostedtoolcache/go/1.21.0/x64/src/testing/testing.go:1648 +0x3ad
FAIL	gonum.org/v1/gonum/graph/coloring	600.022s

[kortschak]

Yeah, this shouldn't happen, and I've tried to stop it from causing the test timeout panic (the initial set of failures is the best we can do in the bad case). It is flakey, but the algorithm is randomised and sometimes fails, so there is essentially nothing we can do about it other than not test, which is something I'm not prepared to do.

[codecov-commenter]

Codecov Report

Patch coverage: 88.55% and project coverage change: +0.76% 🎉

Comparison is base (85ca896) 73.26% compared to head (5dcb8ed) 74.02%.
Report is 152 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1890      +/-   ##
==========================================
+ Coverage   73.26%   74.02%   +0.76%     
==========================================
  Files         510      529      +19     
  Lines       60132    63498    +3366     
==========================================
+ Hits        44056    47007    +2951     
- Misses      13584    13912     +328     
- Partials     2492     2579      +87     

Files Changed	Coverage Δ
lapack/gonum/dggbal.go	88.55% <88.55%> (ø)

... and 295 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[soypat]

I've tested permute and scaling with Dggbal's results but the way I'm getting there is ridiculous. I fiddle about with the matrix multiplies until the tests pass, then I understand what the implementation is doing. This is because the reference documentation is lacking on what exactly is being stored in lscale and rscale, and how the permutation and scaling is supposed to be applied. The documentation on rscale even seems to be copy pasted from lscale's documentation and left unchanged.

[vladimir-ch]

I don't know how to approach the review other than merging and then cleaning up later. It's quite a bit of work and it will take time, I'm busy with other tasks.