On Wednesday, November 17, 2021 at 11:48:04 PM UTC-8 Kwankyu Lee wrote:
> For example, if there would be a distribution sagemath-coding that
>> contains sage/coding, then would we have this hierarchy
>>
>
> sagemath-objects < sagemath-categories < sagemath-standard-no-symbolics <
> ... < sagemath-coding
>
> where ... might be filled with other intermediate distributions like, I
> imagine, sagemath-rings, sagemath-schemes?
>
OK, let's take a look at sage.coding.
First, let's see if it uses symbolics.
(9.5.beta6) $ git grep -E 'sage[.](symbolic|functions|calculus)'
src/sage/coding
src/sage/coding/code_bounds.py: from sage.functions.other import ceil
src/sage/coding/code_bounds.py: sage:
codes.bounds.entropy(1/5,4).factor() # optional - sage.symbolic
src/sage/coding/code_bounds.py: sage: codes.bounds.entropy(1, 3)
# optional - sage.symbolic
src/sage/coding/grs_code.py:from sage.functions.other import binomial
src/sage/coding/grs_code.py:from sage.symbolic.ring import SR
src/sage/coding/guruswami_sudan/gs_decoder.py:from sage.functions.other
import floor
src/sage/coding/guruswami_sudan/utils.py:from sage.functions.other import
floor
Apparently it does not in a very substantial way
- The imports of ceil and floor can likely be replaced by integer_floor,
integer_ceil from sage.arith.misc.
- Looking at the import of SR by src/sage/coding/grs_code.py, it seems that
SR is used for running some symbolic sum, but the doctests do not show
symbolic results, so it is likely that this can be replaced.
- Note though that the above textual search for the module names is merely
a heuristic. Looking at the source of "entropy", through "log" from
sage.misc.functional, a runtime dependency on symbolics comes in. (I have
already marked 2 doctests there as # optional - sage.symbolic.)
So if packaged as *sagemath-coding, *now a domain expert would have to
decide whether these dependencies on symbolics are strong enough to declare
a runtime dependency ("install_requires") on *sagemath-symbolics. *This
declaration would mean that anyone who installs *sagemath-coding* ("pip
install sagemath-coding") would pull in *sagemath-symbolics* ... which, at
least currently, has heavy compile-time dependencies
(ECL/Maxima/FLINT/Singular...).
The alternative is to consider the use of symbolics by *sagemath-coding*
merely as something that provides some extra features ... which will only
be working if the user also has installed *sagemath-symbolics. (*It is
possible to declare this as an "extras_require" so that users could go "pip
install sagemath-coding[symbolics]".)
Let's say that we go with the second alternative. Then *sagemath-coding* would
be a dependency of *sagemath-standard-no-symbolics*.
So it would look like this:
*sagemath-objects* < *sagemath-categories* < *sagemath-coding* <
*sagemath-standard-no-symbolics* < *sagemath-standard*
In general, would this hierarchy have a tree structure?
>
No, only directed acyclic. For example, another chain is
*sagemath-objects* < *sagemath-categories* < *sagemath-symbolics* <
*sagemath-standard*
As to other distributions that you asked about, yes, *sagemath-schemes*
could be a good distribution, but I am not sure where it would go in this
picture because sage.schemes is not homogeneous in terms of its
dependencies. For example, sage.schemes.[hyper]elliptic_curves seems to
make heavy use of symbolics, whereas sage.schemes.toric is closely
connected to sage.geometry. So smaller distributions along the lines of
dependencies could make sense as well.
We will most likely not have a distribution *sagemath-rings. *The reason is
that the various ring element implementations pull in a wide spectrum of
compiled libraries, so *sagemath-rings *would be nearly as monolithic as
all of Sage. More useful could be smaller distributions, again informed by
dependencies, such as *sagemath-padics*, for example: Most current uses of
the NTL library in Sage seem to be for sage.rings.padics.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/def60633-ed17-4426-9492-b9638c0c0048n%40googlegroups.com.
