[sage-devel] Re: SymEngine 0.1.0 released
Nice. I'm looking forward to contribute, not the least because of the review situation, but also because it is useful for more than one project. -- 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] Methods for evaluating the Jones representations of braids and the Jones polynomials of the closure
Not short term plans as far as I know. The best would be to ask Thierry Coulbois himself. One thing which should be relatively easy would be to polish the doctests and make it an optional package. Vincent On 10/08/15 16:47, fuglede.sagem...@gmail.com wrote: Nifty! Any plans to include this in the code base? - Søren Den søndag den 9. august 2015 kl. 15.25.08 UTC+2 skrev vdelecroix: Hello, Let me tell you that T. Coulbois already implemented Bestvina-Handel algorithm (for general automorphisms of the free group): https://github.com/coulbois/sage-train-track There are a lot of possible optimization and improvement in the documentation. But it works well (and has been intensively tested). 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: Tarball uploads
On 10/08/15 14:38, Volker Braun wrote: On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote: I agree with you: from a technical point of view this is stupid. It is not. There is no security without the chain of trust. Maybe in a parallel universe where everybody is so far on the autistic spectrum that they religiously verify finger prints over a second channel, but not in the real world. It is. There is no security without the chain of trust. And I do not trust certificate authority. If a trusted certificate authority X provides me a certificate for google.com then I can be a man in the middle. What prevent them for doing so? This is a very weak design. Moreover, who can be a certificate authority? Let me propose something less stupid: the first time you access to a website you have to accept the certificate manually (if you wish you can have a look at the fingerprint). Then, until it changes nothing happens (the very same way ssh works). It does not prevent certificate authority to keep signing the certificate if they wish. Right now, if a certificate changes but it is certified, you browser will not alert you. But it definitely should. -- 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: Tarball uploads
What I meant is that it doesn't make any sense to show a scary warning in the case of encrypted but not verified pages, but don't show any warning in the case of neither encrypted nor verified plain http pages. The second is strictly less secure than the first... yet the browser induces the user to think that it is actually more secure. About the security model of CA certificates, I recommend this talk: http://m.youtube.com/watch?v=pDmj_xe7EIQ -- 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: Tarball uploads
On Monday, August 10, 2015 at 5:34:49 PM UTC+2, vdelecroix wrote: Moreover, who can be a certificate authority? There is always google if you want to know the requirements for a CA Your proposal would result in daily new certificate warnings as you browse to new web pages and/or certificates expire. How long until your mom/gf/so/non-technical friend would stop caring and click on OK out of reflex? How to revoke compromised self-signed certs? You are essentially expanding your trust from hundreds of CAs to millions of small websites. -- 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: Tarball uploads
What I meant is that it doesn't make any sense to show a scary warning in the case of encrypted but not verified pages, but don't show any warning in the case of neither encrypted nor verified plain http pages. The second is strictly less secure than the first... yet the browser induces the user to think that it is actually more secure. About the security model of CA certificates, I recommend this talk: http://m.youtube.com/watch?v=pDmj_xe7EIQ -- 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: Tarball uploads
On Monday, August 10, 2015 at 7:10:43 PM UTC+2, mmarco wrote: What I meant is that it doesn't make any sense to show a scary warning in the case of encrypted but not verified pages, but don't show any warning in the case of neither encrypted nor verified plain http pages. The second is strictly less secure than the first... The former is a tell-tale sign of a MITM attack, the latter is just how http usually works. -- 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] Methods for evaluating the Jones representations of braids and the Jones polynomials of the closure
Nifty! Any plans to include this in the code base? - Søren Den søndag den 9. august 2015 kl. 15.25.08 UTC+2 skrev vdelecroix: Hello, Let me tell you that T. Coulbois already implemented Bestvina-Handel algorithm (for general automorphisms of the free group): https://github.com/coulbois/sage-train-track There are a lot of possible optimization and improvement in the documentation. But it works well (and has been intensively tested). 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: Tarball uploads
Precisely. Tee way http works is strictly less secure than the most insecure HTTPS scenario. If I wanted to mitm some HTTPS connection, I wouldn't do so by redirecting the victim to a fake HTTPS web page, but to a fake http one. The lack of warnings from the browser would make such an attack go unnoticed in many cases. That is, the lack of a warning from the browser in plain http makes the protection of ssl certificates much less effective. In the video I linked before moxie marlinspike proposes an alternative method to check the authenticity of a web site that is not based on CAs. I see some problems to his approach, but I agree with him that we need to look for something different than what we have right now. -- 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: Tarball uploads
On 08/10/2015 08:38 AM, Volker Braun wrote: On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote: I agree with you: from a technical point of view this is stupid. It is not. There is no security without the chain of trust. Maybe in a parallel universe where everybody is so far on the autistic spectrum that they religiously verify finger prints over a second channel, but not in the real world. You don't need to verify the fingerprint. If you don't have to pay for certs, you can make them valid for eternity, and only warn the user when they change. There's only one opportunity for a MITM -- when you first save the cert -- and that's no different than the CA model (where did you get your root certs?). -- 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: [ANN] Flint 2.5 released
the flint upgrade #19009 needs review! On 10/08/15 13:36, Vincent Delecroix wrote: I created #19009 for the upgrade in Sage. On 08/08/15 11:59, 'Bill Hart' via sage-devel wrote: I just updated the tarballs to fix an issue noted with the MSVC build. Note, this only affects Windows when building with MSVC, hence I didn't push the patch number. Bill. On 7 August 2015 at 23:33, Bill Hart goodwillh...@googlemail.com wrote: Hi all, We are very pleased to present Flint version 2.5.0. It can be downloaded from our website: http://http://flintlib.org/ FLINT is a C library for arithmetic in support of Number Theory, including polynomial arithmetic and linear algebra over Z, Z/nZ, Q, p-adics, q-adics, F_q, and univariate factorisation over those rings. It depends on GMP or MPIR and MPFR. New features/improvements in this release include: * LLL (rational, Nguyen-Stehle, from Gram matrix, with_removal, Storjohann/ULLL) [1] * Hermite normal form (naive, xgcd, Domich-Kannan-Trotter, Kannan-Bachem, Pernet-Stein) [1] * Smith normal form (diagonal, Kannen-Bachem, Iliopoulos) [1] * Paterson-Stockmeyer algorithm * modular resultant * half gcd style resultant * polynomial discriminant * multithreaded multimodular Taylor shift * multithreaded Brent-Kung composition * multithreaded Kaltofen-Shoup distinct degree factorisation * multiplication based reduced row echelon form * inline functions included in library for use by foreign function interfaces * Primality tests for large integers (Pocklington, Morrison) * Probable prime tests for large integers (Lucas, Baillie-PSW, strong-psp, Brillhart-Lehmer-Selfridge) * CRT for large integers * Dixon algorithm for nullspace [1] * Brent-Kung composition in irreducibility and distinct degree factorisation * floating point QR decomposition * Schwarz-Rutishauser Gram-Schmidt algorithm * Ogita-Rump-Oishi dot product * matrix window functions * MSVC support (Brian Gladman) * fast cube/nth-root (Newton, Kahan, magic number, Chebyshev) * Bodrato matrix squaring * matrix concatenation functions * matrix content * faster n_gcd * faster n_sqrtmod and fmpz_sqrtmod * additional functions for returning factor of modulus in polys over Z/nZ * Hadamard matrix construction * series addition/subtraction * faster prime_pi bounds * speedup creation of sparse polynomials * speedup n_isprime and n_nextprime * speedup n_isprime_pocklington * speedups to fmpq_poly and fmpz_poly arithmetic * speedup polynomial irreducibility testing over Z/pZ * speedup of rank computation over ZZ * made CPimport compile time dependency only * teach flint_printf/sprintf about explicit width format specifiers * support relative paths in configure * library soname versioning * ARM64 patches * Support MSYS2 * Progress towards supporting MIPS64 * Many build system improvements * Fix a serious bug in fmpz_poly_signature Contributors to this release include: Abinhav Baid, Alex Best, Fredrik Johansson, William Hart, Brian Gladman, Jean-Pierre Flori, Martin Lee, Curtis Bright, Daniel Fabian, Julian Ospald, Dan Grayson, Dana Jacobsen, Vladimir Glazachev, Kushagra Singh, Ashish Kedia, Anubhav Srivistava, Prabhdeep Singh, Alena Sergeicheva, Sebastian Pancratz, mgkurtz, Tommy Hofmann, Daniel Roche, Max Goldfar, Andreas Enge, Francois Bissey, Denis Kryskov, Anton Mellit, and numerous others. [1] Thanks to Google for funding students through its Google Summer of Code. Abinhav Baid and Alex Best contributed to Flint through this program. Best wishes, The Flint Development Team. -- 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: Tarball uploads
On 08/10/2015 11:34 AM, Vincent Delecroix wrote: Let me propose something less stupid: the first time you access to a website you have to accept the certificate manually (if you wish you can have a look at the fingerprint). Then, until it changes nothing happens (the very same way ssh works). It does not prevent certificate authority to keep signing the certificate if they wish. This is called certificate pinning and it's a great idea. Mozilla and Google pin their own certs for mozilla.org and google.com (and a few others, now) in Firefox/Chrome. But it's not available generally because it doesn't make anyone money. Once you have certificate pinning, you can just get rid of the CAs and use self-signed certs that last forever. Works better, for free. -- 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] SymEngine 0.1.0 released
Hi, We just released SymEngine 0.1.0: https://github.com/sympy/symengine/releases/tag/v0.1.0 SymEngine (https://github.com/sympy/symengine) is a standalone fast C++ symbolic manipulation library. Optional thin wrappers allow usage of the library from other languages, we currently have C, Python, Ruby and Julia wrappers. The Python wrappers allow integration with SymPy and Sage. SymEngine was previously called CSymPy, but we renamed it, since it can be used from any language, not just Python. Even though the Python wrappers are the most developed, and I am personally heavily invested in Python and my long term goal is to figure out how to port SymPy on top of SymEngine, as well as Sage on top of SymEngine. So that we can have just one symbolic library, that is fast, but also has a lot of features, either in terms of SymPy in Python, or eventually in C++ (that way other languages can benefit as well). Here are build instructions for Sage: https://github.com/sympy/symengine/wiki/Building-SymEngine#installing-into-sage, we tested it on Sage Math Cloud. You can then use Sage with SymEngine in it to run your favorite benchmark. We also have some automatic benchmarks, some timings are posted here: https://github.com/sympy/symengine/pull/579 We benchmark both the Python wrappers (against Sage or SymPy), as well as just the raw C++ library (against e.g. GiNaC). Most of these benchmarks are synthetic, and so the problem with them is that you can for example use a fast polynomial library to do them faster. SymEngine seems to be faster than Sage on all of them, but if you find some where Sage is faster, definitely let me know. However, much better is to benchmark on some real applications. Here is an example: https://github.com/certik/symengine/pull/10#issuecomment-129199481, that uses symbolics (as it has square roots, fractions, sin, cos and other things) and it is benchmarking how long it takes to do a derivative (once the expression is fully converted to Sage, SymEngine or SymPy). The expression comes up when calculating equations of motion for a bicycle using PyDy (http://www.pydy.org/), you actually need a Jacobian, but this is just one element of it. And Sage seems 6x slower. The benchmark is here: https://github.com/sympy/symengine/pull/580, it's the kane3.py. It should be pointed out that Sage might arrange the final expression a bit differently, so a meaningful benchmark is to do the whole bicycle application, not just one derivative. But so far my experience has been that SymEngine is faster than Sage (sometimes significantly, I think 6x is a good speedup) and if you find some application or a case when Sage is faster, please let me know. What is the best way to maintain a package like this for Sage --- we currently create an spkg, but I read somewhere that spkgs will be deprecated? Right now we want to maintain it ourselves and make it easy for people to try out and if enough people like it, we can start discussing more how to make Sage use it by default. As I said, that is my long term goal, but it is a lot of work. If successful though, users and developers of Sage can then contribute to it and then anybody else who uses SymEngine outside of Sage will immediately benefit, and vice versa. And by being in C++, not just Python users will benefit, since the main development is done in C++. There are lots of people in Ruby, Julia, even Haskell who ask for a symbolic package. And this can be it. The C++ code is truly cross platform, we test every commit with gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows. I also test manually with Intel and PGI compilers. See here for more details: https://github.com/sympy/symengine/wiki/Compiler-Support There will be bugs that you might discover during building it, but they can be fixed if you report them. Inherently it should build using any recent C++11 compiler on any platform. If you try it out, we would be interested in any feedback, both positive and negative. Isuru has spent most of the summer making it working well with Sage and improving the code overall. And several other GSoC students have been working on it as well. Ondrej -- 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] SymEngine 0.1.0 released
Hi Ondřej, Old fashioned .spkg are not in fashion anymore. In fact we very much want to kill them as much as possible. The new process separate the tarball from upstream (pristine as much as possible) and the building script. In a similar fashion gentoo ebuild or hashtag recipe. Look at https://github.com/sagemath/sage/tree/master/build/pkgs for some example. spkg-install is still very much the recipe used. So it should be done by pushing a branch on a sage ticket. We should really finish to push cmake through at least as an experimental package so this could also be in experimental. Once we sort out cmake as optional SymEngine could also become optional. I can probably get it in sage-on-gentoo straight away though. Francois On 08/11/15 11:26, Ondřej Čertík wrote: Hi, We just released SymEngine 0.1.0: https://github.com/sympy/symengine/releases/tag/v0.1.0 SymEngine (https://github.com/sympy/symengine) is a standalone fast C++ symbolic manipulation library. Optional thin wrappers allow usage of the library from other languages, we currently have C, Python, Ruby and Julia wrappers. The Python wrappers allow integration with SymPy and Sage. SymEngine was previously called CSymPy, but we renamed it, since it can be used from any language, not just Python. Even though the Python wrappers are the most developed, and I am personally heavily invested in Python and my long term goal is to figure out how to port SymPy on top of SymEngine, as well as Sage on top of SymEngine. So that we can have just one symbolic library, that is fast, but also has a lot of features, either in terms of SymPy in Python, or eventually in C++ (that way other languages can benefit as well). Here are build instructions for Sage: https://github.com/sympy/symengine/wiki/Building-SymEngine#installing-into-sage, we tested it on Sage Math Cloud. You can then use Sage with SymEngine in it to run your favorite benchmark. We also have some automatic benchmarks, some timings are posted here: https://github.com/sympy/symengine/pull/579 We benchmark both the Python wrappers (against Sage or SymPy), as well as just the raw C++ library (against e.g. GiNaC). Most of these benchmarks are synthetic, and so the problem with them is that you can for example use a fast polynomial library to do them faster. SymEngine seems to be faster than Sage on all of them, but if you find some where Sage is faster, definitely let me know. However, much better is to benchmark on some real applications. Here is an example: https://github.com/certik/symengine/pull/10#issuecomment-129199481, that uses symbolics (as it has square roots, fractions, sin, cos and other things) and it is benchmarking how long it takes to do a derivative (once the expression is fully converted to Sage, SymEngine or SymPy). The expression comes up when calculating equations of motion for a bicycle using PyDy (http://www.pydy.org/), you actually need a Jacobian, but this is just one element of it. And Sage seems 6x slower. The benchmark is here: https://github.com/sympy/symengine/pull/580, it's the kane3.py. It should be pointed out that Sage might arrange the final expression a bit differently, so a meaningful benchmark is to do the whole bicycle application, not just one derivative. But so far my experience has been that SymEngine is faster than Sage (sometimes significantly, I think 6x is a good speedup) and if you find some application or a case when Sage is faster, please let me know. What is the best way to maintain a package like this for Sage --- we currently create an spkg, but I read somewhere that spkgs will be deprecated? Right now we want to maintain it ourselves and make it easy for people to try out and if enough people like it, we can start discussing more how to make Sage use it by default. As I said, that is my long term goal, but it is a lot of work. If successful though, users and developers of Sage can then contribute to it and then anybody else who uses SymEngine outside of Sage will immediately benefit, and vice versa. And by being in C++, not just Python users will benefit, since the main development is done in C++. There are lots of people in Ruby, Julia, even Haskell who ask for a symbolic package. And this can be it. The C++ code is truly cross platform, we test every commit with gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows. I also test manually with Intel and PGI compilers. See here for more details: https://github.com/sympy/symengine/wiki/Compiler-Support There will be bugs that you might discover during building it, but they can be fixed if you report them. Inherently it should build using any recent C++11 compiler on any platform. If you try it out, we would be interested in any feedback, both positive and negative. Isuru has spent most of the summer making it working well with Sage and improving the code overall. And several other GSoC students have been working on it as well. Ondrej -- You received this
Re: [sage-devel] SymEngine 0.1.0 released
And for what it is worth, I very strongly believe we should do everything we can to transition Sage itself over to using current standard current approaches to development and distribution. That means fully supporting pip, using github (instead of a custom trac and wiki install), and better integrating with Linux distro package systems, etc. It would also mean trying to break up the full SageMath library into smaller more manageable dependencies with semantic versioning, and have pip bring those in. I'm very curious whether other Sage developers agree with me that the time is ripe to move in such a direction. William, Based on my experience using pip/PyPI/easy_install/etc. to distribute SnapPy as an amalgam of these packages https://pypi.python.org/pypi?%3Aaction=searchterm=dunfieldsubmit=search --- which includes a stand-alone version of Sage's PARI interface --- one issue that comes to mind is that pip has limited support for binary wheels on Linux. In fact, currently PyPI refuses to host Linux wheels (though OS X and Windows wheels are accepted). We do provide binary Linux eggs that work with the deprecated easy_install on most reasonably recent Linux distros, but this requires some ugly hacks to deal with e.g. whether Python is compiled to use 2 or 4 byte unicode strings, as well as compiling the eggs themselves on virtual machines running really dated distros. So using pip and PyPI on Linux would likely result in building each Python module from source. For modules with modest-to-moderate amounts of C/C++ code, this is no problem, and even something larger but reasonably self-contained like PARI can be dealt with by having setup.py just execute some Makefile or whatever. Things with dependencies on system libraries (e.g. OpenGL headers or whatever) can get tricky which is why it would be really nice to have binary wheels as a fallback... Best, Nathan Best, Nathan -- 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: Tarball uploads
an alternative might be to use github - package maintainers can create tarballs via github release creation. On Saturday, 8 August 2015 20:22:18 UTC+1, Volker Braun wrote: In order to streamline updating third-party tarballs I've written a small web app where you can directly upload them. That way you don't need to host files yourself. Plus, the files can be retrieved by sha1 so with a little bit more scripting I won't always forget to manually copy them to the mirrors. Its a bit on the cutting-edge side (Python 3 aiohttp and Polymer) but should work on all current browsers, so its ready to beta-test: http://fileserver.sagemath.org:8080/ Source code is at https://github.com/vbraun/SageDevApp -- 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] Methods for evaluating the Jones representations of braids and the Jones polynomials of the closure
From a quick lookover, it looks like it is easy enough to actually port the methods directly into Sage, which would make it easier to maintain and use than an optional spkg. Best, Travis On Monday, August 10, 2015 at 8:26:36 AM UTC-7, vdelecroix wrote: Not short term plans as far as I know. The best would be to ask Thierry Coulbois himself. One thing which should be relatively easy would be to polish the doctests and make it an optional package. Vincent On 10/08/15 16:47, fuglede@gmail.com javascript: wrote: Nifty! Any plans to include this in the code base? - Søren Den søndag den 9. august 2015 kl. 15.25.08 UTC+2 skrev vdelecroix: Hello, Let me tell you that T. Coulbois already implemented Bestvina-Handel algorithm (for general automorphisms of the free group): https://github.com/coulbois/sage-train-track There are a lot of possible optimization and improvement in the documentation. But it works well (and has been intensively tested). 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] SymEngine 0.1.0 released
On Mon, Aug 10, 2015 at 4:26 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: What is the best way to maintain a package like this for Sage --- we currently create an spkg, but I read somewhere that spkgs will be deprecated? Right now we want to maintain it ourselves and make it easy for people to try out and if enough people like it, we can start discussing more how to make Sage use it by default. I would like to strongly encourage you to make properly package and distribute SymEngine in the way that is standard for Python libraries, as in your issue 160: https://github.com/sympy/symengine/issues/160 Then I can install SymEngine by typing sage -sh pip install SymEngine And for what it is worth, I very strongly believe we should do everything we can to transition Sage itself over to using current standard current approaches to development and distribution. That means fully supporting pip, using github (instead of a custom trac and wiki install), and better integrating with Linux distro package systems, etc. It would also mean trying to break up the full SageMath library into smaller more manageable dependencies with semantic versioning, and have pip bring those in. I'm very curious whether other Sage developers agree with me that the time is ripe to move in such a direction. -- William, still tired of reinventing wheels... As I said, that is my long term goal, but it is a lot of work. If successful though, users and developers of Sage can then contribute to it and then anybody else who uses SymEngine outside of Sage will immediately benefit, and vice versa. And by being in C++, not just Python users will benefit, since the main development is done in C++. There are lots of people in Ruby, Julia, even Haskell who ask for a symbolic package. And this can be it. The C++ code is truly cross platform, we test every commit with gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows. I also test manually with Intel and PGI compilers. See here for more details: https://github.com/sympy/symengine/wiki/Compiler-Support There will be bugs that you might discover during building it, but they can be fixed if you report them. Inherently it should build using any recent C++11 compiler on any platform. If you try it out, we would be interested in any feedback, both positive and negative. Isuru has spent most of the summer making it working well with Sage and improving the code overall. And several other GSoC students have been working on it as well. Ondrej -- 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. -- William (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.
Re: [sage-devel] Re: Tarball uploads
On Monday, August 10, 2015 at 11:42:16 AM UTC+2, vdelecroix wrote: I agree with you: from a technical point of view this is stupid. It is not. There is no security without the chain of trust. Maybe in a parallel universe where everybody is so far on the autistic spectrum that they religiously verify finger prints over a second channel, but not in the real world. -- 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: Tarball uploads
Even without checking the certificate, https is mre secure than plain http. Of course you are vulnerable to MITM attacks (just as you are with http), but at least you are secure from pasive attacks. I really don't understand why browsers show a scary warning when you try to connect a web page by https with an untrtusted certificate... but show no warning at all when you connect to a much less secure plain http page. El domingo, 9 de agosto de 2015, 19:21:03 (UTC+2), Michael Orlitzky escribió: On 08/09/2015 07:09 AM, Volker Braun wrote: Yes, though we don't have a certificate for *.sagemath.org. Besides the cost, you also need to periodically renew etc. Though I'm hoping that Let's Encrypt (https://letsencrypt.org) will fix that. Launching this September... Just use a self-signed cert and post the fingerprint. If we trust you enough to click that URL, we trust you enough to post the fingerprint. For anyone who cares, that process is more secure than using a CA cert. Anyone who doesn't care or who believes the browser warning can use plain http. -- 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: Tarball uploads
On 10/08/15 11:32, mmarco wrote: I really don't understand why browsers show a scary warning when you try to connect a web page by https with an untrtusted certificate... Do you? A certificate authority makes money from selling certificates. They use a lot of energy in forcing browser developers to trust their services... It the same story why there is still a lot of salt, sugar and fat in all the prepared food that you buy in supermarket (this is very bad for the health but tasty for cheap, hence attracting for the food industry). I agree with you: from a technical point of view this is stupid. -- 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: DiGraph, int vs. sage Integer
On Mon, 10 Aug 2015, Vincent Delecroix wrote: Sounds reasonable. However, it seems to optimize only numbers from 0 to 9. Here is a test code: No. You are wrong. You can just have a look to the code publicly available. It is the class CGraphBackend in the file src/sage/graphs/base/c_graph.pyx that manage the labels. ??? For example I got [type 'int', type 'sage.rings.integer.Integer'] from g = Graph() g.add_vertex(9) g.add_vertex(10) [type(x) for x in g.vertices()] and this seems quite unexpected. -- Jori Mäntysalo
Re: [sage-devel] Re: DiGraph, int vs. sage Integer
On 10/08/15 09:40, Jori Mäntysalo wrote:
On Mon, 10 Aug 2015, Vincent Delecroix wrote:
Sounds reasonable. However, it seems to optimize only numbers from 0 to
9. Here is a test code:
No. You are wrong. You can just have a look to the code publicly
available. It is the class CGraphBackend in the file
src/sage/graphs/base/c_graph.pyx that manage the labels.
??? For example I got
[type 'int', type 'sage.rings.integer.Integer']
from
g = Graph()
g.add_vertex(9)
g.add_vertex(10)
[type(x) for x in g.vertices()]
But
sage: G = Graph()
sage: G.add_vertices(range(100))
sage: set(type(x) for x in G.vertices())
{type 'int'}
and this seems quite unexpected.
True. The number 10 is just the size of the initial allocated memory.
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: DiGraph, int vs. sage Integer
On Sun, 9 Aug 2015, Nathann Cohen wrote:
Is this a bug? If not, what is the rationale behind this?
What I know is that it was done deliberately, and I do not know the
rationale. I can guess that it was because you pay for labels, and that
Robert Miller thought that there was no reason to pay for them when the
vertices were labelled with integers.
Sounds reasonable. However, it seems to optimize only numbers from 0 to 9.
Here is a test code:
g1 = DiGraph({11:[9]})
print [(x, type(x)) for x in g1.vertices()]
g2 = DiGraph({8:[12]})
print [(x, type(x)) for x in g2.vertices()]
I would say that this is a bug. To what way should this be unified, that
I left others to decide.
I have NOT made a trac ticket, and won't look after this for a long time,
so hopefully somebody catches this.
--
Jori Mäntysalo
Re: [sage-devel] Re: DiGraph, int vs. sage Integer
On 10/08/15 09:19, Jori Mäntysalo wrote: On Sun, 9 Aug 2015, Nathann Cohen wrote: Is this a bug? If not, what is the rationale behind this? What I know is that it was done deliberately, and I do not know the rationale. I can guess that it was because you pay for labels, and that Robert Miller thought that there was no reason to pay for them when the vertices were labelled with integers. Sounds reasonable. However, it seems to optimize only numbers from 0 to 9. Here is a test code: No. You are wrong. You can just have a look to the code publicly available. It is the class CGraphBackend in the file src/sage/graphs/base/c_graph.pyx that manage the labels. I would say that this is a bug. To what way should this be unified, that I left others to decide. I agree that this is not very well documented and might be annoying. One way to fix it is to say *at creation* whether we want to use labels or not. 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: DiGraph, int vs. sage Integer
On Mon, 10 Aug 2015, Vincent Delecroix wrote:
But
sage: G = Graph()
sage: G.add_vertices(range(100))
sage: set(type(x) for x in G.vertices())
{type 'int'}
I guess you meant G.add_vertices(IntegerRange(100)). But still true, so it
goes. And also G.add_vertices(IntegerRange(1,100)) gives 'Integer' and
'int'.
And also
G = Graph()
G.add_vertices([0,1,2,3,4,5,6,7,8,9,10,11])
G.delete_vertex(4)
set(type(x) for x in G.vertices())
is different from
G = Graph()
G.add_vertices([0,1,2,3,5,6,7,8,9,10,11])
set(type(x) for x in G.vertices())
and this seems quite unexpected.
True. The number 10 is just the size of the initial allocated memory.
OK. I don't like magic numbers... But anyway, maybe this should be leave
as it is. Or maybe just documented, if it is not already.
--
Jori Mäntysalo
Re: [sage-devel] Re: [ANN] Flint 2.5 released
I created #19009 for the upgrade in Sage. On 08/08/15 11:59, 'Bill Hart' via sage-devel wrote: I just updated the tarballs to fix an issue noted with the MSVC build. Note, this only affects Windows when building with MSVC, hence I didn't push the patch number. Bill. On 7 August 2015 at 23:33, Bill Hart goodwillh...@googlemail.com wrote: Hi all, We are very pleased to present Flint version 2.5.0. It can be downloaded from our website: http://http://flintlib.org/ FLINT is a C library for arithmetic in support of Number Theory, including polynomial arithmetic and linear algebra over Z, Z/nZ, Q, p-adics, q-adics, F_q, and univariate factorisation over those rings. It depends on GMP or MPIR and MPFR. New features/improvements in this release include: * LLL (rational, Nguyen-Stehle, from Gram matrix, with_removal, Storjohann/ULLL) [1] * Hermite normal form (naive, xgcd, Domich-Kannan-Trotter, Kannan-Bachem, Pernet-Stein) [1] * Smith normal form (diagonal, Kannen-Bachem, Iliopoulos) [1] * Paterson-Stockmeyer algorithm * modular resultant * half gcd style resultant * polynomial discriminant * multithreaded multimodular Taylor shift * multithreaded Brent-Kung composition * multithreaded Kaltofen-Shoup distinct degree factorisation * multiplication based reduced row echelon form * inline functions included in library for use by foreign function interfaces * Primality tests for large integers (Pocklington, Morrison) * Probable prime tests for large integers (Lucas, Baillie-PSW, strong-psp, Brillhart-Lehmer-Selfridge) * CRT for large integers * Dixon algorithm for nullspace [1] * Brent-Kung composition in irreducibility and distinct degree factorisation * floating point QR decomposition * Schwarz-Rutishauser Gram-Schmidt algorithm * Ogita-Rump-Oishi dot product * matrix window functions * MSVC support (Brian Gladman) * fast cube/nth-root (Newton, Kahan, magic number, Chebyshev) * Bodrato matrix squaring * matrix concatenation functions * matrix content * faster n_gcd * faster n_sqrtmod and fmpz_sqrtmod * additional functions for returning factor of modulus in polys over Z/nZ * Hadamard matrix construction * series addition/subtraction * faster prime_pi bounds * speedup creation of sparse polynomials * speedup n_isprime and n_nextprime * speedup n_isprime_pocklington * speedups to fmpq_poly and fmpz_poly arithmetic * speedup polynomial irreducibility testing over Z/pZ * speedup of rank computation over ZZ * made CPimport compile time dependency only * teach flint_printf/sprintf about explicit width format specifiers * support relative paths in configure * library soname versioning * ARM64 patches * Support MSYS2 * Progress towards supporting MIPS64 * Many build system improvements * Fix a serious bug in fmpz_poly_signature Contributors to this release include: Abinhav Baid, Alex Best, Fredrik Johansson, William Hart, Brian Gladman, Jean-Pierre Flori, Martin Lee, Curtis Bright, Daniel Fabian, Julian Ospald, Dan Grayson, Dana Jacobsen, Vladimir Glazachev, Kushagra Singh, Ashish Kedia, Anubhav Srivistava, Prabhdeep Singh, Alena Sergeicheva, Sebastian Pancratz, mgkurtz, Tommy Hofmann, Daniel Roche, Max Goldfar, Andreas Enge, Francois Bissey, Denis Kryskov, Anton Mellit, and numerous others. [1] Thanks to Google for funding students through its Google Summer of Code. Abinhav Baid and Alex Best contributed to Flint through this program. Best wishes, The Flint Development Team. -- 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: Sage build from source fails on OS X 10.9
I opted for kicking my .bashrc out of the way and exporting a different PATH. Regardless, I now have a working Sage build! Thank you for solving my problem in two sentences :-) On Sunday, August 9, 2015 at 6:40:58 PM UTC-4, Volker Braun wrote: Building with homebrew in /usr/local is not supported and likely to fail. Move /usr/local out of the way and try again. On Sunday, August 9, 2015 at 11:53:51 PM UTC+2, Jeroen Sijsling wrote: Dear all, Today I tried to build Sage from source, for now just for the heck of it, but also because in the future I will probably want to contribute some code. Here is what happens after cloning from GitHub and typing make: Error installing package gcc-4.9.2.p1 Please email sage-devel (http://groups.google.com/group/sage-devel) explaining the problem and including the relevant part of the log file /Users/jrsijsling/Programs/sage/logs/pkgs/gcc-4.9.2.p1.log Describe your computer, operating system, etc. If you want to try to fix the problem yourself, *don't* just cd to /Users/jrsijsling/Programs/sage/local/var/tmp/sage/build/gcc-4.9.2.p1 and type 'make' or whatever is appropriate. Instead, the following commands setup all environment variables correctly and load a subshell for you to debug the error: (cd '/Users/jrsijsling/Programs/sage/local/var/tmp/sage/build/gcc-4.9.2.p1' '/Users/jrsijsling/Programs/sage/sage' --sh) When you are done debugging, you can type exit to leave the subshell. make[2]: *** [/Users/jrsijsling/Programs/sage/local/var/lib/sage/installed/gcc-4.9.2.p1] Error 1 make[1]: *** [all-toolchain] Error 2 real 21m12.146s user 14m47.666s sys 4m19.776s *** Error building Sage. The following package(s) may have failed to build (not necessarily during this run of 'make all'): * package: gcc-4.9.2.p1 log file: /Users/jrsijsling/Programs/sage/logs/pkgs/gcc-4.9.2.p1.log build directory: /Users/jrsijsling/Programs/sage/local/var/tmp/sage/build/gcc-4.9.2.p1 The build directory may contain configuration files and other potentially helpful information. WARNING: if you now run 'make' again, the build directory will, by default, be deleted. Set the environment variable SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this. make: *** [all] Error 1 I have not a clue where to look in this log file so I have simply appended it integrally. Some more information that could be relevant: My computer runs OS X 10.9 (Mavericks). While I do not have Xcode, I do have the command line tools. My C compiler comes from there, and gcc -v gives Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin13.4.0 Thread model: posix More tools have been installed through Homebrew; brew doctor tells me that it is feeling just fine except that Putting non-prefixed findutils in your path can cause python builds to fail. My binary for 6.8 runs without a hitch, and I seem to recall that development could be done from there as well; but I am still quite curious if it is possible to build from source. Many thanks in advance for your help! Best regards, Jeroen Sijsling -- 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.
