Re: [sage-devel] Re: bug: factoring symbolic expressions containing exponentials

On Wed, Apr 10, 2019 at 5:28 PM rjf wrote: > > > I suppose this is a Sage bug; Maxima doesn't have a problem with > its factor program. > Indeed. sage: ex=exp(2*x)+exp(-2*x); ex e^(2*x) + e^(-2*x) sage: maxima(ex).factor().sage() (e^(4*x) + 1)*e^(-2*x) sage: bool(maxima(ex).factor().sage()==ex)

[sage-devel] bug: factoring symbolic expressions containing exponentials

sage: sage.version.version '8.6' sage: ex=exp(2*x)+exp(-2*x); ex e^(2*x) + e^(-2*x) sage: factor(ex) 2*e^(2*x) sage: bool(factor(ex)==ex) False sage: bool(factor(e^(2*x)+e^(-2*x))==e^(2*x)+e^(-2*x)) False sage: bool(factor(2^(2*x)+2^(-2*x))==2^(2*x)+2^(-2*x)) True -- You received this message bec

Re: [sage-devel] matrix equality and assumptions

Thanks. On Tue, Apr 9, 2019 at 10:41 AM Jeroen Demeyer wrote: > > On 2019-04-09 16:29, Bill Page wrote: > > Is this a known problem? > > Now it is: https://trac.sagemath.org/ticket/27629 > > -- > You received this message because you are subscribed to the Google G

[sage-devel] matrix equality and assumptions

Is this a known problem? -- sage: sage.version.version '8.6' sage: assume(x,'real') sage: assumptions() [x is real] sage: e1=matrix([[0,-x],[x,0]]); e1 [ 0 -x] [ x 0] sage: e2=transpose(e1);e2 [ 0 x] [-x 0] sage: e1==e2 True sage: e1-e2 [ 0 -2*x] [ 2*x0] sage: e1-e2==0 True -- sage: forget

Re: [sage-devel] jupyter horizontal scrollbar and wrapping of long math output

On 30 May 2017 at 22:09, William Stein wrote: > > On Tuesday, May 30, 2017, Bill Page wrote: >> >> Is the new CoCalc Jupyter interface available in the Docker version? > > Yes! > >> >> If so maybe I should just switch to that. Besides the collaboration

Re: [sage-devel] jupyter horizontal scrollbar and wrapping of long math output

On 30 May 2017 at 22:11, William Stein wrote: > Also you can report this jupyter bug (including input to reproduce) to them > on github. They are good at triaging their issues right now > I was a bit uncertain as to where to report it since I am using --notebook=jupyter in sage. I figured th

[sage-devel] jupyter horizontal scrollbar and wrapping of long math output

I am not sure if this is the right place to ask this question (Perhaps there is a more specific Jupyter developer list?) but I find the following behavior rather annoying: After doing %display typeset if do something that generates some long multi-line Sage output, mathjax seems to do a pretty g

Re: [sage-devel] Jupyter notebook themes

for result. This is exactly what I needed to know but could not find anywhere in the docs. On 30 May 2017 at 15:44, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Do the following to get the list of config paths > > $ sage -sh -c "jupyter --paths" > > Vincent &

[sage-devel] Jupyter notebook themes

Is it possible to use a custom Jupyter css theme in Sage? E.g. https://github.com/powerpak/jupyter-dark-theme How and where would I put the 'custom.css' file? My first attempts to do this where in my user $HOME/.jupyter/custom directory and second was in the 'sage -root' directory /.jupyter/cus

[sage-devel] Typeset output from external packages

