On Friday, November 19, 2021 at 2:59:55 AM UTC+9 Matthias Koeppe wrote:
> ... So it would look like this:
>
> *sagemath-objects* < *sagemath-categories* < *sagemath-coding* <
> *sagemath-standard-no-symbolics* < *sagemath-standard*
>
>
package sage.coding needs linear algebra, all kinds of
> Let me sketch my strategy to get closer to the design of other
> distributions. https://trac.sagemath.org/ticket/29865 (waiting for
> review) introduces the two lowest levels - *sagemath-objects*,
> *sagemath-categories.* As soon as we have namespace packages working, the
> latter will
On Thursday, November 18, 2021 at 11:47:37 AM UTC+9 Matthias Koeppe wrote:
> That would be https://trac.sagemath.org/ticket/29705
Yes, all the information could be found in the ticket description and the
descriptions of the subtickets. But the master plan is buried in the
details. I want to
Hi,
Sage modularization is going on, and I see in trac many tickets toward the
goal. But I wonder what is the master plan. I mean the plan how sage
library would be split. Here and there I read that some packages in the
sage library will be namespace packages, and others won't be. It would be
Never mind. I was mistaken. The docstring was not raw.
Sorry for the noise.
--
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
The branch for the ticket
https://trac.sagemath.org/ticket/32615
contains "\g" in the docstring of a method. The docstring is a raw string
(in r"""..."""). But in building doc, I get
[function_] building [html]: targets for 1 source files that are out of date
[function_] updating environment:
>
> There is nothing strange in this log, everything looks as expected.
>
Okay. That is reasonable because this was building from scratch, and it
finished without problem.
We need to look at the config.log of gsl to see the error it gives.
>
The error was from an incremental build from an old
On Thursday, September 30, 2021 at 5:10:25 PM UTC+9 dim...@gmail.com wrote:
> ... you can see it in top-level config.log (the following is what you see
> if openblas is accepted):
>
> ## Checking whether SageMath should install SPKG openblas... ##
> ##
On Thursday, September 30, 2021 at 5:09:07 AM UTC+9 John H Palmieri wrote:
> One guess would be that ./configure found what it thought was a usable
> installation of openblas, but when gsl tried to build, that openblas was
> not in fact usable.
>
Perhaps. That is strange. It was "not
My question is: why "make" does not build openblas first and then gsl,
instead of forcing me to do this manually?
On Wednesday, September 29, 2021 at 6:03:15 PM UTC+9 Kwankyu Lee wrote:
> Hi,
>
> I started to build the latest Sage 9.5.beta2 from some old Sage
&g
Hi,
I started to build the latest Sage 9.5.beta2 from some old Sage
installation on Mac. Then it failed while building "gsl" complaining
missing "openblas" library. I could overcome the problem by issuing "sage
-i openblas". I went through this twice on two Sage installations on the
same
On Friday, August 20, 2021 at 3:58:00 AM UTC+9 Gregory Bard wrote:
> I'm so grateful that this issue of cube roots (and other real nth roots)
> has been solved so successfully. It's a huge help to those of us who
> teach calculus, and it's a good story to showcase the cooperative
> atmosphere
On Thursday, August 12, 2021 at 2:41:04 AM UTC+9 Matthias Koeppe wrote:
> The discussion of semantic innovations for the parents seems like a
> distraction to me. Note that in Python, the distinction between the mutable
> and immutable version of a type is usually expressed by different types:
On Wednesday, August 11, 2021 at 7:39:14 AM UTC+9 Nils Bruin wrote:
> The semantics are actually quite straightforward: it's
> hashability-on-demand.
>
The demand is implicit and not explicitly demanded, like set_immutable(),
by the user. We may imagine a situation that this causes a
On Tuesday, August 10, 2021 at 9:07:09 AM UTC+9 Nils Bruin wrote:
> It may well be that it's convenient internally to have element
> constructors to allow for a "mutable=True/False" flag. It may even help
> with implementing the feature under consideration here: making sure that
> vector
I bet this ticket has the simplest nontrivial patch:
https://trac.sagemath.org/ticket/32314
--
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
Actually it depends:
sage: def build():
: v = vector(ZZ, 1000)
: for i in range(1000):
: v[i] = Integer(i)
: return v
:
:
sage: def build2():
: l = list()
: for i in range(1000):
: l.append(Integer(i))
: return
On Saturday, August 7, 2021 at 6:13:19 AM UTC+9 wst...@gmail.com wrote:
> Possible benefits may include:
>
> - potentially much faster: for similar reasons to numpy, a mutable sage
> vector can be much faster than a generic Python list.
>
>
sage: def build():
: v = vector(QQ, 1000)
On Saturday, August 7, 2021 at 5:47:54 AM UTC+9 Nils Bruin wrote:
> So how bad would it be to potentially double the number of vector spaces
> in existence by giving them an extra parameter determining whether fresh
> vectors (such as those resulting from vector arithmetic) should be mutable
>
> So ... I suspect there's a lot of code in sage where immutable vectors
> wouldn't hurt, because a lot of operations will rely on the default
> arithmetic, which creates new vectors for results. However, there are some
> places where it would be a problem.
>
Precisely this many failures if
On Friday, August 6, 2021 at 11:18:30 AM UTC+9 Nils Bruin wrote:
> On Thursday, 5 August 2021 at 18:42:55 UTC-7 Kwankyu Lee wrote:
>
>> I didn't know that a fresh new vector is mutable. I have never used this
>> feature. Why does it make sense that a new vector star
On Friday, August 6, 2021 at 8:25:08 AM UTC+9 Nils Bruin wrote:
> I am fully aware of why vectors *can* be mutable and that having them
> start out life mutable makes sense (since you cannot really change an
> immutable vector back to mutable)
>
I didn't know that a fresh new vector is
Maybe related with
https://trac.sagemath.org/ticket/31948
which you reviewed.
On Tuesday, July 20, 2021 at 1:45:48 AM UTC+9 dim...@gmail.com wrote:
> observed with the latest beta on Linux and macOS:
>
> ...
> [dochtml] [reference] valuations: 1 todos, 14 index, 0 citations, 13
> modules
>
On Thursday, July 15, 2021 at 2:14:20 PM UTC+9 John H Palmieri wrote:
> I think that we should prefer tuples to lists when that is appropriate,
> lists to tuples when that is appropriate. Python has both types for good
> reasons, I think, and I don't see why we should globally recommend one
While we are at
https://trac.sagemath.org/ticket/32200
which is really about standardizing types of return values. How about
including recommendation to prefer `tuple` to `list`? Of course this is
only to apply to functions and methods for users. I think it is good to
have a default type so
This is now
https://trac.sagemath.org/ticket/32200
--
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
On Monday, July 12, 2021 at 12:44:05 AM UTC+9 Nils Bruin wrote:
> I'd expect it's (1). A more nuanced version might be:
>
> (5) As a rule, an Integer should probably be returned if the code is
> probably going to interact with other sage code, but if you have good
> (efficiency) reasons to
Hi,
First of all, it is a bit perplexing to to ask a basic question after
working with Sage more than ten years... Anyway here is the question:
When I write Sage library code returning an integer value, is it ok to
return `int` or should it always return `Integer`?
If the return value is of
Hi Frédéric.
On Thursday, July 8, 2021 at 1:40:02 AM UTC+9 Frédéric Chapoton wrote:
> Kwankyu, may I presume that you are korean or speak korean ?
I am Korean.
> If so, would you please tell if the korean banner is translated correctly,
> or suggest a better translation ?
>
The Korean
On Monday, July 5, 2021 at 9:52:21 PM UTC+9 Michael Orlitzky wrote:
> There's a lot of low-hanging fruit to be had. If you start with
> Harald's logo from
>
> https://github.com/sagemath/artwork
>
> and delete all of the noise, for example, you get something
> respectable.
>
I don't like
On Wednesday, July 7, 2021 at 4:55:15 AM UTC+9 Trevor Karn wrote:
> Hi there,
>
> I'm currently working on upgrading to sage 9.4.beta4 from source. I'm not
> having any trouble with it (so far), but I was hoping to keep writing some
> code. I'm concerned that if I edit code while sage is
On Monday, July 5, 2021 at 7:08:04 AM UTC+9 John H Palmieri wrote:
> Does anyone have experience working with graphic designers? How much would
> it cost to get a logo designed by a professional?
+1 for designing the logo anew. I never liked the amateurish logo. Now Sage
deserves a better
Hi all,
The ticket
https://trac.sagemath.org/ticket/27957
adds algebraic geometry error correcting codes (also called geometric Goppa
codes) and their decoders to Sage. Once merged, this will be another edge
where Sage is superior to Magma.
Travis and I are working on the ticket, and we
Hi all,
The patch in the ticket
https://trac.sagemath.org/ticket/31536
aims to solve a few problems in displaying sage objects in jupyter
environment.
As we are fear of any regressions, please test the patch with your favorite
sage objects. Thank you.
--
You received this message because
There is an error in my description of the present situation. Let me
correct it.
Presently,
show(obj)
shows the latex+mathjax representation wrapped in html, which is the rich
output of the object. The ticket changes the rich output of the object to
the html+mathjax representation, which you
On Wednesday, March 24, 2021 at 5:49:41 AM UTC+9 Eric Gourgoulhon wrote:
> Le mardi 23 mars 2021 à 20:28:45 UTC+1, wst...@gmail.com a écrit :
>
>> Because I created this years before Jupyter started...
>>
>
> Ah yes!
>
> it would be great to redo it.
>>
>
> As a starting point, it would
Hi all,
Changes by ticket #31536 may cause unexpected regressions in Sage in
jupyter notebook. Please test and leave comments.
Here is the address: https://trac.sagemath.org/ticket/31536
Thank you!
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
Hi,
Meanwhile, lazy Laurent series ring is also available.
sage: L. = LazyLaurentSeriesRing(QQ)
sage: f = 1 - z - z^2
Acknowledging first all that William did and the fact that Harald is
currently maintaining the website,
I think that the Sage website should remove the links to Cocalc from the
front page. Perhaps they can be collected in a displayed box dedicated for
sponsors.
--
You received this
On Friday, October 23, 2020 at 4:13:52 PM UTC+9 Fredrik Johansson wrote:
> I'm not sure if there can be such a field. For exact use, perhaps. In
> general, Calcium will be much slower than RR or RBF if you just want
> numerical values. It will be terrible for plotting, for example. In any
>
>
> Currently working on that (see http://fredrikj.net/calcium/ and
> http://fredrikj.net/blog/2020/09/benchmarking-exact-dft-computation/).
>
Looks great! The standard question is then: do you think your library fits
for the throne of RealField and could rule peacefully other "real fields"
I have a pretty long list of doctests (and implementation) that an
> abstraction of the genuine real field, as a container, should satisfy,
> and the previous examples will not hold.
>
Then it should be called "AbstractRealField", and we set RR =
AbstractRealField, CC =
>
> +1 as well of course. A harder question is whether we are ready to
> replace the Python names RealField and RR with RealFloatingField and
> RFF, so that the names RealField and RR could be used for the genuine
> real field.
>
I wonder if there is a real prospect that the genuine real
The last line of Volker's recipe is actually:
* Run "xcode-select --switch /Applications/Xcode-11.app/Contents/Developer"
to switch
--
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
ot;math functionality" available without extra imports and
> that's the point of Sage in general. While stuff for dealing with files and
> warnings is special enough to require special commands.
>
> On Wednesday, 2 September 2020 at 00:08:57 UTC-6 Kwankyu Lee wrote:
>
>> +1 to re
+1 to remove all.
On Wednesday, September 2, 2020 at 1:50:07 PM UTC+9 John H Palmieri wrote:
> There is a ticket (https://trac.sagemath.org/ticket/25383) about removing
> some Sage functions from the global namespace, which I think is a good
> idea. But Sage also imports some Python modules:
Hi,
Some of you might be affected by the changes made by this ticket
https://trac.sagemath.org/ticket/29993
to the TOC of Sage Reference Manual. Or you might want to make your own
change to the TOC while we are at it. Then leave your comment there.
--
You received this message because you
On Saturday, June 27, 2020 at 5:18:26 PM UTC+9 john.c...@gmail.com wrote:
> I woke up to see ticket #2 sitting there so could not resist.
Congratulation! By the ticket
#3 reported by John Cremona in the year 2020,
you carved your honorable name into the history of SageMath.
We, the
For your info,
#2 authored by Daniel Krenn, reviewed by Clemens Heuberger, 4 years ago
#1 *sage-duplicate/invalid/wontfix, reviewed by *David Kirkby, 10 years
ago
#1 fixed by William Stein, 14 years ago
--
You received this message because you are subscribed to the Google Groups
I took #29994. Who will win #3?
--
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
>From the review:
*Its genesis came from the frustration that its creator William Stein and
others felt with the commercial systems such as Maple, Mathematica, MATLAB,
and the academic, but still expensive, Magma system.*
Sage freed me from the frustration!
--
You received this message
Thanks. A good read!
--
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
On Saturday, March 28, 2020 at 1:05:01 AM UTC+9, Paddy Adams wrote:
>
> At the moment the implementation of algebraic curves in Sage doesn't seem
> to be connected at all to the implementation of Function Fields. Is this
> intentional? It would seem to be useful to be able to, for example, get
On Saturday, March 28, 2020 at 6:16:25 PM UTC+9, John Cremona wrote:
>
> Certainly this is not intentional. It just has not been done.
Wrong. It was recently done for curves over finite fields in affine and
projective spaces.
As we already have function fields over number fields, it would
On Friday, February 28, 2020 at 3:37:52 AM UTC+9, Markus Wageringel wrote:
>
> This is an interesting suggestion. How would this work with
> non-interactive builds like on the patchbots or in CI?
>
So add a docbuild option `--yes-download` to prevent asking. And
`--no-download` might be
>
> At the same time, Sage is trying to move away from Sage-the-distribution,
> so that packaging third-party inventory files for offline use in Sage is
> undesirable as well, not to mention the maintenance overhead this would
> entail.
>
3. Ask by default before downloading missing
On Sunday, February 16, 2020 at 10:10:11 AM UTC+9, Michael Orlitzky wrote:
>
> On 2/14/20 7:55 PM, Michael Orlitzky wrote:
> >
> > But... is that the distinction that we want to make? I'm skeptical that
> > the person who wrote that paragraph in the developer's guide had the
> > 1995
On Friday, February 14, 2020 at 11:01:05 PM UTC+9, Michael Orlitzky wrote:
>
> Should it apply to *methods* that also act like constructors, even
> though visually, something like cones.Foo() doesn't look like a
> constructor (it looks like a method)?
I would think
cones
On Sunday, February 9, 2020 at 3:18:05 PM UTC+9, vdelecroix wrote:
>
> Le 06/02/2020 à 06:29, Kwankyu Lee a écrit :
> > I think the correct behavior of echelon_form(transformation=True) is to
> > choose a backend algorithm that actually produce a transformation matrix
&
I solved the first question:
sage: me = m.extended_echelon_form()
sage: p = me.submatrix(0,3)
sage: p * m
[1 0 4]
[0 1 2]
[0 0 0]
--
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,
Hi,
It surprised me to find that my expectation fails:
sage: m = matrix(GF(5), 3, [1,2,3,4,5,6,7,8,9])
sage: m
[1 2 3]
[4 0 1]
[2 3 4]
sage: m.echelon_form(transformation=True)
[1 0 4]
[0 1 2]
[0 0 0]
sage: m = matrix(QQ, 3, [1,2,3,4,5,6,7,8,9])
sage: m.echelon_form(transformation=True)
[ 1 0
On Saturday, December 7, 2019 at 7:21:44 PM UTC+9, Frédéric Chapoton wrote:
>
> The patchbot named "sage4" has been banned from posting its reports. It
> will be unbanned when Jeroen tells us that he is taking care.
>
Thank God!
--
You received this message because you are subscribed to the
On Friday, October 18, 2019 at 4:43:53 PM UTC+9, Mao Zeng wrote:
>
> As I understand, groebner_basis() in Sage uses Singular as a backend to
> compute the groebner basis of ideals in polynomial rings. However, Singular
> can also compute the groebner basis of modules. Is this functionality
>
>
> However, someone who knows about git (i.e., not I) should report the bug
> that git allows deletion of a branch that is checked out in another
> worktree.
>
I don't see that bug. This is what happens when I try that: (* denotes the
branch on the worktree I am currently on; + denotes
On Saturday, September 28, 2019 at 3:17:55 AM UTC+9, Simon King wrote:
>
> Hi!
>
> At some point I was advised to use "git worktree" to have one py2 and
> one py3 installation sharing the same git repository. Till one hour ago,
> it worked fine.
>
> Now, if I understand correctly, in my py2
The situation will be improved after
https://trac.sagemath.org/ticket/27873
for curves over finite fields.
--
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
>
> IIRC, singular returns the output of the resolution in a complicated way
> (defining several rings, and some ideals inside them). Maybe it would make
> sense to use the Sage schemes infrastructure to wrap that in a more
> user-friendly way (although the schemes code itself could use some
Hi,
It seems to me that currently only two patchbots are reliably testing
patches. One of them is "hades" that I am running temporarily. Owners of
patchbots should check if his or her patchbot is polluting trac with wrong
results rather than helping reviewers.
--
You received this message
Hi,
The ticket at
https://trac.sagemath.org/ticket/28096
makes cached methods with do_pickle=True work (get the content pickled) for
UniqueRepresentation objects. This is not an issue at an obscure corner of
Sage, but would affect most users when saving objects to disk.
Note that most
Now there is a one-line patch at
https://trac.sagemath.org/ticket/26254
to fix the problem.
I wish that cython experts check that out. I am concerned whether the patch
has any unexpected side effect that I cannot foresee.
--
You received this message because you are subscribed to the Google
There is already a ticket for that:
https://trac.sagemath.org/ticket/26254
but no one is working on it.
On Sunday, July 21, 2019 at 1:32:24 AM UTC+9, John H Palmieri wrote:
>
> See
> https://ask.sagemath.org/question/47214/help-doesnt-show-function-call/.
> Some of the time when you evaluate
On Thursday, June 27, 2019 at 9:45:42 PM UTC+9, Simon King wrote:
>
>
> I think if pickling doesn't preserve the content of the cached method
> then it is a bug.
>
UniqueRepresentation objects do not preserve the content of the cached
method with do_pickle=True.
This problem is solved in
>
> From the code, I learned that there is "do_pickle" option. With
> "do_pickle=True", the content of the cached method is indeed preserved with
> an experimental class. I will check again with my production code.
>
I applied "do_pickle=True" option to F.weierstrass_points() with global
On Thursday, June 27, 2019 at 10:20:55 PM UTC+9, Volker Braun wrote:
>
> There is the do_pickle argument, e.g. from TFM:
>
> sage: class C:
> : @cached_method(do_pickle=True)
> : def __hash__(self):
> : return id(self)
>
>
> Note that it can cause the following
On Thursday, June 27, 2019 at 9:45:42 PM UTC+9, Simon King wrote:
>
> Hi!
>
> Is it a Python object?
>
Yes.
> A cached method (if that hasn't changed since I last looked at the code)
> stores the cached values in some dict stored as an attribute, and when
> you pickle the object (at
On Thursday, June 27, 2019 at 4:41:30 PM UTC+9, John Cremona wrote:
>
> I think this is one disadvantage of using the cached_method decorator,
> instead of the clumsier way of actually storing the result in the object,
> eg. by setting X._genus. In your example I cannot think of a reason why
Hi,
Suppose I have an object X. I computed X.genus(), which took a long time.
The method genus() is a cached method. So it gives the result quickly next
time. Then I saved the object X. After loading X in a new session, I want
X.genus() to give the cached result rather than computing it again.
On Friday, June 14, 2019 at 8:16:58 PM UTC+9, Dima Pasechnik wrote:
>
> On Fri, Jun 14, 2019 at 12:04 PM Kwankyu Lee > wrote:
> >
> > Hi
> >
> > I noticed that the coercion section of the sage reference manual
> mentions _r_action_ and _
Hi
I noticed that the coercion section of the sage reference manual mentions
_r_action_ and _l_action methods instead of _act_on_ and _acted_upon_
methods, while it seems that the former methods were replaced with the
latter methods 10 years ago in #5597!
Am I right? Then this is quite
Hi,
I pushed the code for integral curves over finite fields to ticket #27873:
https://trac.sagemath.org/ticket/27873
for those who want to experiment with it. Thank you.
Kwankyu
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
On Sunday, May 19, 2019 at 9:50:22 PM UTC+9, Eric Gourgoulhon wrote:
>
> LaTeX is arguably the best way to display mathematics
>
I agree with this, but sage objects are not mathematics.
> If one would like the plain text view of an object X instead, one can use
> print(X).
> So, in the
On Sunday, May 19, 2019 at 5:48:23 PM UTC+9, Volker Braun wrote:
>
> If you find yourself typing show() all the time you probably want to
> change the displayhook to typeset stuff, i.e. you want "%display typeset"
> in the notebook or on the command line:
>
> sage: m = random_matrix(ZZ, 3)
>
On Sunday, May 19, 2019 at 1:42:02 PM UTC+9, John H Palmieri wrote:
>
> Did you try "print(mat.str())"?
>
No I didn't. Thanks for the tip.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
Hi,
If mat is a matrix of large size, it is displayed in a short form:
sage: mat
22 x 32 dense matrix over Finite Field of size 2 (use the '.str()' method
to see the entries)
Then if I follow the recommendation,
sage: mat.str()
'[1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 1
Hi,
How about adding show() method to the class of sage objects, so that we can
do
mat.transpose().show()
instead of
show(mat.transpose())
which is cumbersome to add to and remove from mat.transpose()? This is
useful in Jupyter notebook.
Kwankyu
--
You received this message because you
This is now
https://trac.sagemath.org/ticket/27844
which needs review.
--
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.
Hi,
I observed
sage: F = GF(2)
sage: E = GF(4)
sage: phi = E.coerce_map_from(F); phi
Ring morphism:
From: Finite Field of size 2
To: Finite Field in z2 of size 2^2
Defn: 1 |--> 1
sage: phi.section()
---
TypeError
On Friday, May 10, 2019 at 4:04:15 PM UTC+9, Simon King wrote:
>
>
> On 2019-05-10, Kwankyu Lee > wrote:
> > 1. It is very, but not terribly, slow compared with Magma. One may want
> to
> > improve the speed.
>
> Is there a ticket for it, which also
Dear Sage developer community,
As of Sage 8.8.beta4, the global function field code of the ticket #22982
has finally landed all in Sage. Following the tradition of giving a report
when a major piece of new functionality is added to Sage, I will now
briefly recall what we achieved and thank the
On Sunday, March 24, 2019 at 4:43:47 AM UTC+9, Andrey Novoseltsev wrote:
>
> On Saturday, 23 March 2019 00:25:10 UTC-6, Kwankyu Lee wrote:
>>
>> I would expect one process runs all interact cells from one client (if
>> this makes sense).
>>
>> I have a
>
> On Friday, March 22, 2019 at 12:56:58 AM UTC+9, Andrey Novoseltsev wrote:
>>>
>>> "languages" for SageMathCell are very different from kernels for
>>> Jupyter. SageMathCell keeps a bunch of preforked kernels (all are the same)
>>>
>>
>> And a new kernel is created for each interact cell.
On Friday, March 22, 2019 at 12:56:58 AM UTC+9, Andrey Novoseltsev wrote:
>
> "languages" for SageMathCell are very different from kernels for Jupyter.
> SageMathCell keeps a bunch of preforked kernels (all are the same)
>
And a new kernel is created for each interact cell. Right? This seems
Hi,
If the determinant is obviously zero, then you don't need to run the
computation. If a preprocessing to check zero rows or columns is added,
then the determinant computation would become slower for usual nontrivial
cases.
Cheers.
On Saturday, March 16, 2019 at 2:15:06 AM UTC+9,
On Wednesday, March 13, 2019 at 9:04:32 PM UTC+9, Simon King wrote:
>
> PS:
>
> On 2019-03-13, Simon King > wrote:
> > There are of course cases in which a default pickling mechanism makes
> > sense (think of UniqueRepresentation). However, I think that Map is
> > not such a case.
> >
> >
>
> What did I do wrong? Or what should I do more?
To pass _test_pickling, it is enough to implement __eq__ method. This is
reasonable!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
>
> The _test_category issue is something that shows up with every map (and I
> think homset). This is because the parent (i.e., the homset) does not
> (usually) have a single Element class, but the _test_category is checking
> that the map is a subclass of the element_class that is
Hi,
I thought the idiom to define a map is:
from sage.categories.map import Map
from sage.categories.homset import Hom
from sage.categories.fields import Fields
class Derivation(Map):
def __init__(self, field):
Map.__init__(self, Hom(field, field, Fields()))
But then the last two
On Wednesday, February 27, 2019 at 11:25:38 PM UTC+9, Daniel Krenn wrote:
>
> Can I savely assume that S.an_element() of something S (within SageMath)
> returns an element different from S.zero() if possible (meaning if there
> are nonzero elements in S)?
>
The purpose of S.an_element() is
>
>
> In particular, Jeroen, concerning the strange rule that _lmul_ not being
> implemented means that it returns None: I seem to recall (but I am not
> 100% sure) that P._get_action_(Q) (or some other method name, I don't
> recall) could test what happens if P.zero()._lmul_(Q.zero()) or
On Wednesday, February 27, 2019 at 3:26:08 PM UTC+9, Jeroen Demeyer wrote:
>
> On 2019-02-26 23:44, Kwankyu Lee wrote:
> > It could be possible to hammer the coercion model to behave more nicely
> > with the category framework, at least with respect to the issue
301 - 400 of 737 matches
Mail list logo
