Re: [sage-devel] Re: Vector spaces with immutable vectors by default

I like the idea proposed in https://trac.sagemath.org/ticket/29101 (as posted by Matthias). Namely, introducing the option mutable=False for the element constructor. Then your code could be rewritten to sum( D[V(v0+w, mutable=False)] for w in W) which should be fine, I guess. Travis Scrimshaw s

[sage-devel] Re: How to use generic quotients?

l we are able to implement the quotients > in #32249. Does anyone see any reason not to implement such an error? Or at > least a warning? > > On Tuesday, July 27, 2021 at 8:33:13 AM UTC-5 Michael Jung wrote: > >> Thank you Trevor! This was extremely helpful! >> Trevor Karn sch

[sage-devel] Re: How to use generic quotients?

he graded commutative > algebras. I opened a ticket https://trac.sagemath.org/ticket/32249 to > start doing this but in the meantime got pulled toward other tasks for my > GSoC project. > > On Monday, July 26, 2021 at 1:43:33 PM UTC-5 Michael Jung wrote: > >> Sorry, the last exam

[sage-devel] Re: How to use generic quotients?

Sorry, the last example is of course sage: from sage.algebras.commutative_graded_algebra_finite import FiniteGCAlgebra sage: A. = FiniteGCAlgebra(QQ, degrees=(1,2,3), max_degree=6) sage: I = A.ideal(y^2) sage: Q = A.quotient(I) sage: Q.gen(1)^2 ybar^2 Michael Jung schrieb am Montag, 26. Juli

[sage-devel] How to use generic quotients?

Hello everyone, In https://trac.sagemath.org/ticket/32272, I am trying to implement graded algebras with finite degree. I have troubles constructing a (generic) quotient. Here is what happens without a ngens method: sage: from sage.algebras.commutative_graded_algebra_finite import FiniteGCAlge

[sage-devel] Unification of generic ring methods

Hello everyone, I have encountered some inconsistencies in the code involving rings. Some implementations use R.is_field() To check whether a ring R is a ring whereas other implementations prefer R in Fields() I propose to unify this behavior. A first approach and discussion can be found h

[sage-devel] Unification of generic ring methods

Hello everyone, I have encountered some inconsistencies in the code involving rings. Some implementations use R.is_field() To check whether a ring R is a ring whereas other implementations prefer R in Fields() I propose to unify this behavior. A first approach and discussion can be found he

[sage-devel] Graded algebra with finite degree

Hello, For my next project I need graded algebras with finite degree. So far, Sage provides commutative (graded) differential algebras: https://doc.sagemath.org/html/en/reference/algebras/sage/algebras/commutative_dga.html A finite degree could be obtained by using appropriate ideals from this

[sage-devel] Re: Possible bug in gen_legendre_P (associated Legendre polynomials)

Unfortunately, I am not familiar with the details either. Nevertheless, I have made the proposed change for the interval -1https://mathworld.wolfram.com/AssociatedLegendrePolynomial.html. Most importantly, this also solves the problem with spherical harmonics, which was the a highly requested fi

[sage-devel] Re: spherical harmonics still broken in 9.3.rc2