Did this used to work? E.g. in a Sage notebook click the [x] Typeset option and then execute: --- %maxima integrate(1/sin(x),x) --- in a cell. My recollection is that this used to use maxima to generate LaTeX and then display it typeset in the worksheet, i.e. the same as --- maxima("integrate(1/(x

[sage-devel] Re: SageMath ArraryFire and afnumpy

OK, thanks. I guess what I would need is some more detailed suggestions for how to debug the problem. Yes, starting with the actual error log is a good idea. To that end I started over from the beginning, keeping a detailed log, but ... Starting with a fresh install and building everything from s

Re: [sage-devel] Re: How to check that something is a real number?

in this case. It also does not make sense to me that the last equality returns True. On 20 September 2016 at 16:29, Emmanuel Charpentier wrote: > > > Le mardi 20 septembre 2016 04:02:16 UTC+2, Bill Page a écrit : >> >> In keeping with Richard's suggestion, in Sage I think

[sage-devel] SageMath ArraryFire and afnumpy

SageMath is a computer algebra system http://www.sagemath.org/ that provides an interface to a large number of open source packages for both symbolic and numeric computations, including especially numpy. But unlike a lot of open source SageMath bundles most of these software packages in a sing

Re: [sage-devel] Re: How to check that something is a real number?

In keeping with Richard's suggestion, in Sage I think a good _algebraic_ definition of 'real' is bool(x/2+conjugate(x)/2 == x) So sage: def RN(x): : try: : return bool(x/2+conjugate(x)/2 == x) : except: : return false which also works whenever conjuga

Re: [sage-devel] Re: ExpressionNice

On 20 August 2016 at 08:54, Bill Page wrote: > > If Sage supported a standard ASCII-art 2-d output format for > expressions, then perhaps another choice would be suitable. > Perhaps I should have said "unicode-art" 2-d output. I noticed that in --notebook=jupyter Sympy do

Re: [sage-devel] Re: ExpressionNice

On 19 August 2016 at 18:30, Bill Page wrote: > ... > Probably the only way to make a sufficient number of people happy > enough to get a positive review on this ticket would be to implement > several major alternative notations for derivatives and an easy way to > switch between

Re: [sage-devel] Re: ExpressionNice

ption along with several other optional formats for the derivative. Bill Page. -- 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+u

Re: [sage-devel] Re: ExpressionNice

On 19 August 2016 at 14:24, Nils Bruin wrote: > On Friday, August 19, 2016 at 9:45:12 AM UTC-7, Bill Page wrote: >> >> My main question is whether we should try to replicate what is done >> by ExpressionNice and thereby render it obsolete or should we try >> to

Re: [sage-devel] Re: ExpressionNice

On the contrary after reading the code for ExpressionNice carefully it is clear that it does not do post-processing as such and should be quite general and robust. However that said, I am very much in favor of using the approach you demonstrated in https://trac.sagemath.org/ticket/21286 My main

Re: [sage-devel] Re: ExpressionNice

ExpressionNice is a subclass of sage.symbolic.expression.Expression, it seemed therefore that maybe I should be able to do something like: sage: import sage.manifolds.utilities sage: sage.symbolic.expression.Expression = sage.manifolds.utilities.ExpressionNice and expect all my expressions to be

Re: [sage-devel] Re: ExpressionNice

On 18 August 2016 at 01:59, Nils Bruin wrote: > On Wednesday, August 17, 2016 at 3:25:31 PM UTC-7, Bill Page wrote: >> >> >> It turns out that a solution is now "hidden away" in plain sight: >> >> https://trac.sagemath.org/ticket/18640 >> >

[sage-devel] ExpressionNice

ease 7.3 as part of above SageManifolds ticket. OK, it is nice to now have ExpressionNice but wouldn't it be even nicer if it did not have such an obscure name and nicer still if it was actually the default output format in Sage? (Of course it would be good to still have the Pynac notation available as

Re: [sage-devel] sage_mode for emacs has display problem in sage 7.4 beta0

On Aug 14, 2016 11:26 AM, "'Martin R' via sage-devel" < sage-devel@googlegroups.com> wrote: > > Can't we undo the ipython 5 thing? It's a major nuisance on the command line, too. > +1 I find the new coloration in the Sage command line in the beta release quite extreme and nearly unreadable in so

Re: [sage-devel] Re: checkout from trac

BTW, is it normal to run 'make' after 'git trac checkout'? I just did that and 'make' seems to be re-building almost everything. On 13 August 2016 at 17:07, Bill Page wrote: > Yes indeed it does! Much appreciated. > > On 13 August 2016 at 17:05, Volker

Re: [sage-devel] Re: checkout from trac

Yes indeed it does! Much appreciated. On 13 August 2016 at 17:05, Volker Braun wrote: > I removed the leading slash from the branch name on that ticket, works now. > > On Saturday, August 13, 2016 at 10:22:55 PM UTC+2, Bill Page wrote: >> >> OK, I thought that might be it (

Re: [sage-devel] Re: checkout from trac

OK, I thought that might be it (although all I really wanted was read-only access), so I ran 'git trac config', see below. But it still fails. I guess it's just not my day ... On 13 August 2016 at 16:13, Volker Braun wrote: > You missed "git trac config" > wspage@sarah ~/sage $ git trac config

Re: [sage-devel] Re: checkout from trac

isting-ticket > > > -leif > >> In particular check out the sections on "Installing the Git-Trac >> Command" and then "Check out an Existing Ticket" >> >> >> >> On Saturday, August 13, 2016 at 6:55:10 PM UTC+2, Bill Page wrote: >

Re: [sage-devel] Re: checkout from trac

Sorry, I'm still confused. What exactly do I have to do to checkout a trac ticket for testing and where is it documented? Google searches only seem to mention --dev. On Aug 13, 2016 12:19 PM, "leif" wrote: Bill Page wrote: > It seems like I am always confused when I try to u

[sage-devel] checkout from trac

It seems like I am always confused when I try to use sagetrac, but I did not expect this: wspage@sarah ~/sage $ ./sage --dev checkout --ticket=21231 sage-run received unknown option: --dev usage: sage [options] Try 'sage -h' for more information. -- What am I doing wrong? I just did wspage@sar

[sage-devel] Equations in jupyter notebook jump from centered to left aligned upon rendering

See this issue: https://github.com/ipython/ipython/issues/7827 I have this annoying behavior in a newly install instance of SageMath 7.2. I would like it to remain centered as in normal "display math" style. In the file: /usr/lib/sagemath/local/lib/python2.7/site-packages/ notebook/static/styl

Re: [sage-devel] incremental migration to github?

On 11 January 2016 at 11:26, William Stein wrote: > > For what it is worth I'm highly supportive of Sage development moving to > github. >... > Anyway what github have accomplished in the last few years is very > impressive. > +1 -- You received this message because you are subscribed to the Go

Re: [sage-devel] is_constant in the SymbolicRing

()).is_constant() but perhaps easily remedied. Bill Page. -- 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 post

Re: [sage-devel] sage octave interface

ne that Octave has returned an error message rather than a result. Maybe looking for >>> would be more reliable? > 4. What is EOF at line 302? > I think this is a possible exception returned by 'expect'. Regards, Bill Page. -- Forwarded message --

[sage-devel] sage octave interface

I am interested in comments and criticism concerning the following work in progress: https://pypi.python.org/pypi/sage_octave Bill Page -- Forwarded message -- From: Bill Page Date: 6 January 2016 at 00:54 Subject: Re: [smc] %octave mode in sage worksheets is flaky simply

[sage-devel] Fwd: [sage-trac] #10295: Upgrading pexpect

Is anyone interested in helping to resolve this old pexpect issue? Dealing with the Sage development process and in particular Sage package management is a bit beyond me but François Bissey created a branch almost 5 months ago with an updated version of pexpect that worked with the version of Sage

Re: [sage-devel] Re: [SPAM: 9.600] Fwd: [sage-trac] #10295: Upgrading pexpect

The version of pexpect with the new option is still a branch called https://github.com/pexpect/pexpect/tree/superfluous-sleep I think they are waiting for us to say that it works with Sage. Sorry, I really dont understand what is required in order to update a branch on git.sagemath.org

Re: [sage-devel] Re: [fricas-devel] Re: categories

Thanks. https://github.com/homalg-project/CAP_project https://github.com/homalg-project/CAP_project/blob/master/CAPManual.pdf On 1 October 2015 at 18:43, Simon King wrote: > PS: > > On 2015-10-01, Bill Page wrote: >> I am very interested in the use of adjunction in progra

Re: [sage-devel] Re: [fricas-devel] Re: categories

he way this was done in Sage but I continue to wish for something both simpler and more ambitious. :) I am very interested in the use of adjunction in programming languages and the definition of types by construction of universals. Perhaps CAP is relevant? Can you provide a reference to a relevant

