[sage-devel] Re: Regarding Braid project and its integration in Sage
leif wrote: Amit Jamadagni wrote: [...] We got introduced to the Braid progamme (http://www.layer8.co.uk/maths/braids/index.htm) project as we were looking out for Vogel's algorithm implementation. Coming to the details of Braid project it has been written in C++ and has some extensive results pertaining to Braid word representation. It would be great if the community could comment on the issue below: Would it be great to rewrite the entire code or just wrap the present code. (This has been posed keeping in mind that the community supports the idea "building the car instead of reinventing the wheel" because of the following reasons). We are yet to know the license on which the above project has been shipped. Yep, even the source tarball lacks any licen[cs]e or copyright information; the only thing I could find is Written by A. Bartholomew, January 2008 - February 2013 in a single file. P.S.: From [1]: [...] This is a spare time activity for me which I do solely for pleasure, for my day job I work as a computer network engineer. [...] If you plan to use any of these programmes, please read the disclaimer and general comments [2] If you find any bugs or errors, please email me at andr...@layer8.co.uk From [2]: All the software and results on this site are provided as is, and in good faith. To the best of my knowledge the code is accurate and the results presented correct, however, if you decide to use these results or software then I accept no responsibility for the consequences of any errors they may contain. Any errors that are reported to me will, in due course, be corrected at this site but no guarantees beyond best endeavours are given. [...] -leif [1] http://www.layer8.co.uk/maths/ [2] http://www.layer8.co.uk/maths/disclaimer.htm -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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: Regarding Braid project and its integration in Sage
Amit Jamadagni wrote: [...] We got introduced to the Braid progamme (http://www.layer8.co.uk/maths/braids/index.htm) project as we were looking out for Vogel's algorithm implementation. Coming to the details of Braid project it has been written in C++ and has some extensive results pertaining to Braid word representation. It would be great if the community could comment on the issue below: Would it be great to rewrite the entire code or just wrap the present code. (This has been posed keeping in mind that the community supports the idea "building the car instead of reinventing the wheel" because of the following reasons). We are yet to know the license on which the above project has been shipped. Yep, even the source tarball lacks any licen[cs]e or copyright information; the only thing I could find is Written by A. Bartholomew, January 2008 - February 2013 in a single file. If the author is happy then we are thinking of re-implementing the most important parts and writing wrappers for the rest as a temporary solution (during the coding period) and then move onto re-implement the rest of the project (after the summer) [The re-implementation would help in maintaining the code]. Some might comment saying " Why to reinvent the wheel if wrappers are present ?? " We had problems compiling the braid project using gcc 4.7, it worked fine using the older versions. So we cannot guarantee that wrappers would work on every system. We could certainly help in making it conform to newer C++ standards; GCC (g++) tends to get "stricter" with each major release. And as mentioned above, re-implementation might help in effective maintenance of the code. Well, contributing changes back upstream would certainly be a better option, provided the licence allows us to redistribute the code (modified or not). -leif So we have come to the conclusion that the code must be rewritten but it would be done in phases. If there could be a better way out, it would be of great help if we could be notified. If it turns out to be negative (in sense the license does not meet the expectations) then re-writing the entire logic would be the only option remaining.(We are losing out on wrappers for some good code for a temporary period of time). Hoping to hear from the community.Thanks. Amit. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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] Regarding Braid project and its integration in Sage
Hello all, We (me under the mentorship of Miguel) have been working on the implementation of Knot theory in Sage as a part of GSoC 2014 and would like to hear your thoughts on the following subject. We got introduced to the Braid progamme ( http://www.layer8.co.uk/maths/braids/index.htm) project as we were looking out for Vogel's algorithm implementation. Coming to the details of Braid project it has been written in C++ and has some extensive results pertaining to Braid word representation. It would be great if the community could comment on the issue below: Would it be great to rewrite the entire code or just wrap the present code. (This has been posed keeping in mind that the community supports the idea "building the car instead of reinventing the wheel" because of the following reasons). We are yet to know the license on which the above project has been shipped. If the author is happy then we are thinking of re-implementing the most important parts and writing wrappers for the rest as a temporary solution (during the coding period) and then move onto re-implement the rest of the project (after the summer) [The re-implementation would help in maintaining the code]. Some might comment saying " Why to reinvent the wheel if wrappers are present ?? " We had problems compiling the braid project using gcc 4.7, it worked fine using the older versions. So we cannot guarantee that wrappers would work on every system. And as mentioned above, re-implementation might help in effective maintenance of the code. So we have come to the conclusion that the code must be rewritten but it would be done in phases. If there could be a better way out, it would be of great help if we could be notified. If it turns out to be negative (in sense the license does not meet the expectations) then re-writing the entire logic would be the only option remaining.(We are losing out on wrappers for some good code for a temporary period of time). Hoping to hear from the community.Thanks. Amit. -- 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: how to install an optional spkg in the new git system?
On Sat, May 3, 2014 at 4:37 AM, leif wrote: > Volker Braun wrote: >> >> On Saturday, May 3, 2014 11:15:51 AM UTC+2, Sébastien Labbé wrote: >> >> So Sage must first be changed/updated in order to install a newly >> released package if that package uses the new git system? It adds a >> dependancy on a recent Sage version which is not necessary, no? >> >> >> On the other hand it avoids the combinatorial explosion where random >> sage/spkg combinations can't be tested. > > > http://en.wikipedia.org/wiki/Combinatorial_explosion ;-) > > The effort is at most linear in the number of Sage releases you test. > > I don't think you test even a single Sage release with all possible > combinations of k (optional/experimental) spkgs (latest version > installed/not installed => 2^k; 3^k if you'd take not installed/previous > version/brand new version). Unfortunately, I think you're right -- I'm not aware of any systematic testing of any of the optional spkg's. In fact, some optional databases don't even install right now, as they were broken by the git re-organization. I test Sage + the optional packages [1] as part of work on SageMathCloud. The test suite does not fully pass, since installing optional packages results in various little changes. Also, I have to do a few hacks to get these optional packages to install. But it comes very close. [1] SAGE_OPTIONAL_PACKAGES = [ 'biopython', 'chomp', 'database_cremona_ellcurve', 'database_odlyzko_zeta', 'database_pari', 'biopython', 'brian', 'cbc', 'cluster_seed', 'coxeter3', 'cryptominisat', 'cunningham_tables', 'database_gap', 'database_jones_numfield', 'database_kohel', 'database_symbolic_data', 'dot2tex', 'gap_packages', 'gnuplotpy', 'guppy', 'kash3', 'lie', 'lrs', 'nauty', 'normaliz', 'nose', 'nzmath', 'p_group_cohomology', 'phc', 'pybtex', 'pycryptoplus', 'pyx', 'pyzmq', 'qhull', 'topcom', 'zeromq', 'stein-watkins-ecdb' ] > > > More seriously, while it's probably ok to force people to use/install the > latest version of optional spkgs with the current [devel/stable] Sage > release they have (which is only enforced if you manually *reinstall* them > after an upgrade of Sage), it's IMHO against the philosophy of spkgs to > force people to install the latest [devel?!] version of Sage just to get an > updated/fixed optional or experimental spkg. > > And bundling the spkg metadata to specific Sage releases also makes > testing/experimenting with different spkgs usually harder. > > Not my choice. AFAIK there's not even a script to create a self-contained > "legacy" spkg from the metadata in a Sage release and the corresponding > upstream tarball, to alleviate the situation. > > > As for dot2tex (an optional spkg), although it also got upgraded (which > includes upstream fixes), compatibility with *older* Sage versions was > removed, and no updated "legacy" spkg was provided. > > > -leif > > P.S.: If people are expected to run "make distclean && make" after what > previously was just "sage -upgrade", there's not much difference to just > downloading and building the new version from scratch, probably only in > order to benefit from an updated/fixed optional spkg... > > -- > () The ASCII Ribbon Campaign > /\ Help Cure HTML E-Mail > > > -- > 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 Stein Professor of Mathematics University of Washington http://wstein.or -- 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] near-field
Hello, I would like more projective planes seen as incidence structure. In order to do so I need to introduce what are called near-field [1]. Which is not exactly a division ring: the distributivity fail on one of the side. Does anybody has some implementation already? Do you think I need a proper category for the near fields? It would be fine to me to set the category to "Rings" but perhaps it is more appropriate to have the corresponding category. Comments might also go on the ticket #16283. Best Vincent [1] http://en.wikipedia.org/wiki/Near-field_%28mathematics%29 -- 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: how to install an optional spkg in the new git system?
Volker Braun wrote: On Saturday, May 3, 2014 11:15:51 AM UTC+2, Sébastien Labbé wrote: So Sage must first be changed/updated in order to install a newly released package if that package uses the new git system? It adds a dependancy on a recent Sage version which is not necessary, no? On the other hand it avoids the combinatorial explosion where random sage/spkg combinations can't be tested. http://en.wikipedia.org/wiki/Combinatorial_explosion ;-) The effort is at most linear in the number of Sage releases you test. I don't think you test even a single Sage release with all possible combinations of k (optional/experimental) spkgs (latest version installed/not installed => 2^k; 3^k if you'd take not installed/previous version/brand new version). More seriously, while it's probably ok to force people to use/install the latest version of optional spkgs with the current [devel/stable] Sage release they have (which is only enforced if you manually *reinstall* them after an upgrade of Sage), it's IMHO against the philosophy of spkgs to force people to install the latest [devel?!] version of Sage just to get an updated/fixed optional or experimental spkg. And bundling the spkg metadata to specific Sage releases also makes testing/experimenting with different spkgs usually harder. Not my choice. AFAIK there's not even a script to create a self-contained "legacy" spkg from the metadata in a Sage release and the corresponding upstream tarball, to alleviate the situation. As for dot2tex (an optional spkg), although it also got upgraded (which includes upstream fixes), compatibility with *older* Sage versions was removed, and no updated "legacy" spkg was provided. -leif P.S.: If people are expected to run "make distclean && make" after what previously was just "sage -upgrade", there's not much difference to just downloading and building the new version from scratch, probably only in order to benefit from an updated/fixed optional spkg... -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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: how to install an optional spkg in the new git system?
On Saturday, May 3, 2014 11:15:51 AM UTC+2, Sébastien Labbé wrote: > > So Sage must first be changed/updated in order to install a newly released > package if that package uses the new git system? It adds a dependancy on a > recent Sage version which is not necessary, no? > On the other hand it avoids the combinatorial explosion where random sage/spkg combinations can't be tested. -- 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: how to install an optional spkg in the new git system?
Thanks for the answers. I also read http://trac.sagemath.org/ticket/16048 which was helpful. Your sage is probably too old and doesn't have build/pkgs/dot2tex yet? > sage-6.2-beta6 is not that old:) So Sage must first be changed/updated in order to install a newly released package if that package uses the new git system? It adds a dependancy on a recent Sage version which is not necessary, no? Sébastien -- 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.
