[sage-devel] Re: Feature request: Flatpak

On Sunday, April 25, 2021 at 1:53:03 PM UTC-5 Samuel Lelievre wrote: Marc Culler's SageMath-macOS app could provide inspiration for that. After having done some research on this, my preference would be to package Sage as an AppImage, and I have plans for doing that. An AppImage needs to be

Re: [sage-devel] Re: Feature request: Flatpak

On Sun, Feb 9, 2025 at 11:30 AM Jerry Caligiure wrote: > > Hello! I'd really like to get this working on flatpak. I'm trying to sandbox > off applications from the system in Linux, and flatpak is an easy way to do > that. > I'm thinking we could use electron (https://www.electronjs.org/) to crea

[sage-devel] Re: Feature request: Flatpak

Hello! I'd really like to get this working on flatpak. I'm trying to sandbox off applications from the system in Linux, and flatpak is an easy way to do that. I'm thinking we could use electron (https://www.electronjs.org/) to create a gui if needed, but like stated previously you don't *need* a

[sage-devel] Re: Feature request: Flatpak

2021-04-18 08:17:31 UTC, Volker Braun: > flatpak is designed for gui apps, registering a desktop icon and so on. To really make use of it we'd need at least a small gui app that then lets you start/stop the jupyter server and/or launch browser windows. Marc Culler's SageMath-macOS app could p

[sage-devel] Re: Feature request: Flatpak

Flatpak actually can handle CLI-only apps: for example, see mosh or appstream-glib . They are hidden on the Flathub website, and that is by design

[sage-devel] Re: Feature request: Flatpak

flatpak is designed for gui apps, registering a desktop icon and so on. To really make use of it we'd need at least a small gui app that then lets you start/stop the jupyter server and/or launch browser windows. If you just want to run Sage then there is already a one-liner podman / docker com

[sage-devel] Re: feature request: store additional information about symbolic variables