Re: [fricas-devel] Re: [sage-devel] categories

In FriCAS (1) -> x:Polynomial(Integer) Type: Void (2) -> x + 1/2 1 (2) x + - 2 Type: Polynomial(Fraction(Integer)) On 1 October 2015 at 15:28, 'Bill Hart' via

Re: [fricas-devel] Re: [sage-devel] categories

On 1 October 2015 at 15:10, William Stein wrote: > On Thu, Oct 1, 2015 at 12:00 PM, Bill Page wrote: >> ... Clearly the related? concept of >> "element" is borrowed from category theory - maybe even topos theory? > > Yes, parents and elements are from Magma.

Re: [fricas-devel] Re: [sage-devel] categories

On 1 October 2015 at 14:23, William Stein wrote: > ... > One other impression you have is that categories were just bolted on > by combinatorics people at the end. However, David Kohel and I > actually implemented the first round of category-related stuff in Sage > right at the very, very beginni

Re: [fricas-devel] Re: [sage-devel] categories

On 1 October 2015 at 13:07, William Stein wrote: > On Thu, Oct 1, 2015 at 9:38 AM, Bill Page wrote: >> [Changed thread subject from: Sources of funding - perhaps computer >> manufacturers? ] >> >> What I find hard to swallow is the peculiar mix of "parent",

