There are two factors that forms a distribution package: (a) mathematical
contents of the code and (b) dependencies (external software packages) that
supports the code.
Some distribution packages are named after mathematical contents and others
are named after the main dependency.
Distribution
So, it turns out that
> * a core distribution with absolutely minimal dependencies and only
dependencies which have proved stable on all supported platforms
>
> This is exactly sagemath-categories. It has absolutely minimal
dependencies
is not what I tried to say. What I tried to say is that
On Sunday, September 29, 2024 at 1:30:38 AM UTC-7 axio...@yahoo.de wrote:
I think that `sagemath--minimal-dependencies` would be clear, wouldn't it?
Again fails the "minimal for what" test; and fails to distinguish
*sagemath-categories* from *sagemath-objects* (which has the same
dependencies
On Sunday, September 29, 2024 at 12:15:04 AM UTC-7 Dima Pasechnik wrote:
On 29 September 2024 01:50:39 BST, Matthias Koeppe
wrote:
>On Saturday, September 28, 2024 at 5:21:56 PM UTC-7 oscar.j@gmail.com
>wrote:
>
>On Sun, 29 Sept 2024 at 00:22, Matthias Koeppe
>wrote:
>> On Saturday, S
On 1 October 2024 17:04:49 BST, Georgi Guninski wrote:
>On Tue, Oct 1, 2024 at 5:59 PM Dima Pasechnik wrote:
>>
>> This is a usual discrepancy between the univariate and multi-variable
>> case: the backends are different, and probably the functionality
>> is not implemented in the univariate b
sage: Kx.=QQ[]
sage: l=[x,x^2]
sage: ge=Sequence(l).algebraic_dependence().gens();ge
[-T1 + T0^2]
sage: Kx.=QQ[]
sage: l=[x,x^2]
sage: ge=Sequence(l).algebraic_dependence().gens();ge
AttributeError: 'Sequence_generic' object has no attribute
--
You received this message because you are subscribe
On Tue, Oct 1, 2024 at 5:59 PM Dima Pasechnik wrote:
>
> This is a usual discrepancy between the univariate and multi-variable
> case: the backends are different, and probably the functionality
> is not implemented in the univariate backend (Flint?).
> I gather it can be implemented using a result
Thanks Dima. I will play around with your suggestion and will cc you
in the issues/PR on github.
Vincent
On Tue, 1 Oct 2024 at 11:06, Dima Pasechnik wrote:
>
> Hi Vincent,
> That's a bug, indeed.
>
> These `--with-libgmp=` are parameters of ./configure scripts of cocoalib
> and polylib. We do h
On Tue, Oct 1, 2024 at 12:22 PM Dima Pasechnik wrote:
>
> On Tue, Oct 1, 2024 at 11:46 AM Dima Pasechnik wrote:
> >
> > This is a usual discrepancy between the univariate and multi-variable
> > case: the backends are different, and probably the functionality
> > is not implemented in the univaria
On Tue, Oct 1, 2024 at 11:46 AM Dima Pasechnik wrote:
>
> This is a usual discrepancy between the univariate and multi-variable
> case: the backends are different, and probably the functionality
> is not implemented in the univariate backend (Flint?).
> I gather it can be implemented using a resul
This is a usual discrepancy between the univariate and multi-variable
case: the backends are different, and probably the functionality
is not implemented in the univariate backend (Flint?).
I gather it can be implemented using a resultant computation.
Dima
On Tue, Oct 1, 2024 at 9:30 AM Georgi G
Hi Vincent,
That's a bug, indeed.
These `--with-libgmp=` are parameters of ./configure scripts of cocoalib
and polylib. We do have SAGE_GMP_PREFIX which is set to an empty string
on systems where GMP comes from the system.
So probably on such systems these --with-libgmp= are not even needed,
and
Dear all,
This is a configure script question related to sage environment.In
many situations, system libraries are used for GMP. However, both
cocoalib and polylib spkg-install.in files use hardcoded path to
libgmp
cocoalib/spkg-install.in:
--with-libgmp="${SAGE_LOCAL}/lib/libgmp.a"
13 matches
Mail list logo
