Hi Samuel,

On 2018-04-08, Samuel Lelievre <samuel.lelie...@gmail.com> wrote:
>> 2. The vast majority of my spkg's tests start with calling a function 
>> that is responsible for providing data on a cohomology ring; if the 
>> data is locally available, then it is just loaded; if it isn't, but 
>> internet is available, then the data is downloaded; if it isn't, then 
>> the data is computed from scratch. So, mathematically the functions do 
>> not depend on the data from internet; but they do try to access them 
>> unless local data are available (which in many tests aren't). 
>
> Maybe such a function could take optional arguments such as
>
>     def f(..., get_data_from=None)

I think one should distinguish two issues: Where to get data from? Where
to write data to?

Let me give some background that may explain how I came to the current
design.

Early in the development of the spkg I found that it is unfeasible (in
the big examples that have been part of my project) to keep the whole
structure of all cohomology rings in memory all the time. So, parts of
the structure that are currently not in use are stored on disk. That's
why there has to be a folder assosiacted with a cohomology ring.
To keep things orderly, the folders for each individual ring are all
contained in a single root folder, which is what I refer to by
"location of a database".

Of course, a user's computations must not interfere with other user's
computations. That's why *all* cohomology rings belong to a private
database located somewhere in DOT_SAGE, even if they were loaded from
some public database or from the web.

Usually, computing a cohomology ring involves computing several other
cohomology rings as well: If G is a finite group, p is a prime, and S a
Sylow p-subgroup, then computing H^*(G; GF(p)) with my spkg involves the
cohomology rings of
- The maximal p-elementary abelian subgroup in Z(S)
- All maximal p-elementary abelian subgroups in S
- S
- N_G(Z(S))
- G

For simplicity, I want that all these rings belong to the same private
database, and thus I have a global option defining the location of *the*
private database that is used for all rings.

Similarly I have global options for the location of the current public
database and the current web database.

But your remark made me reconsider: While there is reason to only have a
single private database (to *store* stuff), it should be perfectly fine
to simultaneously have more than one public database and more than one
web database - or *no* public database resp. *no* web database.

So, I would modify your idea as follows:
- I will keep the global option for the location of *the* private
  database.
- I will extend the current global options for the location of public
  and web database: They should become *tuples* of strings, rather than
  single strings. The resources are then tried in order: First all
  private database, then all public databases, then all web databases.
  If that fails, the ring will be computed from scratch.
- There should be an optional argument `public_dbs` and `web_dbs` that
  override the global options for public and web databases.
  Or perhaps the wording `local_dbs` instead of `public_dbs` would be
  clearer.
 
And since internet during tests during installation is a problem, I'd
set web_dbs=() globally at the beginning of each doctest.

> Then the doctests could be split into some that require internet
> (which would be tagged # optional -- internet), and some that don't.

Again: The tests will almost always be executed during installation, and
thus there definitively is no internet. So, "# optional -- internet"
cannot be a solution.

Instead, I will ban internet access in all tests by setting the global
web_dbs appropriately, except in the tests of the functions that get
data from web databases. These tests don't need to change, as I am using
a *local* toy database in the format that's used by an actual web database.

Thank you for your feedback and suggestions!

Best regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to