I changed priority to "critical". This feature is obviously highly demanded among the community (cf. https://trac.sagemath.org/ticket/25034#comment:6). Best, Michael Jonathan Thornburg schrieb am Donnerstag, 8. April 2021 um 20:12:19 UTC+2: > There have been longstanding issues with spherical ha

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

P.S. Same for the ticket links I didn't provide since I assumed they will be added automatically similar to the Sage trac server. Michael Jung schrieb am Montag, 5. April 2021 um 10:40:01 UTC+2: > Thank you. But also sorry, I spotted a mistake: > > "under the weaker assumpti

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

Thank you. But also sorry, I spotted a mistake: "under the weaker assumption of the base ring being a Q-algebra" -> "under the weaker assumption of the base ring's fraction field being a Q-algebra" Moreover, it would be nice if you could adapt the syntax. I used markdown for simplicity since I

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

Here we go. Thanks for taking care of it, Matthias! Michael Jung schrieb am Montag, 5. April 2021 um 00:29:07 UTC+2: > Meaning, I will post it here. > > Michael Jung schrieb am Montag, 5. April 2021 um 00:28:24 UTC+2: > >> Alright, thanks. For now then, I'll post my pro

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

Meaning, I will post it here. Michael Jung schrieb am Montag, 5. April 2021 um 00:28:24 UTC+2: > Alright, thanks. For now then, I'll post my proposal the upcoming days. Is > markdown format fine? > Matthias Koeppe schrieb am Sonntag, 4. April 2021 um 21:59:53 UTC+2: > >>

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

d. > https://trac.sagemath.org/wiki/WikiStart#legacy-account-request > > On Sunday, April 4, 2021 at 12:06:50 PM UTC-7 Michael Jung wrote: > >> Is there a way I can get access though? There is a bit more worth to add: >> - https://trac.sagemath.org/ticket/18416 >>

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

. April 2021 um 18:49:31 UTC+2: > Just post the text here that you want added and I can add it. > > On Sunday, April 4, 2021 at 9:29:08 AM UTC-7 Michael Jung wrote: > >> >> It might also worth to mention that the Pfaffian of a matrix can now be >> computed wi

[sage-devel] Re: https://wiki.sagemath.org/ReleaseTours/sage-9.3

It might also worth to mention that the Pfaffian of a matrix can now be computed with a much way faster algorithm: https://trac.sagemath.org/ticket/30681. I would add an example to the Release tour but I don't know how or I don't have access... Samuel Lelievre schrieb am Montag, 22. März 2021

Re: [sage-devel] sagetex and tcb

Here's the issue: https://github.com/sagemath/sagetex/issues/54 I've provided a minimal example of the tcolorbox environment. Perhaps that is something that can be added to sagetex if we get it to work? Michael Jung schrieb am Sonntag, 4. April 2021 um 11:54:02 UTC+2: > Anyway, I

Re: [sage-devel] sagetex and tcb

Anyway, I will approach this on the GitHub page. This problem is more suited there than here. Thanks Dima! Best, Michael Michael Jung schrieb am Sonntag, 4. April 2021 um 11:39:46 UTC+2: > There is no bug or something. I just want to use sagetex beyond its > current capabilities. Long

Re: [sage-devel] sagetex and tcb

nimal example yet. dim...@gmail.com schrieb am Sonntag, 4. April 2021 um 10:36:34 UTC+2: > Hi, > could you file an issue in https://github.com/sagemath/sagetex - > with an example, showing what doesn't currently work. > Thanks > Dima > > On Sat, Apr 3, 2021 at 9:49 PM Michael

[sage-devel] sagetex and tcb

Hello everyone, I would appreciate some help from an TeX expert. Namely, I would like to combine tcolorboxes with the sageblock environment of sagetex. I already have my own tcolorbox format for Sage code in Jupyter style. In particular I use the "\newtcblisting" command together with "listing

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

Hi, so, what's the punch line now? I totally lost track because we digressed too much. Is the representation change still wanted or not? And if so, what shall be it? I would like to conclude https://trac.sagemath.org/ticket/24523. Best, Michael emanuel.c...@gmail.com schrieb am Samstag, 24. Ok

[sage-devel] Proposal to use Polls

Dear all, I propose to integrate more polls in our development process. Polls are good to capture the atmospheric picture about a topic. Sometimes, I lose track about the common opinion because the discussions drift in various directions; which is totally fine, but makes a traceback barely pos

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

Dear all, *-1: I don't really care what RealField.__repr__ returns, but cast a token no vote to object to the logical next move of breaking backwards compatibility by changing the meaning of RealField and/or RR. I see the need for a "genuine real field", but it seems a lot simpler just to call

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

Dear all, vdelecroix schrieb am Freitag, 16. Oktober 2020 um 07:50:46 UTC+2: > I agree that these are not fields in the mathematical sense. And Sage > knows about it > > sage: RR.is_exact() > > > False > sage: QQ.is_exact() > > > True > That's actually what I meant. We also have: sage: RR

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

Hi everyone, Thierry: *+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. * It seems, this is then a good motivation to push

[sage-devel] Re: "Real Field" -> "Real Floating-point Field"

+1 from my side, too. vdelecroix schrieb am Mittwoch, 14. Oktober 2020 um 08:28:08 UTC+2: > Dear all, > > I would like to discuss the patchbomb at > > https://trac.sagemath.org/ticket/24523 > > The ticket hopes to change the string representation from > "Real Field with XX bits of precision" to "

[sage-devel] Divison by zero error for series

Consider the following (analytic) function: sage: a = sqrt(x)/(2*sinh(sqrt(x)/2)) sage: a.taylor(x, 0, 10) 91546277357/42092863826076169666560*x^10 - 5749691557/669659197233029971968000*x^9 + 16931177/4995070990221312*x^8 - 8191/612141052723200*x^7 + 1414477/2678117105664000*x^6 - 73/35

[sage-devel] Re: ./sage -b yields error

Apparently, the makefile in src is missing somehow. But the original build was successful. -- 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...@

[sage-devel] ./sage -b yields error

Hello, today, I have built Sage 9.2.beta5 completely from scratch. I wanted to checkout a ticket and quickly rebuild the source code by using "./sage -b". Surprisingly, I got the following error message (I hope, it is correctly translated into English): make: *** No targets specified and no mak

[sage-devel] Sage9.2.beta5 Jupyter Notebook not working

Hello everyone, since version 9.2.beta5, I get a blank page when opening a Jupyter notebook. The command line shows the following error: [W 21:50:21.889 NotebookApp] 404 GET /nbextensions/mathjax/MathJax.js?config =TeX-AMS-MML_HTMLorMML-full,Safe&delayStartupUntil=configured (127.0.0.1) 1.86ms r

[sage-devel] manifolds component for trac server

Hello everybody, is it possible to add the manifolds component to the trac server? In my opinion, the geometry component is not suitable anymore since manifolds is already a quite big part by itself and certainly doesn't belong to the geometry module. This makes it extremely difficult to search

[sage-devel] Parallelization of Wedge Product Computation

Dear Sage-Developers, in the SageManifolds part, most component-wise computations can be performed on multiple cores. However, the wedge product has not been parallelized yet. But since I need this for some computations in "higher" dimensions, I want to contribute this to the project. I had alr

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

Ah, interesting. Do you have some literature/references for me? Am Montag, 1. Juni 2020 01:06:44 UTC+2 schrieb Nils Bruin: > > On Sunday, May 31, 2020 at 2:52:21 PM UTC-7, Michael Jung wrote: >> >> If I understand this correctly, I'd say this is already the approach of &g

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

I should just mention here, that a CPU parallelization on the level of components already takes place. However, watching the CPU usage one can see that only single cores are demanded. I am not certain about the reason. Am Sonntag, 31. Mai 2020 23:52:21 UTC+2 schrieb Michael Jung: > >

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

on of the determinant scales quite badly, too. I already replaced zero-involving computations by simple checks. However, this is not enough. Am Sonntag, 31. Mai 2020 22:51:27 UTC+2 schrieb Nils Bruin: > > On Sunday, May 31, 2020 at 12:41:52 PM UTC-7, Michael Jung wrote: >> >>

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

ai 2020 22:33:57 UTC+2 schrieb Nils Bruin: > > On Saturday, May 30, 2020 at 7:37:43 AM UTC-7, Michael Jung wrote: >> >> Mh. Okay. Do you have an idea how to improve the computation, e.g. by >> using multiple cores? >> >> A standard trick is to take a "multimo

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

Mh. Okay. Do you have an idea how to improve the computation, e.g. by using multiple cores? Am Samstag, 30. Mai 2020 11:37:02 UTC+2 schrieb Dima Pasechnik: > > On Sat, May 30, 2020 at 8:05 AM Michael Jung > wrote: > > > > Thanks for your respond. The entries are eleme

Re: [sage-devel] Re: Mutliprocessing for Matrix Computations?

Thanks for your respond. The entries are elements of the mixed form algebra (https://doc.sagemath.org/html/en/reference/manifolds/sage/manifolds/differentiable/mixed_form_algebra.html). Whose multiplications are already relatively slow. -- You received this message because you are subscribed t

[sage-devel] Re: Mutliprocessing for Matrix Computations?

Sorry, I meant: "especially for the division-free algorithm of the determinant." Am Freitag, 29. Mai 2020 23:46:55 UTC+2 schrieb Michael Jung: > > Dear Sage Developers, > is there a mutliprocessing support available for computations with > matrices of large dimensions? E

[sage-devel] Mutliprocessing for Matrix Computations?

Dear Sage Developers, is there a mutliprocessing support available for computations with matrices of large dimensions? Especially with respect to the division-free algorithm? Best wishes Michael -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Polarization of Homogeneous Polynomials

I wonder, if it is faster to compute the complete polynomial directly or go the way via the free algebra? Anyway, I have to deal with pretty much variables, hence a nice fast algorithm would be nice. Best Michael Am Dienstag, 5. Mai 2020 10:24:39 UTC+2 schrieb Michael Jung: > > Hi

[sage-devel] Re: Polarization of Homogeneous Polynomials

Hi Markus, these are awesome pieces of code. Thank you! Unfortunately, I need this as the full polynomial since I have to do different computations with each variable... Particularly, I have a homogeneous polynomial of matrices and want it to polarize. Best wishes MIchael Am Dienstag, 28. Apr

[sage-devel] Polarization of Homogeneous Polynomials

Dear Sage Developers, along with characteristic classes, I recently added to the SageManifolds branch, I would like to add their transgression forms now. This, however, involves a polarization of homogeneous polynomials (see https://en.wikipedia.org/wiki/Polarization_of_an_algebraic_form). I wo

Re: [sage-devel] Re: Build Error with Sage9.rc2 on Ubuntu 20.04

Oh yes. You are right. For some reason, my git repo changed back to `master`. The build has finished now. Thanks for your foresight, Matthias. Best Michael Am 26.04.20 um 19:34 schrieb Matthias Koeppe: On Sunday, April 26, 2020 at 2:55:51 AM UTC-7, Michael Jung wrote:  still, ecl won&#

[sage-devel] Re: Build Error with Sage9.rc2 on Ubuntu 20.04

Yes, exactly. Thank you Eric. I could compile pillow now, but still, ecl won't work. -- 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...@google

Re: [sage-devel] Re: Efficient algorithm to express symmetric polynomial in terms of elementary ones

d more efficient. I have no idea what is the polarization, but you can open a new thread where you explain your problem. Best Vincent Le 21/04/2020 à 12:16, Michael Jung a écrit : Wow, thanks Vincent. This is awesome! Could you shortly explain what the crucial difference is here? On thi

Re: [sage-devel] Re: Efficient algorithm to express symmetric polynomial in terms of elementary ones

1, 1] + 11/60480*e[3, 2, 1] - 1/60480*e[3, 3] - > 1/720*e[4] - 1/1440*e[4, 1] - 1/12096*e[4, 1, 1] - 1/6720*e[4, 2] - > 1/30240*e[5, 1] + 1/30240*e[6] > sage: %time t = todd(12) > CPU times: user 18.5 ms, sys: 112 µs, total: 18.6 ms > Wall time: 18.1 ms > > Best &g

[sage-devel] Re: Efficient algorithm to express symmetric polynomial in terms of elementary ones

(although in that case, Sage seems to be pretty fast). Or have I > misunderstood something? > > Thanks, > Travis > > > On Tuesday, April 21, 2020 at 10:00:35 AM UTC+10, Michael Jung wrote: >> >> Thanks for your reply Travis. >> >> Here are different com

[sage-devel] Re: Efficient algorithm to express symmetric polynomial in terms of elementary ones

then to the elementary basis (which is outsourced to > symmetrica). Do you have some references for these efficient algorithms to > convert a polynomial directly to the elementary basis? > > Best, > Travis > > > On Tuesday, April 21, 2020 at 3:18:37 AM UTC+10, Michael Ju

[sage-devel] Efficient algorithm to express symmetric polynomial in terms of elementary ones

Dear Sage developers, currently, I am working on an alternative algorithm to compute characteristic forms. I hope to gain a speed-up here. For this reason, I need to express symmetric polynomials in terms of elementary symmetric functions. At the moment, I am playing around with `SymmetricFunct

Re: [sage-devel] Inherit Method but keep Documentation?

ael Orlitzky: On 3/18/20 5:04 PM, Michael Jung wrote: Dear developers, to reduce redundancies in the SageManifolds code, we plan to inherit most methods and classes from a (mathematically) more general setup. Still, the current documentation is mandatory. Is it possible to establish new documentat

[sage-devel] Inherit Method but keep Documentation?

Dear developers, to reduce redundancies in the SageManifolds code, we plan to inherit most methods and classes from a (mathematically) more general setup. Still, the current documentation is mandatory. Is it possible to establish new documentations for inherited methods? An example: class Moth

[sage-devel] Counterexample of Fubini - Strange Result with Maxima

Dear fellow developers, I've encountered a really strange result in Sage while using Maxima. sage: f(x,y) = (x^2-y^2)/(x^2+y^2)^2 sage: integrate(integrate(abs(f(x,y)), x, 0, 1), y, 0, 1) -1/4*pi This is really weird. At least, the result should be positive! SymPy however yields th

[sage-devel] Counterexample of Fubini - Strange Result with Maxima

Dear fellow developers, I've encountered a really strange result in Sage while using Maxima. | sage:f(x,y)=(x^2-y^2)/(x^2+y^2)^2 sage:integrate(integrate(abs(f(x,y)),x,0,1),y,0,1) -1/4*pi | This is really weird. At least, the result should be positive! SymPy however yields the correct result:

Re: [sage-devel] Symbolic Variables for Internal Useg

The issue is more subtle than that. My variable must be defined on the complex domain. But sage: x = SR.var('x', domain='complex') changes the domain of x permanently. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Symbolic Variables for Internal Use

I'd like to use symbolic expressions in the source code to compute taylor expansions of predefined functions. But this affects the use of variables named the same way on the level of the user. Is there a safe way to use the framework of symbolic calculus without affecting the variables globally?

Re: [sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

Simon King a écrit : > > On 2019-10-24, Michael Jung > > wrote: > >> Do you have an example where SR fails to be exact? > > > > One can convert a float to SR. The result is in SR, but still behaves > > like a float: > >sage: a = SR(2.)^(1/500)

[sage-devel] Manifolds: Using Multiprocessing with Functions causes Error

sage: Parallelism().set(nproc=4) sage: M = Manifold(2, name='S2', latex_name=r'S^2', start_index=1) sage: U = M.open_subset('U') ; V = M.open_subset('V') sage: M.declare_union(U,V) # M is the union of U and V sage: c_xy. = U.chart() ; c_uv. = V.chart() sage: xy_to_uv = c_xy.transition_map(c_uv, .

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

I see. Maybe it is possible to decompose/split the matrix in SR into an exact and inexact part, convert the inexact part to RDF and apply the Gram-Schmidt algorithm appropiately? I don't know, maybe it's too naive? -- You received this message because you are subscribed to the Google Groups "s

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

Do you have an example where SR fails to be exact? Am Donnerstag, 24. Oktober 2019 18:20:36 UTC+2 schrieb Simon King: > > Hi Michael, > > On 2019-10-24, Michael Jung > wrote: > > Maybe, I did get something wrong. But what's the problem about > Gram-Schmidt >

[sage-devel] Re: Gram-Schmidt Procedure for Symbolic Ring

Maybe, I did get something wrong. But what's the problem about Gram-Schmidt on SR? There are just sums and divisions (and probably roots to normalize) in Gram-Schmidt which should not lead to problems in SR. By the way, what does "exact" actually mean? Am Mittwoch, 23. Oktober 2019 22:41:53 UTC

[sage-devel] Gram-Schmidt Procedure for Symbolic Ring

Hello everyone, I have a question regarding the implemented Gram-Schmidt procedure. Using a matrix in the symbolic ring leads to the following error message: m = matrix(SR, [[x,2*x],[x^2,1]]) m.gram_schmidt() --- NotImplemen

[sage-devel] Force Field Algorithm for Matrices Consisting of Non-field Elements

Dear community, I've already opened a ticket on this topic. In the manifold implementation, scalar fields behave a lot like symbolic ring elements: There is a division behind and "most" of the elements behave like field elements. Since the manifold pack

[sage-devel] Manifolds: Pullback/Pushforward Notation

Dear community, at this stage, the pushforward of a differentiable map '\Phi' is noted by '\Phi^*'. After some discussion with my collegues and consulting common literature (like "Smooth Manifolds" by Lee), this seems not to be the canonical notation. I've already opened a ticket

[sage-devel] Manifolds: 'set_restriction' Behaviour

Dear community, sage: M = Manifold(2, 'M') sage: X. = M.chart() sage: eX = X.frame() sage: a = M.one_form() sage: b = M.one_form() sage: a[eX,:] = x*y, x+y sage: b.set_restriction(a) sage: b.display() ValueError Traceback (most recent call last) ... ValueError: no basis could be found for comp

Re: [sage-devel] Problems Compiling 8.8beta9

Thank you. A complete new compilation did work (except an error occurring while compiling the doctest). Am 08.09.19 um 10:23 schrieb Dima Pasechnik: On Sun, Sep 8, 2019 at 12:25 AM Michael Jung wrote: I'll try this one. So, there was a major change in beta 9? major or not, here is the

Re: [sage-devel] Problems Compiling 8.8beta9

lowed by make > and perhaps even recompile from scratch (i.e. after doing make distclean) > in some cases. > > > On Sun, Sep 8, 2019 at 12:06 AM Michael Jung > wrote: > > > > Exactly! I came from stable 8.8 and used "sage -br" to compile the beta >

Re: [sage-devel] Problems Compiling 8.8beta9

Exactly! I came from stable 8.8 and used "sage -br" to compile the beta version. OS: Ubuntu 18.04 Log (pw: sage): https://boxup.uni-potsdam.de/index.php/s/3jqidVADCcJT5ky Am Sonntag, 8. September 2019 00:46:16 UTC+2 schrieb Dima Pasechnik: > > On Sat, Sep 7, 2019 at 11:28

[sage-devel] Problems Compiling 8.8beta9

Dear everyone, since this morning, I try to compile 8.8beta9. Unfortunately, the compilation gets stuck right at: .../sage/local/include/libLfunction/Lfind_zeros.h:1231:58: warning: ‘tmp2’ may be used uninitialized in this function [-Wmaybe-uninitialized]

[sage-devel] Re: Matrix Inverse for Arbitrary Rings

omain? Best, Michael Am Samstag, 13. Juli 2019 14:23:31 UTC+2 schrieb Simon King: > > Hi Michael, > > On 2019-07-13, Michael Jung > wrote: > > You could try something like > > try: > > is_field = R.is_field() > > except TypeError: > > is

Re: [sage-devel] Matrix Inverse for Arbitrary Rings

It is supposed to work for inheritances of Ring (see sage.rings.ring): def is_field(self, proof=True): if self.is_zero(): return False if proof: raise NotImplementedError("No way to prove that %s is an integral domain!" % self) else: return False But due to th

Re: [sage-devel] Matrix Inverse for Arbitrary Rings

Dear Vincent, you're exactly right. Here is a minimal example: sage: M = Manifold(2, 'M', structure='top') sage: X. = M.chart() sage: matrix = MatrixSpace(X.function_ring(), 2)([x,0,0,y]); matrix [x 0] [0 y] sage: sage: matrix.adjugate() --

Re: [sage-devel] Matrix Inverse for Arbitrary Rings

lgorithms. This should be reasonable enough. Best Vincent Le 12/07/2019 à 16:43, Michael Jung a écrit : Dear developers, I need to compute the inverses of matrices over commutative rings (namely scalar fields on manifolds). Unfortunately, the algorithms only process if the ring is a field or

[sage-devel] Matrix Inverse for Arbitrary Rings

Dear developers, I need to compute the inverses of matrices over commutative rings (namely scalar fields on manifolds). Unfortunately, the algorithms only process if the ring is a field or a corresponding fraction field is known. For now, I will pretend that the algebra of scalar fields is an al

[sage-devel] Re: Characteristic Classes - Implement Vector Bundles?

How can I delete the actual branch on trac and create a new one? And: How do I merge properly to the recent beta version? I am sorry, it seems I'm too stupid for git trac. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] Re: Characteristic Classes - Implement Vector Bundles?

Damn it, I feel so stupid! :D Thanks, this did the job. :) Am 15.05.2019 um 14:48 schrieb Travis Scrimshaw: However, the interesting part for me is the commutative subalgebra of even mixed forms which I could certainly implement. But I am not sure whether this will work due to the

[sage-devel] Re: Characteristic Classes - Implement Vector Bundles?

Actually, I get the error: --- AttributeErrorTraceback (most recent call last) in () > 1 det = matrix.determinant(); show(det) /home/michi/GitProjects/sage/local/lib/python2.7/site-packages/sa

[sage-devel] Re: Characteristic Classes - Implement Vector Bundles?

Unfortunately, I noticed that the algorithm of computing the determinant of MixedForm elements doesn't work for matrices of dimension higher than 3 since MixedFormAlgebra isin general not a field. So, is it useful to create a new matrix class for this kind of purpose? If so, how is the matrix i

Re: [sage-devel] Re: Characteristic Classes - Implement Vector Bundles?

Hello, Having vector bundles would be nice! But what do you mean by *abstract* vector bundle? Ah. I meant vector bundles without specifying any maps. But since changes of frames/coordinates and continuations are convenient to have, this seems unavoidable. Where would you start if you'd program

[sage-devel] Characteristic Classes - Implement Vector Bundles?

Hey there, for the next step of implementing characteristic classes, I'd like to implement abstract vector bundles. 1) Do you agree? 2) How would you proceed in doing so? It seems like it's not an easy task at all (at least if you wish having all functionalities). I mean, for characteristic cla

[sage-devel] Re: Scalar Field in Diff Form Algebra? Check fails!

I apologize. The issue was there before (tested on sage 8.6). I open a ticket. Agreed? However, how are beta issues managed? Best regards Michael Am Sonntag, 14. April 2019 10:35:13 UTC+2 schrieb Michael Jung: > > Since 8.8beta1 there is a critical issue regarding scalar fields: >

[sage-devel] Scalar Field in Diff Form Algebra? Check fails!

Since 8.8beta1 there is a critical issue regarding scalar fields: sage: M = Manifold(2, 'M') sage: X. = M.chart() sage: f = M.scalar_field(x, name='f') sage: f in M.diff_form_module(1) --- AttributeError

Re: [sage-devel] Re: Characteristic classes on manifolds

Hello, I changed the status to "needs_review" since the doctests are now complete. :) What are the next steps? Lean back and sip tea? Regards, Michael Am 06.04.19 um 18:54 schrieb Michael Jung: I added a link to a demo notebook in the description of the ticket. Further

Re: [sage-devel] Re: Characteristic classes on manifolds

I added a link to a demo notebook in the description of the ticket. Furthermore, I've encountered another unnice issue (see ticket comments). I'd appreciate when someone knows how to fix it. Best regards Michael Am Mittwoch, 3. April 2019 17:42:34 UTC+2 schrieb Michael Jung: > &

Re: [sage-devel] Re: Characteristic classes on manifolds

ur branch there can be WIP, why not? Best regards, Michael Originalnachricht Betreff: [sage-devel] Re: Characteristic classes on manifolds Von: Eric Gourgoulhon An: sage-devel Cc: Le mardi 2 avril 2019 22:54:51 UTC+2, Michael Jung a écrit : All fine, except the very last line

[sage-devel] Re: Characteristic classes on manifolds

so far - without any errors. Yet, what might explain the very different results? Can you give me a first hint, though not seeing the code? Cheers, Michael Am Montag, 1. April 2019 00:53:06 UTC+2 schrieb Michael Jung: > > Thanks for your interest! :) I started the ticket > <https://trac

[sage-devel] Re: Characteristic classes on manifolds

ra > itself can be one ticket. Feel free to also cc me (by using tscrim) on the > tickets. > > Best, > Travis > > > On Sunday, March 31, 2019 at 4:03:27 AM UTC+10, Michael Jung wrote: >> >> My dear developers, >> right now, I'm working on my master th

Re: [sage-devel] Re: Problem with wedge of unnamed diff forms on non-parall. mfds

Oh yes, the chart is wrongly defined. It should be: |sage: c_xy.=U.chart()| ||obviously. I copied it once, changed the variables, and copied it back changing the variables again. Sorry.| | What are appropriate settings for a ticket regarding this issue? I'm a ticket virgin.| | Am 30.03.201