New package simplicial modules

[kellerlv]

A package for computing simplicial modules and the Dold-Kan correspondence, by Michael DeBellevue and Keller VandeBogert

[d-torrance]

Thanks for the contribution!

Currently, test 5 is failing with the following error:

i13 : 	    assert isSimplicial C2
stdio:15:31:(3): error: no method found for applying isSimplicial to:
     argument   :   1      1      1      1      1 . (of class SimplicialModule)
                   S  <-- S  <-- S  <-- S  <-- S  .
                                                  .
                   0      1      2      3      4  .

[d-torrance]

The tests are failing on one of the builds due to running out of memory:

-- capturing check(47, "SimplicialModules") Insufficient memory for the allocation

Is there any way of making this example smaller? There are a few others that take a while:

-- capturing check(9, "SimplicialModules")   -- 6.0101s elapsed
...
-- capturing check(26, "SimplicialModules")  -- 69.118s elapsed
-- capturing check(27, "SimplicialModules")  -- 22.6293s elapsed

[kellerlv]

The tests are failing on one of the builds due to running out of memory:

-- capturing check(47, "SimplicialModules") Insufficient memory for the allocation

Is there any way of making this example smaller? There are a few others that take a while:

-- capturing check(9, "SimplicialModules")   -- 6.0101s elapsed
...
-- capturing check(26, "SimplicialModules")  -- 69.118s elapsed
-- capturing check(27, "SimplicialModules")  -- 22.6293s elapsed

Yes -- I should have pruned this one down. I had to fix a similar example in the documentation that was causing memory issues so I should have done a similar tweak here.

[d-torrance]

I've added a few additional comments on the code. Also, some of the tests are still pretty lengthy:

 -- capturing check(26, "SimplicialModules") -- 35.9748s elapsed
 -- capturing check(27, "SimplicialModules") -- 18.2174s elapsed
...
-- capturing check(47, "SimplicialModules") -- 7.68881s elapsed
...
 -- capturing check(49, "SimplicialModules") -- 8.55586s elapsed
 -- capturing check(50, "SimplicialModules") -- 20.7422s elapsed

[d-torrance]

Having Complexes in both PackageImports and PackageExports is redundant

[kellerlv]

What's the preferred threshold for test lengths? These tests took about half as long as those times on my computer, but I acknowledge 35 seconds is quite long. One issue with this is that simplicial objects are generally very big and computationally cumbersome, so it's hard to build nontrivial examples that also run quickly. I kind of knew the example sizes would be an issue here but wasn't sure what was considered acceptable.

[mahrud]

What's the main bottleneck? Have you profiled the test?

[kellerlv]

No, I haven't profiled it mostly because I don't know how. For all of the slow tests it generally stems not from this package's constructors themselves, but the general slowness of applying Schur functors/exterior powers to large matrices (which are functions from other packages).

[d-torrance]

These calls to needsPackage are unnecessary since the packages are in PackageExports

[d-torrance]

Using applyValues here would be a bit cleaner here since we wouldn't need to create an intermediate list

[d-torrance]

Comparing to true here is unnecessary since opts.Degeneracy is already a boolean

[mahrud]

(Although since it's an option, === true would make sure it's not null also.

[d-torrance]

Usually error message begin with a lowercase letter

[d-torrance]

You can use =!= here to negate ===