[sage-devel] categories

e a Julia/Nemo list where this should be continued? Regards, Bill Page. On 1 October 2015 at 10:56, Bill Hart wrote: > > On Thursday, 1 October 2015 16:35:20 UTC+2, Bill Page wrote: > >> >> Unfortunately while I am very much in favor of the category/domain >> approach

Re: [sage-devel] Sources of funding - perhaps computer manufacturers?

On 1 October 2015 at 05:47, Juan Luis Cano wrote: > ... > The situation got better over the years (the IPython notebook was born, then > Anaconda came to scene so I never ever had to recompile NumPy again) and > it's been ages since I last used (and recommended) Sage for any real work. > Perhaps S

Re: [sage-devel] Sources of funding - perhaps computer manufacturers?

On 29 September 2015 at 19:41, Dima Pasechnik wrote: > > cryptographers (some of them can certainly qualify as engineers) use Magma a > lot. > OK. Would you say that Sage is a viable alternative for them? -- You received this message because you are subscribed to the Google Groups "sage-devel

Re: [sage-devel] Sources of funding - perhaps computer manufacturers?

here are quite a few people who seem to be trying to do this with Sage but I am not sure whether Sage is more or less an viable alternative for this purpose than an of the Ma's. When it comes to doing new mathematics the flexibility of Python and the complexity of the Sage development infras

Re: [sage-devel] how should the expression relation test be named?

different semantics. Are you proposing a similar "tristate" logic in Sage? Is there somewhere that I can find "Truth(tm)"? On 25 September 2015 at 02:09, Ralf Stephan wrote: > On Thursday, September 24, 2015 at 8:22:53 PM UTC+2, Bill Page wrote: >> >> What

Re: [sage-devel] how should the expression relation test be named?

What answer should be expected when it is not possible to show that an expression is zero? Would you expect that ex.is_zero() = not(ex.is_nonzero()) ? I suppose that I should expect True or False from bool(ex=0) and False in the case that it cannot be shown to be true. But I am not so sur

Re: [sage-devel] Re: Extremely broad bug in Sage Integral Computations

Just for fun, here is a prettier version of this worksheet on SMC https://cloud.sagemath.com/projects/b04b5777-e269-4c8f-a4b8-b21dbe1c93c6/files/integral2.sagews On 4 June 2015 at 14:29, Bill Page wrote: > On 4 June 2015 at 14:14, Emmanuel Charpentier > wrote: >> Bill, Sagemath clo

