Re: [sage-devel] Re: What are we unable to do right now ?
Hi, Le 05/12/2014 21:45, maldun a écrit : I agree with you that it is not that important as it was some years ago. Nevertheless be aware that many professional users in engineering and research can't go online that simply, because of security reasons, and company policies (I know that from first hand), and they are a big market which we should not underestimate. There's a point to be made that a professional user in engineering and research which doesn't have access to anything else that windows is a rare species facing extinction! Snark on #sagemath -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
Hi, If I read this: http://en.wikipedia.org/wiki/Risch_algorithm I understand that : f=x/(sqrt(x^4+10*x^2-96*x-71)) has an anti-primitive. I do not have maple, so I do nt know if Maple can integrate it; bur sage cannot: f=x/(sqrt(x^4+10*x^2-96*x-71)) integral(f,x) integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x) t. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout. attachment: tdumont.vcf
[sage-devel] Trac problem again?
Hi! Since yesterday evening (middle European time) I try to do git trac push for #15820. It fails, and as usual it gives no error message. Is that a problem on my side (if so: How to track it down?), or is something wrong with trac? Cheers, Simon -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Let's encrypt
Hello devs, I hope someone here knows how the certificate system works for https connections. I am raising this question because of the Let's Encrypt announcement [1] made by EFF last month. It would make it easier to recommend the secure mode for the sage notebook. Currently, all browsers give a big fat warning if the notebook is started in secure mode. [1] https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web Cheers, basu. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
El sábado, 6 de diciembre de 2014 09:57:09 UTC+1, tdumont escribió: Hi, If I read this: http://en.wikipedia.org/wiki/Risch_algorithm I understand that : f=x/(sqrt(x^4+10*x^2-96*x-71)) has an anti-primitive. I do not have maple, so I do nt know if Maple can integrate it; bur sage cannot: f=x/(sqrt(x^4+10*x^2-96*x-71)) integral(f,x) integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x) t. As mentioned by Martin R in other comments, FriCAS can find the primitive of that expresion in terms of elementary functions. I have just checked that Wolphram Alpha can't do it, and a quite old version of Maple that i have just checked gives the answer in terms of elliptic integrals. If FriCAS is right now the best software for computing these kind of integrals, it might be worth the effort to include it as standard package, write a good interface and adapt the integrate methods to use it, at least as a fallback option. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Let's encrypt
I hope someone here knows how the certificate system works for https connections. I am raising this question because of the Let's Encrypt announcement [1] made by EFF last month. It would make it easier to recommend the secure mode for the sage notebook. Currently, all browsers give a big fat warning if the notebook is started in secure mode. [1] https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web Thanks for this! These warnings are a hint that HTTPS (and other uses of TLS/SSL https://en.wikipedia.org/wiki/Transport_Layer_Security) is dependent on a horrifyingly complex and often structurally dysfunctional bureaucracy for authentication. But presumably still requires manual intervention? -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
On Saturday, December 6, 2014 11:59:14 AM UTC+1, mmarco wrote:
If FriCAS is right now the best software for computing these kind of
integrals, it might be worth the effort to include it as standard package,
write a good interface and adapt the integrate methods to use it, at least
as a fallback option.
The interface already exists:
sage: fricas('3 * 5')
...
TypeError: unable to start fricas because the command 'fricas -nox -noclef'
failed
$ ./sage -i fricas
...
Error installing package fricas-0.3.1
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
/home/ralf/sage/logs/pkgs/fricas-0.3.1.log
http://trac.sagemath.org/ticket/9465
Regards,
--
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 to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
On 5 December 2014 at 21:45, maldun dom...@gmx.net wrote: I agree with you that it is not that important as it was some years ago. Nevertheless be aware that many professional users in engineering and research can't go online that simply, because of security reasons, and company policies (I know that from first hand), and they are a big market which we should not underestimate. +1 In many engineering/industrial/technical contexts, especially in big corporations, a Windows workstation is still the default setup, OSX is non-existent, and Linux/Unix is relegated to HPC and clusters. This is not going to change substantially in the short term. I think there is also a code-quality rationale for having strong multi-platform and multi-architecture support. Software is a bit like a lifeform, living in and adapting to different environments makes it stronger and more resilient. Cheers, Francesco. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
On 5 December 2014 at 20:48, 'Martin R' via sage-devel sage-devel@googlegroups.com wrote: A famous example is integrate(x/sqrt(x^4+10*x^2+-96*x-71),x) which Mathematica won't do, although it is elementary, i.e., has a solution in terms of elementary functions: log((x^6+15*x^4+-80*x^3+27*x^2+-528*x+781)*(x^4+10*x^2+-96*x+-71)^(1/2)+(x^8 +20*x^6+-128*x^5+54*x^4+-1408*x^3+3124*x^2+10001))/8 That is pretty interesting, I would've treated this as an elliptic integral without thinking about it twice. I have two questions: - I imagine if you calculate it as an elliptic integral (say, using the Weierstrassian functions) you would end up with elliptic invariants g1 and g2 with special values that make the elliptic integral collapse to an elementary function? - The factorization of the polynomial in the integrand yields a suspiciously symmetrical form in the factors, is that the reason why the integral can be evaluated with elementary functions? Sorry for the OT! Francesco. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] in IntegralDomains() issues
I came across the following
{{{
R.x = ZZ[]
S.t = R.quo(x^2+5)
S in IntegralDomains()
False
}}}
and even simpler
{{{
R=Zmod(5)
R in IntegralDomains()
False
}}}
This is related to
https://groups.google.com/forum/#!topic/sage-algebra/6C3XkkLfllw
but I couldn't find what ticket it is associated with. I know Sage is
trying to move away from tests like is_integral_domain() to tests like in
IntegralDomains, but those examples are both wrong. Is there some issue
with getting those to 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...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
On Saturday, December 6, 2014 4:30:35 PM UTC+1, bluescarni wrote: - I imagine if you calculate it as an elliptic integral (say, using the Weierstrassian functions) you would end up with elliptic invariants g1 and g2 with special values that make the elliptic integral collapse to an elementary function? Define elementary. I guess the integral is a holonomic function. x/(exp(x)-1) is not, though it looks quite elementary. https://en.wikipedia.org/wiki/Holonomic_function Just a guess. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
Hi, I don't know which of the following is better in the three M's as I have close to no experience with them, but I suspect at least the documentation part is... - Dima Pasechnik mentioned representation theory of associative algebras, but even linear algebra over fields is not implemented in Sage when the vector spaces are not given as R^n or R^m but as CombinatorialFreeModules. This can be worked around in any specific situation by mapping them to R^n and R^m, but the work required grows with the complexity of the question, and this ends up being severely limiting. - Implementers of classes have to make decisions which really should be left to users of their classes. When you create your class of (say) posets, you have to decide whether to cache covering relations or to compute them every time as needed; whether to compute certain invariants when the class is being created or only later; how to represent the data internally; etc.. But there is no right way to make such decisions; it all depends on the user and whether he is planning to study one or two posets in detail or to generate thousands of them as intermediate steps of an algorithm. (For a better example, we recently had a discussion of how much information about a Coxeter group should be computed at the moment of its creation.) We should IMHO use abstract classes more often, but I see very few examples of this in Sage. - Documentation. Sorry, but much of it reads like mason's marks from thousand years ago; particularly on underscored methods (I think people believe that underscore means noone will ever want to use it, but that's not true). Best regards, Darij -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: in IntegralDomains() issues
Hey Ben,
I came across the following
{{{
R.x = ZZ[]
S.t = R.quo(x^2+5)
S in IntegralDomains()
False
}}}
This was an easy fix since we do the primitive test when constructing the
quotient. This is http://trac.sagemath.org/ticket/17450 which is
needs_review.
and even simpler
{{{
R=Zmod(5)
R in IntegralDomains()
False
}}}
This is related to
https://groups.google.com/forum/#!topic/sage-algebra/6C3XkkLfllw
but I couldn't find what ticket it is associated with. I know Sage is
trying to move away from tests like is_integral_domain() to tests like in
IntegralDomains, but those examples are both wrong. Is there some issue
with getting those to work?
The containment testing for IntegralDomains should mimic that of Fields, in
that somewhere it should try is_integral_domain() if it's an attribute.
Moreover, Zmod should outsource is_integral_domain() to the is_field()
test. However this is a more expansive change, but it shouldn't be
controversial...
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Let's encrypt
We should support the let's encrypt project asap, though it is launching in 2015... On Saturday, December 6, 2014 10:10:54 AM UTC, P Purkayastha wrote: Hello devs, I hope someone here knows how the certificate system works for https connections. I am raising this question because of the Let's Encrypt announcement [1] made by EFF last month. It would make it easier to recommend the secure mode for the sage notebook. Currently, all browsers give a big fat warning if the notebook is started in secure mode. [1] https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web Cheers, basu. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] fricas pkg in Sage
Hello, I just discover FriCAS and its tremendous possibilities. I just updated the package that we ship we Sage from version 0.3.1 to version 1.2.4 (more information at http://trac.sagemath.org/ticket/9465). It might become a more standard package. I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? Best Vincent -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
The installation instructions say that ecl is roughly 3 times slower. Once upon a time, when I was a fricas contributor, it made quite a difference. But back than, sbcl was a no-go for sage (I forgot why). I still love fricas' language. I never underrstood why Python succeeded and Aldor didn't, once it became free. But that's live. Martin -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
Maybe one reason to prefer ecl is that it is embeddable, which could allow us to have a much faster interface than pexpect? -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
I'm not sure that fricas *has* to be a package : the current versins (6.4, 6.5beta) already have the fricas interface compiled in : /usr/local/sage-6.5/src/build/lib.linux-x86_64-2.7/sage/interfaces/fricas.py /usr/local/sage-6.5/src/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.pyc and fricas() calls a possible systemwide fricas. Successfully. Therefore fricas has the same Sage status as Mathematica, Magma or Matlab. However, the fricas interface lacks a .fricas() method for getting the (a) fricas-palatable representation of some objects. It also lacks somethong to avid the ascii_art default output of fricas, which is quite unparsable by the sage() method (which exists). I also saw somewhere on the list the suggestion of a algorithm=fricas option to integrate(), which seems a very good idea. Nevertheless, having a fricas package which might replace a systemwide fricas installation might help its disemination. HTH, -- Emmanuel Charpentier Le samedi 6 décembre 2014 18:23:32 UTC+1, vdelecroix a écrit : Hello, I just discover FriCAS and its tremendous possibilities. I just updated the package that we ship we Sage from version 0.3.1 to version 1.2.4 (more information at http://trac.sagemath.org/ticket/9465). It might become a more standard package. I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? Best Vincent -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: What are we unable to do right now ?
Le samedi 6 décembre 2014 15:38:20 UTC+1, Ralf Stephan a écrit :
On Saturday, December 6, 2014 11:59:14 AM UTC+1, mmarco wrote:
If FriCAS is right now the best software for computing these kind of
integrals, it might be worth the effort to include it as standard package,
write a good interface and adapt the integrate methods to use it, at least
as a fallback option.
The interface already exists:
sage: fricas('3 * 5')
...
TypeError: unable to start fricas because the command 'fricas -nox
-noclef' failed
$ ./sage -i fricas
...
Error installing package fricas-0.3.1
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
/home/ralf/sage/logs/pkgs/fricas-0.3.1.log
http://trac.sagemath.org/ticket/9465
Regards,
That interface calls a systemwide fricas. This works for me...
HTH,
--
Emmanuel Charpentier
--
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 to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: What are we unable to do right now ?
sage: fricas.integrate(x^2,x).unparsed_input_form() '(1/3)*x^3' Or, more usefully : sage: toto=eval(preparse(fricas.integrate(x^2,x).unparsed_input_form())) ; toto 1/3*x^3 sage: parent(toto) Symbolic Ring sage: type(toto) type 'sage.symbolic.expression.Expression' which might be the point of the whole exercise... HTH, -- Emmanuel Charpentier -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [fricas-devel] fricas pkg in Sage
On 12/06/2014 06:23 PM, 20100.delecr...@gmail.com wrote: I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? I'd say yes. But it's probably Waldek who has more knowledge of ecl vs. sbcl. I only remember that compilation (at least some years ago) with ecl took quite a bit longer than with sbcl. In fact, I don't see any embeddable advantage of ecl for Sage. It's usually the computation that costs time (since I only expect heavier or complicated computations exported to FriCAS) not the conversion from one Sage to FriCAS and back. Especially the translation of FriCAS types into Sage types is nearly impossible. FriCAS has quite a sophisticated type hierarchy. I would expect that there isn't even always a corresponding Sage type that one could convert the FriCAS result to in order to have those values natively available for further computations in Sage. Anyway, being able to call FriCAS from within Sage and thus giving Sage users access to the power of FriCAS, is certainly a good step. Ralf -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
Le samedi 6 décembre 2014 19:01:46 UTC+1, Emmanuel Charpentier a écrit : I'm not sure that fricas *has* to be a package : the current versins (6.4, 6.5beta) already have the fricas interface compiled in : /usr/local/sage-6.5/src/build/lib.linux-x86_64-2.7/sage/interfaces/fricas.py /usr/local/sage-6.5/src/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.pyc and fricas() calls a possible systemwide fricas. Successfully. Therefore fricas has the same Sage status as Mathematica, Magma or Matlab. However, the fricas interface lacks a .fricas() method for getting the (a) fricas-palatable representation of some objects. It also lacks somethong to avid the ascii_art default output of fricas, which is quite unparsable by the sage() method (which exists). I also saw somewhere on the list the suggestion of a algorithm=fricas option to integrate(), which seems a very good idea. Nevertheless, having a fricas package which might replace a systemwide fricas installation might help its disemination. HTH, -- Emmanuel Charpentier Le samedi 6 décembre 2014 18:23:32 UTC+1, vdelecroix a écrit : Hello, I just discover FriCAS and its tremendous possibilities. I just updated the package that we ship we Sage from version 0.3.1 to version 1.2.4 (more information at http://trac.sagemath.org/ticket/9465). It might become a more standard package. I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? Best Vincent Ahem. I have to retract that : if we want to add an 'algorithm=fricas' option to sage's integrate(), fricas just *has* to be there as a standard package. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: fricas pkg in Sage
On Sat, Dec 6, 2014 at 11:13 AM, Emmanuel Charpentier emanuel.charpent...@gmail.com wrote: Le samedi 6 décembre 2014 19:01:46 UTC+1, Emmanuel Charpentier a écrit : I'm not sure that fricas *has* to be a package : the current versins (6.4, 6.5beta) already have the fricas interface compiled in : /usr/local/sage-6.5/src/build/lib.linux-x86_64-2.7/sage/interfaces/fricas.py /usr/local/sage-6.5/src/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.py /usr/local/sage-6.5/local/lib/python2.7/site-packages/sage/interfaces/fricas.pyc and fricas() calls a possible systemwide fricas. Successfully. Therefore fricas has the same Sage status as Mathematica, Magma or Matlab. However, the fricas interface lacks a .fricas() method for getting the (a) fricas-palatable representation of some objects. It also lacks somethong to avid the ascii_art default output of fricas, which is quite unparsable by the sage() method (which exists). I also saw somewhere on the list the suggestion of a algorithm=fricas option to integrate(), which seems a very good idea. Nevertheless, having a fricas package which might replace a systemwide fricas installation might help its disemination. HTH, -- Emmanuel Charpentier Le samedi 6 décembre 2014 18:23:32 UTC+1, vdelecroix a écrit : Hello, I just discover FriCAS and its tremendous possibilities. I just updated the package that we ship we Sage from version 0.3.1 to version 1.2.4 (more information at http://trac.sagemath.org/ticket/9465). It might become a more standard package. I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? Best Vincent Ahem. I have to retract that : if we want to add an 'algorithm=fricas' option to sage's integrate(), fricas just *has* to be there as a standard package. No, your original statement was correct, since we have algorithm='magma' for some functions. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
On Saturday, December 6, 2014 11:13:27 AM UTC-8, Emmanuel Charpentier wrote: Ahem. I have to retract that : if we want to add an 'algorithm=fricas' option to sage's integrate(), fricas just *has* to be there as a standard package. There is precedent otherwise. For instance NumberField(x^5+4).galois_group has an option algorithm=magma. Magma can compute galois groups of a much larger class of number fields than the other options can, and magma is (naturally) not a standard package. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: [fricas-devel] fricas pkg in Sage
On Sat, Dec 6, 2014 at 11:04 AM, Ralf Hemmecke r...@hemmecke.org wrote: On 12/06/2014 06:23 PM, 20100.delecr...@gmail.com wrote: I have a very naive question: the version of lisp we have in Sage is ecl, does it make a huge difference with sbcl ? In fact, I don't see any embeddable advantage of ecl for Sage. It's usually the computation that costs time (since I only expect heavier or complicated computations exported to FriCAS) not the conversion from one Sage to FriCAS and back. A possible clarification: There are strong advantages to the embeddability of ecl for Sage, just maybe not for FriCAS. We use Maxima via embedded ecl, which makes conversions back and forth very fast, which do matter. William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups sage-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: fricas pkg in Sage
On Saturday, December 6, 2014 9:33:57 AM UTC-8, Martin R wrote: The installation instructions say that ecl is roughly 3 times slower. Once upon a time, when I was a fricas contributor, it made quite a difference. But back than, sbcl was a no-go for sage (I forgot why). I think it was because to build sbcl from source, you needed (and still need) an ANSI-compliant Common Lisp already on your machine. So we would maybe need to ship two lisps, sbcl plus another one to build sbcl. -- John -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [fricas-devel] fricas pkg in Sage
On Saturday, December 6, 2014 11:04:31 AM UTC-8, Ralf Hemmecke wrote: I'd say yes. But it's probably Waldek who has more knowledge of ecl vs. sbcl. I only remember that compilation (at least some years ago) with ecl took quite a bit longer than with sbcl. Yes, ecl tends to be quite slow in compiling relative to other lisps, partially because gcc is invoked in the process. That's not necessarily indicative of runtime performance. SBCL tends to be faster in general, though. In fact, I don't see any embeddable advantage of ecl for Sage. It's usually the computation that costs time (since I only expect heavier or complicated computations exported to FriCAS) not the conversion from one Sage to FriCAS and back. Using a binary transfer interface rather than a strings-based one doesn't just have performance advantages, it also solves reliability issues. You wouldn't need to run in the same process, though. With some programming work on both sides, it should be possible to set up a communication interface that does not rely on typed mathematics. Especially the translation of FriCAS types into Sage types is nearly impossible. FriCAS has quite a sophisticated type hierarchy. I would expect that there isn't even always a corresponding Sage type that one could convert the FriCAS result to in order to have those values natively available for further computations in Sage. Types that can't be represented in sage would obviously not be very interesting for sage (but this can change in time). The ones that can would be very useful, though. Plus, we can just extend what is available in sage. Note that FriCAS uses types for purposes that in sage are modeled using its parent/category/type framework, so for translation you shouldn't try and stuff it all into just the python type hierarchy that sage uses. -- 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 to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: in IntegralDomains() issues
Thanks. I've reviewed #17450 and opened #17453 for the integer mod rings.
On Saturday, December 6, 2014 11:39:21 AM UTC-5, Travis Scrimshaw wrote:
Hey Ben,
I came across the following
{{{
R.x = ZZ[]
S.t = R.quo(x^2+5)
S in IntegralDomains()
False
}}}
This was an easy fix since we do the primitive test when constructing the
quotient. This is http://trac.sagemath.org/ticket/17450 which is
needs_review.
and even simpler
{{{
R=Zmod(5)
R in IntegralDomains()
False
}}}
This is related to
https://groups.google.com/forum/#!topic/sage-algebra/6C3XkkLfllw
but I couldn't find what ticket it is associated with. I know Sage is
trying to move away from tests like is_integral_domain() to tests like in
IntegralDomains, but those examples are both wrong. Is there some issue
with getting those to work?
The containment testing for IntegralDomains should mimic that of Fields,
in that somewhere it should try is_integral_domain() if it's an attribute.
Moreover, Zmod should outsource is_integral_domain() to the is_field()
test. However this is a more expansive change, but it shouldn't be
controversial...
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