For the record, I found a way that works for me quite well now: udict = {} cdict = {} docdict = {} def var2(name,doc='',units='',domain1='real',latexname='',value = -1234): ''' Creates a symbolic variable in the given domain (standard:'real') and with the given latexname. Further, it

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 21, 7:09 am, Stan Schymanski wrote: > sage: var('T_a') > or > sage: T_a = var('T_a') > > but William's example does not work if I do > sage: var2('T_a', 'Air temperature (K)') > ?? You're well underway with the question-marks, but instead of writing them on a separate line in an email you

[sage-devel] Re: feature request: store additional information about symbolic variables

Thanks, Nils! The following question probably belongs to sage-support, but it is directly related: It does not seem to make a difference whether I do sage: var('T_a') or sage: T_a = var('T_a') but William's example does not work if I do sage: var2('T_a', 'Air temperature (K)') instead of sage

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 20, 12:36 am, Stan Schymanski wrote: > Since this is done in the units package already, is there a way to > formally save the units of e.g. T_a as units.temperature.Kelvin and then > have something like: > sage: T_a = 300 > sage: T_a > 300 Kelvin You can of course write T_a=300*units.tempe

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 20, 12:36 am, Stan Schymanski wrote: > That's awesome, thanks a lot, William! > > Since this is done in the units package already, is there a way to > formally save the units of e.g. T_a as units.temperature.Kelvin and then > have something like: > sage: T_a = 300 > sage: T_a > 300 Kelvin >

[sage-devel] Re: feature request: store additional information about symbolic variables

That's awesome, thanks a lot, William! Since this is done in the units package already, is there a way to formally save the units of e.g. T_a as units.temperature.Kelvin and then have something like: sage: T_a = 300 sage: T_a 300 Kelvin Cheers Stan On 19/09/11 17:09, William Stein wrote: .

Re: [sage-devel] Re: feature request: store additional information about symbolic variables

On Mon, Sep 19, 2011 at 4:14 AM, Stan Schymanski wrote: > Dear Simon, Richard, Nils and Maarten, > > Thanks for putting so much thought into it. Unfortunately, most of what you > are discussing is way beyond my horizon, so I can't really contribute. I had > no clue how many things need to be consi

[sage-devel] Re: feature request: store additional information about symbolic variables

Dear Simon, Richard, Nils and Maarten, Thanks for putting so much thought into it. Unfortunately, most of what you are discussing is way beyond my horizon, so I can't really contribute. I had no clue how many things need to be considered before implementing my request. I just wanted to confi

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi Richard, On 17 Sep., 20:09, rjf wrote: > Data need not be stored in random access memory.  A disk file might be > quite adequate, > since documentation presumably is not needed in a hurry, nor is it > needed in huge > quantities. I think the application Stan had in mind was indeed to add docu

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 17, 10:17 am, Simon King wrote: > Hi! > > On 17 Sep., 18:15, rjf wrote: > > > \begin{sarcasm} > > I'm sure glad that python/sage is so easy to read. > > \end{sarcasm} > > Yeah, I know that kind of sarcasm from my 15 year old son. > > > I was suggesting the use of STRINGS as indexes. > >

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi! On 17 Sep., 18:15, rjf wrote: > \begin{sarcasm} > I'm sure glad that python/sage is so easy to read. > \end{sarcasm} Yeah, I know that kind of sarcasm from my 15 year old son. > I was suggesting the use of STRINGS as indexes. Do I understand correctly: You suggest to use the name of a glob

[sage-devel] Re: feature request: store additional information about symbolic variables

\begin{sarcasm} I'm sure glad that python/sage is so easy to read. \end{sarcasm} I don't see what is going on, so I am guessing that you are doing something different. I was suggesting the use of STRINGS as indexes. Now it is possible that the same name, i.e. string would have different meanings

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi! In the last few minutes, I hacked something that provides the following: sage: ZZ.set_custom_doc('I like this text better.') sage: ZZ? Type: IntegerRing_class Base Class: String Form:Integer Ring Namespace: Interactive File: /mnt/local/king/SAG

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi Maarten! On 17 Sep., 10:39, Maarten Derickx wrote: > Note that there are also weak referenced versions of dictionairy so the > memory leak can be solved easily. No, it can't. For the approach to work generally, for *any* object O, it is not possible to use O *itself* as (weak) key of a dicti

[sage-devel] Re: feature request: store additional information about symbolic variables

Note that there are also weak referenced versions of dictionairy so the memory leak can be solved easily. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi Nils, On 16 Sep., 20:17, Nils Bruin wrote: > Reasonable options. For me, "...?" is an *introspection* tool, so it > helps me seeing what things look like to sage. Not always. For example: If you have a cached method (such as groebner_basis of multivariate polynomial ideals) then you want to s

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi Simon, Reasonable options. For me, "...?" is an *introspection* tool, so it helps me seeing what things look like to sage. Making its output configurable would detract from its use in that sense (now I have to worry about the fact that the particular object I'm viewing might be distorting my vi

[sage-devel] Re: feature request: store additional information about symbolic variables

Hi Stan, On 16 Sep., 11:25, Stan Schymanski wrote: > On Sep 16, 6:57 am, rjf wrote: > > > Another way is to establish a storage structure, e.g. hashtable, > > indexed file, etc > > to store all the documentation strings with the object names as keys. > > > Essentially  ?variablename = doctable["

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 16, 6:57 am, rjf wrote: > Another way is to establish a storage structure, e.g. hashtable, > indexed file, etc > to store all the documentation strings with the object names as keys. > > Essentially  ?variablename = doctable["variablename"]/ Currently, I store the units information about

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 15, 9:01 am, Nils Bruin wrote: > ... > One way of establishing this feature is by having "custom docstrings" > on objects. Another way is to establish a storage structure, e.g. hashtable, indexed file, etc to store all the documentation strings with the object names as keys. Essentiall

[sage-devel] Re: feature request: store additional information about symbolic variables

On Sep 15, 6:02 am, Stan Schymanski wrote: > Would it be possible to formalise > this somehow, so that I could then type the name of the variable > further down in the document followed by a question mark to see that > information again? One way of establishing this feature is by having "custom d

[sage-devel] Re: Feature Request: Intersection of number fields

On Jan 17, 12:16 am, Ben Linowitz wrote: > Sorry about that. I was thinking of the number fields as being > subfields of C by definition. What if each of the number fields came > with a specified embedding into C? > > Ben I am not sure for the case of embeddings into C, I would compute a common

[sage-devel] Re: Feature Request: Intersection of number fields

Sorry about that. I was thinking of the number fields as being subfields of C by definition. What if each of the number fields came with a specified embedding into C? Ben On Jan 16, 5:55 pm, John Cremona wrote: > [I am cc-ing sage-nt.] > > Without extra infromation, such as an embedding of each

[sage-devel] Re: Feature request for sagetex

Dan Drake wrote: > ? Hmm, that might hard. I'm not sure how to do that. Right now, when you > do \sage{diff(sin(x), x)}, it runs something like > > latex(diff(sin(x), x)) > > and I don't know how to tell latex() to not fully evaluate the diff(). This is an oft-discussed subject (and oft-re

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

+1 for including this function... I had made the same one, but mine is actually 5 times slower than the one proposed in trac 6245 :P Is it possible to not name it "hadamard_product"? Coming from MatLab, I've used it hundreds of time, but I would have never recognized that "hadamard_product" could

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Mon, Jun 15, 2009 at 8:39 PM, Jason Grout wrote: > > William Stein wrote: >> On Mon, Jun 15, 2009 at 7:34 PM, Jason Grout >> wrote: >>> Bill Hart wrote: Can I ask what applications this "Hadamard product" has? >> >> I've never used it, but I guess it must be really really important in >>

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Jun 15, 10:34 am, Jason Grout wrote: > Also, a google search for hadamard product applications turns up > http://buzzard.ups.edu/courses/2007spring/projects/million-paper.pdf > (maybe Rob Beezer knows this person?) Elizabeth Million was a student in a course of mine a few years ago and this w

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

Jason Grout wrote: > William Stein wrote: >> On Mon, Jun 15, 2009 at 7:34 PM, Jason Grout >> wrote: >>> Bill Hart wrote: Can I ask what applications this "Hadamard product" has? >> I've never used it, but I guess it must be really really important in >> numerical computation, since most shoc

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

William Stein wrote: > On Mon, Jun 15, 2009 at 7:34 PM, Jason Grout > wrote: >> Bill Hart wrote: >>> Can I ask what applications this "Hadamard product" has? > > I've never used it, but I guess it must be really really important in > numerical computation, since most shockingly it is the *defaul

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

William Stein wrote: > On Mon, Jun 15, 2009 at 7:34 PM, Jason Grout > wrote: >> Bill Hart wrote: >>> Can I ask what applications this "Hadamard product" has? > > I've never used it, but I guess it must be really really important in > numerical computation, since most shockingly it is the *defaul

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Mon, Jun 15, 2009 at 7:34 PM, Jason Grout wrote: > > Bill Hart wrote: >> Can I ask what applications this "Hadamard product" has? I've never used it, but I guess it must be really really important in numerical computation, since most shockingly it is the *default* for A*B in numpy!! sage: imp

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

Bill Hart wrote: > Can I ask what applications this "Hadamard product" has? (Tim: The term is from linear algebra) http://en.wikipedia.org/wiki/Matrix_multiplication#Hadamard_product says it is used in JPG compression, for example. http://planetmath.org/encyclopedia/HadamardProduct.html Also,

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Jun 15, 2009, at 1:14 PM, Bill Hart wrote: > > Can I ask what applications this "Hadamard product" has? > > Bill. I've never heard it called that, but element-wise multiplication is useful for tensors. Cheers, Tim. --- Tim Lahey PhD Candidate, Systems Design Engineering University of Wate

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

Can I ask what applications this "Hadamard product" has? Bill. On 15 June, 17:32, William Stein wrote: > On Mon, Jun 15, 2009 at 6:17 PM, John Cremona wrote: > > > 2009/6/15 Jason Grout : > > >> William Stein wrote: > >>> On Mon, Jun 15, 2009 at 5:26 PM, paramaniac > >>> wrote: > > Sorry,

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Mon, Jun 15, 2009 at 6:17 PM, John Cremona wrote: > > 2009/6/15 Jason Grout : >> >> William Stein wrote: >>> On Mon, Jun 15, 2009 at 5:26 PM, paramaniac wrote: > Sorry, I don't understand your example. > If > A1 = matrix([[a1,b1],[c1,d1]]) > A2 = matrix([[a2,b2],[c2,d2]]) >

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

2009/6/15 Jason Grout : > > William Stein wrote: >> On Mon, Jun 15, 2009 at 5:26 PM, paramaniac wrote: Sorry, I don't understand your example. If A1 = matrix([[a1,b1],[c1,d1]]) A2 = matrix([[a2,b2],[c2,d2]]) then >>> A1.*A2 = matrix([[a1*a2, b1*b2],[c1*c2, d1*d2]]) >>> >>

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

William Stein wrote: > On Mon, Jun 15, 2009 at 5:26 PM, paramaniac wrote: >>> Sorry, I don't understand your example. >>> If >>> A1 = matrix([[a1,b1],[c1,d1]]) >>> A2 = matrix([[a2,b2],[c2,d2]]) >>> then >> A1.*A2 = matrix([[a1*a2, b1*b2],[c1*c2, d1*d2]]) >> > > (1) we aren't going to add the .*

[sage-devel] Re: Feature Request: element-wise multiplication of

> (1) we aren't going to add the .* notation A1 .* A2 to sage, since > there has to be a *very* very strong +1 to not adding this. > (2) I would love to add a fast optimized function that does multiply > component wise. This is now http://trac.sagemath.org/sage_trac/ticket/6301 Nick --~--~---

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

On Mon, Jun 15, 2009 at 5:26 PM, paramaniac wrote: > >> Sorry, I don't understand your example. >> If >> A1 = matrix([[a1,b1],[c1,d1]]) >> A2 = matrix([[a2,b2],[c2,d2]]) >> then > > A1.*A2 = matrix([[a1*a2, b1*b2],[c1*c2, d1*d2]]) > (1) we aren't going to add the .* notation A1 .* A2 to sage, sin

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

> Sorry, I don't understand your example. > If > A1 = matrix([[a1,b1],[c1,d1]]) > A2 = matrix([[a2,b2],[c2,d2]]) > then A1.*A2 = matrix([[a1*a2, b1*b2],[c1*c2, d1*d2]]) Regards, Lukas --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegr

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

paramaniac wrote: > Dear Sage Developers, > > It would be very nice if Sage supported the element-wise > multiplication of matrices like the .* operator in Octave/Matlab. > I was about to point out the recent thread about this, but then realized it was you that started that thread and acknowl

[sage-devel] Re: Feature Request: element-wise multiplication of matrices

Sorry, I don't understand your example. If A1 = matrix([[a1,b1],[c1,d1]]) A2 = matrix([[a2,b2],[c2,d2]]) then A1.*A2 = On Mon, Jun 15, 2009 at 10:52 AM, paramaniac wrote: > > Dear Sage Developers, > > It would be very nice if Sage supported the element-wise > multiplication of matrices lik

[sage-devel] Re: feature request

On Apr 23, 4:36 am, Flavio Coelho wrote: > Thanks Michael, Hi Flávio, > I was really referring to multiprocessing, since their APIs are not > the same and  pyprocessing isn't supported anymore. Multiprocessing is > maintained to be fully compatible with the 2.6 module to help with > forward c

[sage-devel] Re: feature request

Thanks Michael, I was really referring to multiprocessing, since their APIs are not the same and pyprocessing isn't supported anymore. Multiprocessing is maintained to be fully compatible with the 2.6 module to help with forward compatibility. So I guess the answer to my question is that Multip

[sage-devel] Re: feature request

On Apr 22, 8:09 am, William Stein wrote: > On Wed, Apr 22, 2009 at 6:10 AM, Flavio Coelho wrote: > > > Hi, > > > is it too late to include the multiprocessing package into sage > > 3.4.1? > > No, since we included it in Sage a year ago: While we ship pyprocessing we should really consider upg

[sage-devel] Re: feature request

On Wed, Apr 22, 2009 at 6:10 AM, Flavio Coelho wrote: > > Hi, > > is it too late to include the multiprocessing package into sage > 3.4.1? No, since we included it in Sage a year ago: teragon:~ wstein$ sage -- | Sage Version 3.

[sage-devel] Re: Feature Request/Talk Feedback

On 11/1/07, Martin Albrecht <[EMAIL PROTECTED]> wrote: > Usually, if we choose an implementation for a particular functionality, we try > to make sure to always pick the best implementation available. However, this > choice only applies to those systems we ship (singular, gap, pari ...) and > not

[sage-devel] Re: Feature Request/Talk Feedback

That's exactly the sort of use which I had in mind. There is a possible danger that if lots of papers cite Sage for the computations (which of course we hope they will do), when the "hard" part of the computation was done in one of the component packages, then the writers of that package might fe

[sage-devel] Re: Feature Request/Talk Feedback

John Cremona wrote: > This doesn't exactly answer your question, but I think it would be > useful (or at least interesting) if setting some global flag would > cause Sage to report which external (or internal 3rd party) packages > were used in reaching a result. But perhaps that is unrealistic si

[sage-devel] Re: Feature Request/Talk Feedback

This doesn't exactly answer your question, but I think it would be useful (or at least interesting) if setting some global flag would cause Sage to report which external (or internal 3rd party) packages were used in reaching a result. But perhaps that is unrealistic since a long computation might

[sage-devel] Re: Feature request

See Trac #267, IIRC. Nick On Feb 23, 2:58 pm, "Nick Alexander" <[EMAIL PROTECTED]> wrote: > I'm touching various parts of clone, so I'll add this to my TODO > list. If you make a trac and assign it to me, it will more likely get > done. > > Nick > > On Feb 23, 4:08 am, "Robert Miller" <[EMAIL P

[sage-devel] Re: Feature request

I'm touching various parts of clone, so I'll add this to my TODO list. If you make a trac and assign it to me, it will more likely get done. Nick On Feb 23, 4:08 am, "Robert Miller" <[EMAIL PROTECTED]> wrote: > In the command line, I can do > > $ sage -b branch > > to build the branch, and > >