Re: [sage-devel] Re: Extremely broad bug in Sage Integral Computations

On 4 June 2015 at 14:14, Emmanuel Charpentier wrote: > Bill, Sagemath cloud complains that your worksheet does not exist. > Sorry. I was cleaning up and deleted it by mistake. Here it is again, thanks to SMC snapshots.. >> >> https://cloud.sagemath.com/projects/b04b5777-e269-4c8f-a4b8-b21dbe1c9

Re: [sage-devel] Re: Extremely broad bug in Sage Integral Computations

On 4 June 2015 at 09:21, kcrisman wrote: > >> 1. anyone who believes that sqrt(x^2) is |x| is mistaken. As Bill Page >> says, there are two values. > > Ah, the old 'function versus expression' debate. I really missed that. > It is not clear to me what th

Re: [sage-devel] Extremely broad bug in Sage Integral Computations

On 2 June 2015 at 13:26, Gregory Bard wrote: > > Consider the integral of sqrt( cot(x)^2 ). I think we can all agree that > > sqrt( cot(x)^2 ) = abs( cot (x) ) =/= cot(x) > > ... That is probably exactly where the disagreement starts since sqrt can be considered a "multi-valued function" and one

Re: [sage-devel] Re: Extremely broad bug in Sage Integral Computations

Yes. https://cloud.sagemath.com/projects/b04b5777-e269-4c8f-a4b8-b21dbe1c93c6/files/integral.sagews On 3 June 2015 at 13:31, Samuel Lelievre wrote: > Can fricas do this integral? > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubsc

[sage-devel] fricas.eval() in Sage Notebook tries to start Axiom instead of FriCAS

In SageMath verison 6.6 command line it works as expected: wspage@suse:~/sage> ./sage ┌┐ │ SageMath Version 6.6, Release Date: 2015-04-14 │ │ Type "notebook()" for the browser-based notebook interface.│

[sage-devel] password reset at http://trac.sagemath.org/

Is it working? I tried to reset my password. sage-trac sent me an email with a new one but it does seem to work. Anybody try this lately? -- Forwarded message -- From: sage-trac Date: 8 May 2015 at 17:30 Subject: [Sage] Trac password reset for user: bpage To: bill.p...@newsynthe

Re: [sage-devel] Unicode in Sage Worksheets

On 7 May 2015 at 22:29, François Bissey wrote: > Pushed a branch at http://trac.sagemath.org/ticket/10295 we can continue > the work there. > OK, thanks. > > On 05/08/15 14:22, François Bissey wrote: >> >> Unfortunately, the notebook is still broken with newer pexpect. If you >> try: >> g=sin(x)

Re: [sage-devel] Unicode in Sage Worksheets

On 7 May 2015 at 21:37, François Bissey wrote: > Looks like I would want this single commit. > https://github.com/pexpect/pexpect/commit/aac5897aa12daf056b8fe08f1b6512d9f60c2d27 > The branch seems otherwise strangely stale (210 commits > behind master). Yes. I suppose that branch 3.x is (more or

Re: [sage-devel] Unicode in Sage Worksheets

xpect.spawn(cmd, logfile=self.__logfile, > env=pexpect_env) > File "/usr/lib64/python2.7/site-packages/pexpect/__init__.py", line > 493, in __init__ > fd = sys.__stdin__.fileno() > ValueError: I/O operation on closed file > > this particular failure is

Re: [sage-devel] Re: Unicode in Sage Worksheets

On 6 May 2015 at 23:28, leif wrote: > Bill Page wrote: >> Is there a possibility of creating an experimental package to install >> pexpect 3.3 ? > > mkdir foo-1.0 > > echo 'print "Installing foo.."' > foo-1.0/setup.py > > tar czf foo-1.0.

Re: [sage-devel] Re: Unicode in Sage Worksheets

Is there a possibility of creating an experimental package to install pexpect 3.3 ? I see references to "doctests failing" but no details. It would be good to make this easier to test. On 6 May 2015 at 22:41, leif wrote: > Bill Page wrote: >> After reading t

