SOURCE
http://doc.sagemath.org/html/en/constructions/linear_algebra.html
sage: var('a,b,c')(a, b, c)sage: eqn = [a+b*c==1, b-a*c==0, a+b==5]sage: s =
solve(eqn, a,b,c); s[[a == (25*I*sqrt(79) + 25)/(6*I*sqrt(79) - 34), b ==
(5*I*sqrt(79) + 5)/(I*sqrt(79) + 11), c == 1/10*I*sqrt(79) + 1/10]
On 2016-04-21 03:08, William Stein wrote:
Hi,
How much disk space is it supposed to take to download and build Sage
from source these days...?
It happens that I just did a make distclean; make
My whole $SAGE_ROOT is 7.3GB but that includes the git repo (258MB) and
the upstream files (903MB)
Hello,
I was not able to use gcc with sage-7.1 installed from the ppa. I
constantly got
$ sage -sh
(sage-sh) $ gcc
gcc: error: /usr/lib/sagemath//local/lib/gcc/: Is a directory
error: command 'gcc' failed with exit status 1
In particular, it makes unusable the usage of Cython.
Best,
Vinc
Apologies for cross-posting, and for posting twice for technical reasons:
Many of you are aware of the MathBook XML "Write Once, Read Anywhere"
project, bringing free text authoring to the masses with HTML, print, pdf,
epub, Jupyter, SMC, and other outputs. I'm excited to announce that the
upc
Apologies for cross-posting:
Many of you are aware of the MathBook XML "Write Once, Read Anywhere"
project, bringing free text authoring to the masses with HTML, print, pdf,
epub, Jupyter, SMC, and other outputs. I'm excited to announce that the
upcoming Joint Mathematics Meetings will have a
Hi,
How much disk space is it supposed to take to download and build Sage
from source these days...?
William
--
William (http://wstein.org)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving email
I uploaded a new NTL version (9.7.1) to
http://www.shoup.net/ntl
This version completes the implementation of faster matrix
arithmetic (mul, inv, gauss, etc) modulo small primes.
These new implementations are more cache friendly, and they
make more intelligent use of available hardware (e.g.,
unclassified...
classified...
secret... (password-protected ?)
top secret... (invisible ?)
On Wednesday, April 20, 2016 at 9:39:00 PM UTC+1, Travis Scrimshaw wrote:
>
> I was thinking of this:
>
> https://wiki.sagemath.org/Classify%20old-style%20packages
>
> Best,
> Travis
>
>
--
You received th
I was thinking of this:
https://wiki.sagemath.org/Classify%20old-style%20packages
Best,
Travis
--
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+unsubsc
On Wednesday, April 20, 2016 at 6:28:00 PM UTC+1, Volker Braun wrote:
>
>
>
> On Wednesday, April 20, 2016 at 10:41:53 AM UTC+2, Dima Pasechnik wrote:
>>
>> database_jones_numfield-v4.spkg
>>
>
> There is a new-style package for that one.
>
indeed: 8-)
build/pkgs/database_jones_numfield$ git bla
Well, there is the list at http://trac.sagemath.org/ticket/19220, but I
don't think that's what you mean. It would be a starting point for packages
which can be safely deleted from the server.
--
John
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
> See the list here: http://files.sagemath.org/spkg/optional/
>
> IIRC, there is a more up to date list of packages, including which have
been made into new-style, moved to experimental, ready-to-be-removed, and
undecided. This would be more useful information IMO.
Best,
Travis
--
You re
On Wednesday, April 20, 2016 at 10:41:53 AM UTC+2, Dima Pasechnik wrote:
>
> database_jones_numfield-v4.spkg
>
There is a new-style package for that one.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop re
IMHO pip-type Sage packages should be limited to a) when we need a specific
version or b) when it is required as a dependency.
Whatever the official user-facing installation command is (i.e. "sage -i"
right now) should just fall back to pip/PyPI when there is no specific
package in Sage.
Ideal
Wow, It was easy to get that promotion!
El miércoles, 20 de abril de 2016, 18:18:00 (UTC+2), Volker Braun escribió:
>
> Congratulations, you are now in charge of contacting the maintainers ;-)
>
> On Wednesday, April 20, 2016 at 11:19:29 AM UTC+2, mmarco wrote:
>>
>> In theory, each od these pack
Congratulations, you are now in charge of contacting the maintainers ;-)
On Wednesday, April 20, 2016 at 11:19:29 AM UTC+2, mmarco wrote:
>
> In theory, each od these packages should have a mantainer. I think we
> should, at least, consult them before removing the packages.
> If a package has no
On 20 April 2016 at 15:51, rjf wrote:
> Wandering even further off topic, I think that using the verb "to code" is
> a convention
> with the effect, intentional or not, of diminishing the importance of
> programming
> in a problem-solving situation. Not always, but sometimes.
>
> For example, a
Wandering even further off topic, I think that using the verb "to code" is
a convention
with the effect, intentional or not, of diminishing the importance of
programming
in a problem-solving situation. Not always, but sometimes.
For example, a graduate student (say, in physics) will
"solve" a
On 2016-04-20 16:26, William Stein wrote:
Hi,
My one remark for this thread is that it is relatively easy to make
something pip installable.
For anybody reading William's post, better use this link:
https://python-packaging-user-guide.readthedocs.org/en/latest/
It contains similar informatio
Hi,
My one remark for this thread is that it is relatively easy to make
something pip installable. For example, somebody recently complained
that pygsl was only available via downloading files from sourceforce,
so I (very) easily made
https://pypi.python.org/pypi?:action=display&name=pygsl&ve
Specifically, Jeroen says that `sage -i blah` is more user-friendly, as
opposed to `sage --pip install blah`.
I argue that this is not true, e.g. as `sage -i` is not something that can
be reverted, whereas `sage --pip` can.
I could also say that `sage -i blah` on packages which are behind the sc
On Sat, Apr 16, 2016 at 1:49 AM, mmarco wrote:
> That is a question that we have to address: if we allow this kind of
> external packages (or furthermore, move the devlopments of parts of sage to
> a different workflow)... what kind of control will we do about them? Will we
> make no promises abou
On Fri, Apr 15, 2016 at 8:04 PM, mmarco wrote:
> My proposal would go in the direction of having three categories: optional,
> experimental, and external. Optional and Experimental would follow moreless
> what we have now, external programs that provide some functionality, and we
> keep them in ou
In theory, each od these packages should have a mantainer. I think we
should, at least, consult them before removing the packages.
If a package has no mantainer at all... that is already a good reason to
remove it from the list of optional packages.
El miércoles, 20 de abril de 2016, 9:24:01 (
On Tue, Apr 19, 2016 at 8:27 PM, Fredrik Johansson
wrote:
> On Tuesday, April 19, 2016 at 9:34:13 AM UTC+2, Erik Bray wrote:
>>
>> On Tue, Apr 19, 2016 at 3:11 AM, William Stein wrote:
>> > On Mon, Apr 18, 2016 at 6:03 PM, Kwankyu Lee wrote:
>> >> Which one is correct?
>> >>
>> >> (1) "This is
there is a discussion on http://trac.sagemath.org/ticket/20472
along these lines - PyX is an old-style optional package, apparently not
required by anything in Sage.
IMHO it should just be removed, as one can do 'sage --pip install PyX' just
fine.
Jeroen instead wants to add yet another new-style
On Wednesday, April 20, 2016 at 9:31:25 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2016-04-20 09:24, Volker Braun wrote:
> > I propose to delete them
>
> I disagree. It's not because some packages are broken, that they should
> all be removed.
>
> IMHO everything that can be pip-installed can go
On 2016-04-20 09:24, Volker Braun wrote:
I propose to delete them
I disagree. It's not because some packages are broken, that they should
all be removed.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop
As long as it is not installed as a zipped egg thats good enough. The only
real problem is when shared libraries are in zip archives...
On Wednesday, April 20, 2016 at 9:46:45 AM UTC+2, François wrote:
>
> Should we do something about the “egg” though? I don’t remember it showing
> up
> in th
On Wed, Apr 20, 2016 at 9:46 AM, Francois Bissey
wrote:
> Should we do something about the “egg” though? I don’t remember it showing up
> in the patchbot in the round of pypi updates.
http://trac.sagemath.org/ticket/20218 will address this ultimately.
As a workaround one can also install Numpy us
Should we do something about the “egg” though? I don’t remember it showing up
in the patchbot in the round of pypi updates.
François
> On 20/04/2016, at 19:36, Volker Braun wrote:
>
> There is a numpy update coming up; The patchbots installed the updated numpy,
> but then apparently didn't dow
There is a numpy update coming up; The patchbots installed the updated
numpy, but then apparently didn't downgrade when testing the next ticket
On Wednesday, April 20, 2016 at 9:24:59 AM UTC+2, Frédéric Chapoton wrote:
>
> Several patchbots (poseidon and sage4) meet the same failing doctest
Several patchbots (poseidon and sage4) meet the same failing doctests,
related to numpy:
File "src/sage/env.py", line 165, in sage.env.sage_include_directories
Failed example:
sage.env.sage_include_directories()
Expected:
['.../include',
'.../include/python...',
'.../python.../si
Since we once again had a thread about the pains of accidentally installing
an old-style optional package, I propose to delete them except the
following instead of opening a trac ticket for each one once something bad
happened. If there is anything else you want to hit reply...
See the list her
34 matches
Mail list logo