Re: [sage-devel] Unicode in Sage Worksheets

should be more details. > > François > >> On 7/05/2015, at 13:55, Bill Page wrote: >> >> After reading the docs: >> >> http://pexpect.readthedocs.org/en/latest/index.html >> >> It seems that version 3 and later are supposed to handler unicode >>

Re: [sage-devel] Re: Unicode in Sage Worksheets

After reading the docs: http://pexpect.readthedocs.org/en/latest/index.html It seems that version 3 and later are supposed to handler unicode properly. Version 3.3 requires Python 2.6 or later. Since Sage is already at Python 2.7 is there a good reason why Sage is still using an older version o

[sage-devel] Fwd: Unicode in Sage Worksheets

this specific to just those interfaces that can support unicode? -- Forwarded message -- From: Bill Page Date: 5 May 2015 at 23:02 Subject: Re: Unicode in Sage Worksheets To: sage-cl...@googlegroups.com As suggested here: http://sourceforge.net/p/pexpect/bugs/28/ the following

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 21:45, kcrisman wrote: > Bill Page wrote: >> It just occurred to me that for such >> simple things there should be simple solutions. And I guess there is: > > Well, that has been discussed a lot. There *is* one possibility now - you > can open

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 16:06, William Stein wrote: > On Thu, Apr 30, 2015 at 12:34 PM, Bill Page > wrote: >> ... > You stated 'that the Sage developer emphasis on "doc tests" has > resulted in any fewer errors or problems in Sage in comparison to > other

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 13:29, Dima Pasechnik wrote: > On Thursday, 30 April 2015 18:12:00 UTC+1, Bill Page wrote: >> >> I just tested the patch and now I get the following in a Sage worksheet on >> SMC: >> >> axiom.eval(")version") >> >> '

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 13:34, Dima Pasechnik wrote: > On Thursday, 30 April 2015 17:11:39 UTC+1, Bill Page wrote: > ... > well, for rants we have a special newsgroup called sage-flame. > Yes, although I consider what I wrote more of an inconvenient statement of fact so maybe I used t

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

uot;Axiom Axiom (May 2012) built on Friday July 25, 2014 at 23:34:17 "\r\n' %axiom )version Value = "Axiom Axiom (May 2012) built on Friday July 25, 2014 at 23:34:17 " -- This looks correct with the patch. On 30 April 2015 at 11:59, Bill Page wrote: > On 30 April 2015 a

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 05:29, Dima Pasechnik wrote: > On Thursday, 30 April 2015 10:09:55 UTC+1, Dima Pasechnik wrote: >> On Wednesday, 29 April 2015 23:17:19 UTC+1, Bill Page wrote: >>> >>> > PPS. if you really are pressed for time, I can submit this patch >>&

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 30 April 2015 at 05:29, Dima Pasechnik wrote: > ... >> >> I thought that on SMC in a Sage worksheet you can do %axiom >> and this will call a system-wide Axiom. Currently SMC is hanging for me, >> so I can't check. > > > OK, one can start axiom in an SMC terminal, by typing axiom > it is > (1)

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On Apr 29, 2015 7:30 AM, "Dima Pasechnik" wrote: >> > >> > this patch should go into Sage proper, as it also fixes the same as with SMC >> > issue with Sage's notebook. >> > >> >> Sure. What is the best way to make that happen? > > the usual way is via trac.sagemath.org > (for instance using git

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 23:52, Dima Pasechnik wrote: > > On Tuesday, 28 April 2015 02:27:21 UTC+1, Bill Page wrote: >> >> Yes you are right. The problem was in the original axiom.py. Here is a >> patch that corrects the problem: >> >> htt

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 12:31, Dima Pasechnik wrote: > ... > On Monday, 27 April 2015 17:23:50 UTC+1, Bill Page wrote: >> >> On the original point of this thread: Is there anything wrong with >> just grabbing the 'fricas.py' source from somewhere, changing it, &g

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 12:00, William Stein wrote: > ... > SMC won't be able to provide that sort of hosting for free, that's for sure. > >> I think new projects will have enough room. > > As of right now they do. However, I have to move everything out of > UW asap, so I can't promise anything at al

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 10:31, Bill Page wrote: > On 27 April 2015 at 10:23, Dima Pasechnik wrote: >> >> On Monday, 27 April 2015 15:00:30 UTC+1, Bill Page wrote: >>> ... >>> What's a good way to debug the fricas interface in SageMathCloud? Can >>&

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 10:23, Dima Pasechnik wrote: > > On Monday, 27 April 2015 15:00:30 UTC+1, Bill Page wrote: >> ... >> What's a good way to debug the fricas interface in SageMathCloud? Can >> I just copy and then import the code into a worksheet? I.e. avoid >

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 27 April 2015 at 00:20, William Stein wrote: > On Sun, Apr 26, 2015 at 7:49 PM, Bill Page wrote: >> >> OK, thanks. Any pointers to documentation of "modes" in the Sage >> worksheet would be fine too. > > There's no documentation yet. However, you

Re: [sage-cloud] Re: [sage-devel] Typeset output in non-Sage modes in Sage Notebook

On 26 April 2015 at 20:49, William Stein wrote: > On Sun, Apr 26, 2015 at 5:40 PM, Bill Page wrote: > ... >> Is there a way to tell the worksheet to render code >> between $$ ... $$ as MathJax or have MathML markup rendered by >> the browser instead of being treated si

[sage-devel] Typeset output in non-Sage modes in Sage Notebook

For example, if I start a cell with %fricas or %maxima the result is formatted by the external program and displayed as preformatted ascii text. Some external programs can generate LaTeX or MathML code. Is there a way to tell the worksheet to render code between $$ ... $$ as MathJax or have M

Re: [sage-devel] Re: Bug in abs(I*x).diff(x)

I am still working on this in FriCAS and currently have an operational version 0.2. Although this is the Sage list, I would be glad to continue the discussion and especially with someone willing to review what I have developed so far in FriCAS. I think I now understand all this a bit better than I

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 26 November 2014 at 12:58, Ondřej Čertík wrote: > On Wed, Nov 26, 2014 at 10:17 AM, Bill Page > wrote: >> >> Does it help if a say the operations are defined "symbolically"? > > All I want is if you can give me an algorithm of your approach > in

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 25 November 2014 at 15:14, Erik Massop wrote: > On Tue, 25 Nov 2014 13:30:33 -0500 > Bill Page wrote: > >> On 25 November 2014 at 01:11, Ondřej Čertík wrote: >> > On Mon, Nov 24, 2014 at 10:23 PM, Bill Page >> > wrote: > ... >> >> But I do

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 25 November 2014 at 14:51, Ondřej Čertík wrote: > On Tue, Nov 25, 2014 at 11:30 AM, Bill Page > wrote: ... >>>> Try it this way: >>>> >>>> a*b = exp(?1) >>>> a = exp(?2) >>>> b = exp(?3) >>>> >>>

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 25 November 2014 at 01:11, Ondřej Čertík wrote: > On Mon, Nov 24, 2014 at 10:23 PM, Bill Page > wrote: >> ... >> I am not very interested in real numbers. I am interested in the >> algebra. Would you say that >> >> sqrt(x^2).diff(x) = sqrt(x^2)/x &g

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 24 November 2014 at 17:43, Ondřej Čertík wrote: > On Mon, Nov 24, 2014 at 1:57 PM, Bill Page wrote: > ... >> >> In FriCAS 'abs' is already a kernel function and it implemented the >> derivative of 'abs' even before my proposed patch but I think t

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 22 November 2014 at 12:34, Ondřej Čertík wrote: > On Sat, Nov 22, 2014 at 7:23 AM, Bill Page wrote: >> ... >> FriCAS currently does not implement a symbolic 'conjugate' operator. >> The issue concerns whether adding 'conjugate' is a good idea and

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 21 November 2014 at 20:18, Ondřej Čertík wrote: > On Fri, Nov 21, 2014 at 9:37 AM, Bill Page wrote: >> >> You are right about the derivative. But my limited understanding >> is that the strategy is not to avoid 'abs(x)' but rather to avoid 'sin'. >

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 21 November 2014 at 20:18, Ondřej Čertík wrote: > > I am still confused about one thing: is this issue is already > present in FriCAS before your changes? Because you can > already use conjugate, sin, +, *, ..., even without defining the > derivative for abs(x). I fail to see how defining the a

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 20 November 2014 22:08, Ondřej Čertík wrote: > On Thu, Nov 20, 2014 at 7:53 PM, Bill Page wrote: > ... >> This problem can be reduced to finding an algorithm to determine >> if f(x) is everywhere non-negative. Richardson proves that no such >> algorithm exists. >

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 20 November 2014 12:56, Ondřej Čertík wrote: > ... > Can you give an example of an expression that cannot be decided by > the Richardson's theorem? Well, no not exactly. Richardson's theorem is not about individual expressions, it is about decidability, i.e. computability, in general. Conside

Re: [sage-devel] Bug in abs(I*x).diff(x)

Perhaps this is more or less where Richardson's theorem enters. http://en.wikipedia.org/wiki/Richardson%27s_theorem We badly want a reliable way to determine when an expression is identically zero. In general this is not possible, but if we restrict our selves to a subset of "elementary" function

Re: [sage-devel] Bug in abs(I*x).diff(x)

ink? Bill. On 20 November 2014 09:41, Bill Page wrote: > ... > > I had a thought. I suppose that all non-analytic (nonholomorphic) functions of interest can be written in terms of conjugate and some analytic functions, e.g. > > abs(x)=sqrt(x*conjugate(x)) > > so perhaps al

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 20 November 2014 01:54, Ondřej Čertík wrote: > > What you posted looks good. But we need to test it for arg(z), re(z), > im(z) and any other non-analytic function that we can find. > (1) -> re(x)==(conjugate(x)+x)/2 Type: Void

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 19 November 2014 21:23, kcrisman wrote: > > >> Since this mostly concerns FriCAS I am cross posting to that group. I will >> also post the patch there. For FriCAS list reference the original email >> thread is here: >> > > But if you come up with a solution Sage (or Ginac, or whatever) can

Re: [sage-devel] Bug in abs(I*x).diff(x)

ion(Integer) (11) -> D(abs(x)^2,x) _ (11) x + x Type: Expression(Integer) Bill. On 19 November 2014 11:51, Ondřej Čertík wrote: > > On Wed, Nov 19, 2014 at 9:42 AM, Ondřej Čertík wrote: > > On Wed, Nov 19, 2014 at 9:32 A

Re: [sage-devel] Bug in abs(I*x).diff(x)

2xxabs(log(x)) Type: Expression(Integer) On 19 November 2014 10:19, Bill Page wrote: > > On 2014-11-19 9:36 AM, "Bill Page" wrote: > > ... > > Then I noticed that if we have f=z we get > > > > conjugate(z).diff(z) > > &

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 2014-11-19 9:36 AM, "Bill Page" wrote: > ... > Then I noticed that if we have f=z we get > > conjugate(z).diff(z) > > which is 0. So the 2nd term is 0 and the result is just the first Wirtinger derivative. > > Perhaps I am misinterpreting something? >

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 21:22, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 6:51 PM, Bill Page wrote: >> On 18 November 2014 17:40, Ondřej Čertík wrote: >>> >>> In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) / >>> d conjugate(z). The

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 17:40, Ondřej Čertík wrote: > > In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) / > d conjugate(z). The Df(z) / Dz is the complex derivative taking in > direction theta (where it could be theta=0). Given the chain rule, as > I derived above using chain rules

Re: [sage-devel] Bug in abs(I*x).diff(x)

On 18 November 2014 15:19, Ondřej Čertík wrote: > On Tue, Nov 18, 2014 at 12:14 PM, Bill Page > wrote: >> >> abs(x).diff(x) >> >> would return the symbolic expression >> >> conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta} &

  1   2   3   4   >