[sage-devel] Re: yet another talk on Sage
I think it's excellent. I laughed at the intro to the Sage definition too. Very good. Someone was just asking me a question related to the program you used to create the graph of on page 26. Is this a graph of Sage classes? What is the program/command called? Also, what font are you using? I like it. Maybe Arial or Veranda? On Mon, Nov 3, 2008 at 7:44 PM, Martin Albrecht <[EMAIL PROTECTED]> wrote: > > Hi there, > > I'll give a talk on Sage this Thursday to the PhD student seminar of the > Information Security Group here at Royal Holloway, University of London. > > Slides & demo print-out are here: > > http://sage.math.washington.edu/home/malb/egham-talk-rc0/ > > Feedback of course very welcome. > > Cheers, > Martin > > -- > name: Martin Albrecht > _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _www: http://www.informatik.uni-bremen.de/~malb > _jab: [EMAIL PROTECTED] > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.alpha2 released
On 4 Nov., 01:57, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: > On Oct 31, 2008, at 5:13 PM, mabshoff wrote: > sage -t devel/sage/sage/calculus/calculus.py > this has been reported, but I just noticed that there is > "significant bit noise", not insignificant bit noise: > Expected: > 6.1232339957367663e-16 > Got: > 6.1230317691118863e-16 > I looked into this. Short answer: The Python builtin "float(...)" sucks, the Sage builtin "RDF(...)" rules! Long answer: The command in question is (after "sage: f = 5 * sin(x)" IIRC) sage: float( f(pi) ) The precision loss thus is due to the Python builtin "float()", and possibly only so on Mac. You'll get even on a Mac the awaited-for digits by doing instead: sage: RR( f(pi) ) The mathematical correct result "0.0" is gotten by: sage: float( simplify( f(pi) ) ) and of course also by sage: RR( simplify( f(pi) ) ) But even without "simplify" you get the result "0.0" by: sage: RDF( f(pi) ) It would be a good idea not only to "just fix" the numerical noise in this doctest, but also but some (or all) of the above into doctesting "calculus.py". @Michael: My own test did not yield more issues than already reported. If the ticket you wanted to open does not appear soon, I'll open an extra one just for this "calculus.py" stuff and apply a patch to it. Cheers, gsw > Justin > > -- > Justin C. Walker, Curmudgeon-at-Large > () The ASCII Ribbon Campaign > /\ Help Cure HTML Email --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: RDF['t'] bug?
On Nov 3, 2008, at 7:39 PM, Jason Grout wrote: > Bill Hart wrote: >> sage: R.=RDF['t'] >> sage: s=1.0e1*t^3+1.0e-100*t^2+1.01234e-100*t+1.0e1 >> sage: u=1.0e1*t^3-1.0e1*t^2+1.0e1*t-1.0e1 >> sage: s*u >> 100.0*t^6 - 100.0*t^5 + 100.0*t^4 - 100.0*t^2 + 100.0*t - 100.0 >> >> What happened to the t^3 term? > > > Isn't it zero in RDF? > > sage: a0=RDF(1.0e1) > sage: a1=RDF(1.01234e-100) > sage: a2=RDF(1.0e-100) > sage: a3=RDF(1.0e1) > sage: b0=RDF(-1.0e1) > sage: b1=RDF(1.0e1) > sage: b2=RDF(-1.0e1) > sage: b3=RDF(1.0e1) > sage: # the coefficient of t^3 > sage: a0*b3 + a1*b2 + a2*b1 + a3*b0 > 0.0 > > Note that a0*b3+a3*b0 is zero (both are 100 in magnitude). However, > > sage: a2*b1 - a1*b2 > 2.01234e-99 > sage: a2*b1 - a1*b2 +1 -1 > 0.0 > > My guess is that adding 100 and subtracting 100 wipes out the > precision > and makes the resulting expression close enough to zero that it is > considered zero. > > Are you sure that RDF provides enough precision to carry out your > computation? That's almost certainly what's happening. If you do sage: sage: (s.change_ring(RealField(400)) * u.change_ring(RealField (400)))[3] -1.2339992707276099007932117842977737442427998522647464651126978 20628822244138099718572056030722800920267941116652e-101 then it gets the correct answer. Even worse is sage: (t+1e100)^2 1.0*t^2 + 1e+200 because the wrong algorithm is being used. See http:// trac.sagemath.org/sage_trac/ticket/4055 - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New software for computing automata and rewriting systems
On Mon, Nov 3, 2008 at 6:42 PM, Ronan Paixão <[EMAIL PROTECTED]> wrote: > > >> Qt was originally licensed under terms which many people considered >> not open source or not GPL compatible. I think a consequence of this >> was that the GNOME project took off in order to develop an alternative >> to the KDE desktop environment, which originally was developed with Qt >> using the above licensing terms. Fortunately (to me, at least), >> Trolltech revised the licensing terms and now Qt is GPL compatible. >> You can say that there's only one version of Qt, that's the open >> source version. If you use Qt in an open source project (that's GPL >> compatible), then you don't have to pay any cash to the company that >> owns the copyright to Qt. However, the same open source version of Qt >> can also be covered by a business license. This means that if you use >> Qt in a closed source, propriety product and you plan to distribute >> that product for royalties, then legally you must obtain a "business" >> license from the company that owns the copyright to Qt (translation: >> pay the dough to get the go). > > I've talked to a friend which works for a big company that uses Qt with > the commercial license. > > He said that, even though one making patches to the GPL version might > think that code is also GPL'd, Trolltech has the right to use that patch > as part of Qt distributed with the commercial license. I think you are completely confusing software licenses and copyright here. If you look at the Qt license it starts: TROLL TECH FREE SOFTWARE LICENSE Copyright (C) 1992-1997 Troll Tech AS. All rights reserved. See, e.g., http://www.kde.org/whatiskde/licenses/LICENSE/. This means that anything included with Qt is copyright by TrollTech. Thus presumably anybody who submits a patch for inclusion in Qt must sign over their copyright. At this point Qt can do anything they want with said code. This is a pretty common policy, e.g., the GMP library has a similar policy, as do *many* FSF projects and other projects like Python. The Linux kernel is a noticeable exception because contributors do not have to sign over copyright. -- William > He also noticed > that even though that may seem "unethical" at first, it isn't because: > 1) Who makes the patch first "takes advantage" of who made the initial > software; > 2) Who makes the patch must be aware of that before making the patch, as > it's also part of the dual-license agreement; > 3) and most important, if Trolltech thinks the patch worth it, the > patcher can be hired as a contractor to receive compensation for that > patch, and to avoid litigation. > > So, with that in mind, some stuff I said in previous e-mails may be > inaccurate (as some in this e-mail may also be, since IANAL). > > Ronan Paixão > > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: RDF['t'] bug?
On Mon, Nov 3, 2008 at 7:06 PM, Bill Hart <[EMAIL PROTECTED]> wrote: > > sage: R.=RDF['t'] This first line is wrong. It should be R. = RDF[] or R. = PolynomialRing(RDF) or R. = RDF['t'] As is, you've made the polynomial ring that prints its variable as t but is referred to as x. Here's something similar. age: R. = QQ['t'] sage: x t Who knows what you defined the t to be that you're using above? I don't. William > sage: s=1.0e1*t^3+1.0e-100*t^2+1.01234e-100*t+1.0e1 > sage: u=1.0e1*t^3-1.0e1*t^2+1.0e1*t-1.0e1 > sage: s*u > 100.0*t^6 - 100.0*t^5 + 100.0*t^4 - 100.0*t^2 + 100.0*t - 100.0 > > What happened to the t^3 term? > > Bill. > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: RDF['t'] bug?
Bill Hart wrote: > sage: R.=RDF['t'] > sage: s=1.0e1*t^3+1.0e-100*t^2+1.01234e-100*t+1.0e1 > sage: u=1.0e1*t^3-1.0e1*t^2+1.0e1*t-1.0e1 > sage: s*u > 100.0*t^6 - 100.0*t^5 + 100.0*t^4 - 100.0*t^2 + 100.0*t - 100.0 > > What happened to the t^3 term? Isn't it zero in RDF? sage: a0=RDF(1.0e1) sage: a1=RDF(1.01234e-100) sage: a2=RDF(1.0e-100) sage: a3=RDF(1.0e1) sage: b0=RDF(-1.0e1) sage: b1=RDF(1.0e1) sage: b2=RDF(-1.0e1) sage: b3=RDF(1.0e1) sage: # the coefficient of t^3 sage: a0*b3 + a1*b2 + a2*b1 + a3*b0 0.0 Note that a0*b3+a3*b0 is zero (both are 100 in magnitude). However, sage: a2*b1 - a1*b2 2.01234e-99 sage: a2*b1 - a1*b2 +1 -1 0.0 My guess is that adding 100 and subtracting 100 wipes out the precision and makes the resulting expression close enough to zero that it is considered zero. Are you sure that RDF provides enough precision to carry out your computation? Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] RDF['t'] bug?
sage: R.=RDF['t'] sage: s=1.0e1*t^3+1.0e-100*t^2+1.01234e-100*t+1.0e1 sage: u=1.0e1*t^3-1.0e1*t^2+1.0e1*t-1.0e1 sage: s*u 100.0*t^6 - 100.0*t^5 + 100.0*t^4 - 100.0*t^2 + 100.0*t - 100.0 What happened to the t^3 term? Bill. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: New software for computing automata and rewriting systems
> Qt was originally licensed under terms which many people considered > not open source or not GPL compatible. I think a consequence of this > was that the GNOME project took off in order to develop an alternative > to the KDE desktop environment, which originally was developed with Qt > using the above licensing terms. Fortunately (to me, at least), > Trolltech revised the licensing terms and now Qt is GPL compatible. > You can say that there's only one version of Qt, that's the open > source version. If you use Qt in an open source project (that's GPL > compatible), then you don't have to pay any cash to the company that > owns the copyright to Qt. However, the same open source version of Qt > can also be covered by a business license. This means that if you use > Qt in a closed source, propriety product and you plan to distribute > that product for royalties, then legally you must obtain a "business" > license from the company that owns the copyright to Qt (translation: > pay the dough to get the go). I've talked to a friend which works for a big company that uses Qt with the commercial license. He said that, even though one making patches to the GPL version might think that code is also GPL'd, Trolltech has the right to use that patch as part of Qt distributed with the commercial license. He also noticed that even though that may seem "unethical" at first, it isn't because: 1) Who makes the patch first "takes advantage" of who made the initial software; 2) Who makes the patch must be aware of that before making the patch, as it's also part of the dual-license agreement; 3) and most important, if Trolltech thinks the patch worth it, the patcher can be hired as a contractor to receive compensation for that patch, and to avoid litigation. So, with that in mind, some stuff I said in previous e-mails may be inaccurate (as some in this e-mail may also be, since IANAL). Ronan Paixão --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.alpha2 released
On Nov 3, 2008, at 5:01 PM, mabshoff wrote: > On Nov 3, 4:57 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: >> On Oct 31, 2008, at 5:13 PM, mabshoff wrote: [snip] >> sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py >> See below > Which matrix_group failure? The one mentioned just above, which I neglected to provide details for :-} Here's the scoop: File "/Users/tmp/sage-3.2.alpha2/tmp/matrix_group.py", line 667: sage: G.as_permutation_group(method="smaller") Expected: Permutation Group with generators [(1,2) (3,7,13,25,45,5,10,19,35,60)(8,16,30,41,69,11,22,40,31,54) (14,28,49,80,91,20,38,64,93,78)(17,33,57,26,48,23,43,72,36,63)(46,61) (52,73,55,76,94,67,58,70,89,81), (1,3,8,17)(2,5,11,23)(7,14)(10,20) (13,26,49,81)(16,31,55,72)(19,36,64,94)(22,41,70,57)(25,46,76,93) (28,38)(30,52,63,91)(33,58)(35,61,89,80)(40,67,48,78)(43,73)(45,69) (54,60), (1,4)(2,6)(3,9)(5,12)(7,15)(8,18)(10,21)(11,24)(13,27)(14,29) (16,32)(17,34)(19,37)(20,39)(22,42)(23,44)(25,47)(26,50)(28,51)(30,53) (31,56)(33,59)(35,62)(36,65)(38,66)(40,68)(41,71)(43,74)(45,75)(46,77) (48,79)(49,82)(52,83)(54,84)(55,85)(57,86)(58,87)(60,88)(61,90)(63,92) (64,95)(67,96)(69,97)(70,98)(72,99)(73,100)(76,101)(78,102)(80,103) (81,104)(89,105)(91,106)(93,107)(94,108)] Got: Permutation Group with generators [(1,2) (3,7,13,25,45,5,10,19,35,57)(8,16,31,56,87,11,22,41,71,91) (14,28,51,81,46,20,38,66,98,61)(17,33,59,39,69,23,43,73,29,54) (26,48,77,49,79,36,63,94,64,96)(52,83,108,123,102,67,84,110,126,88) (112,129,139,121,127,116,132,141,114,124), (1,3,8,17)(2,5,11,23) (7,14,29,48)(10,20,39,63)(13,26,49,69)(19,36,64,54)(25,46,31,57) (28,52,84,94)(35,61,41,45)(38,67,83,77)(51,59,91,116)(56,88,114,96) (66,73,87,112)(71,102,121,79)(108,124,110,127), (1,4)(2,6)(3,9)(5,12) (7,15)(8,18)(10,21)(11,24)(13,27)(14,30)(16,32)(17,34)(19,37)(20,40) (22,42)(23,44)(25,47)(26,50)(28,53)(29,55)(31,58)(33,60)(35,62)(36,65) (38,68)(39,70)(41,72)(43,74)(45,75)(46,76)(48,78)(49,80)(51,82)(52,85) (54,86)(56,89)(57,90)(59,92)(61,93)(63,95)(64,97)(66,99)(67,100) (69,101)(71,103)(73,104)(77,105)(79,106)(81,107)(83,109)(84,111) (87,113)(88,115)(91,117)(94,118)(96,119)(98,120)(102,122)(108,125) (110,128)(112,130)(114,131)(116,133)(121,134)(123,135)(124,136) (126,137)(127,138)(129,140)(132,142)(139,143)(141,144)] ** 1 items had failures: 1 of 18 in __main__.example_24 Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds If you're not confused, You're not paying attention --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.alpha2 released
On Nov 3, 4:57 pm, "Justin C. Walker" <[EMAIL PROTECTED]> wrote: > On Oct 31, 2008, at 5:13 PM, mabshoff wrote: > > > > > Hello folks, > > > here goes 3.2.alpha2 which should fix all known issues from > > 3.2.alpha1. A lot of fixes from BD 15 were merged and we are well on > > the way to the final 3.2. I plan to do another alpha3 in two days > > unless I run our of time in which case we will have the first > > 3.2.rc0. > > > Sources and a binary for sage.math are in > > > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/ > > Built on Mac OS X, 10.4.11 (Core 2 Duo) w/o problems. > > Had 5 "make -j2 test" failures: > > sage -t devel/sage/sage/calculus/calculus.py > this has been reported, but I just noticed that there is > "significant bit noise", not insignificant bit noise: > Expected: > 6.1232339957367663e-16 > Got: > 6.1230317691118863e-16 Ouch. > sage -t devel/sage/sage/calculus/wester.py > Reported > sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py > See below > sage -t devel/sage/sage/matrix/matrix_complex_double_dense.pyx > Reported > sage -t devel/sage/sage/matrix/matrix_real_double_dense.pyx > Reported > > Regarding the matrix_group failure, it comes up with a different set > of generators than expected. The odd thing is that when I run this > test separately, it passes. Which matrix_group failure? > Justin Cheers, Michael > -- > Justin C. Walker, Curmudgeon-at-Large > () The ASCII Ribbon Campaign > /\ Help Cure HTML Email --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.alpha2 released
On Oct 31, 2008, at 5:13 PM, mabshoff wrote: > > Hello folks, > > here goes 3.2.alpha2 which should fix all known issues from > 3.2.alpha1. A lot of fixes from BD 15 were merged and we are well on > the way to the final 3.2. I plan to do another alpha3 in two days > unless I run our of time in which case we will have the first > 3.2.rc0. > > Sources and a binary for sage.math are in > > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2/ Built on Mac OS X, 10.4.11 (Core 2 Duo) w/o problems. Had 5 "make -j2 test" failures: sage -t devel/sage/sage/calculus/calculus.py this has been reported, but I just noticed that there is "significant bit noise", not insignificant bit noise: Expected: 6.1232339957367663e-16 Got: 6.1230317691118863e-16 sage -t devel/sage/sage/calculus/wester.py Reported sage -t devel/sage/sage/groups/matrix_gps/matrix_group.py See below sage -t devel/sage/sage/matrix/matrix_complex_double_dense.pyx Reported sage -t devel/sage/sage/matrix/matrix_real_double_dense.pyx Reported Regarding the matrix_group failure, it comes up with a different set of generators than expected. The odd thing is that when I run this test separately, it passes. Justin -- Justin C. Walker, Curmudgeon-at-Large () The ASCII Ribbon Campaign /\ Help Cure HTML Email --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] yet another talk on Sage
Hi there, I'll give a talk on Sage this Thursday to the PhD student seminar of the Information Security Group here at Royal Holloway, University of London. Slides & demo print-out are here: http://sage.math.washington.edu/home/malb/egham-talk-rc0/ Feedback of course very welcome. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: how to clone the documentation repository
Patch(es) at #4370 ready for review. Cheers, gsw On 26 Okt., 14:21, "John Cremona" <[EMAIL PROTECTED]> wrote: > It is now #4370. > > John > > 2008/10/26 mabshoff <[EMAIL PROTECTED]>: > > > > > Minh Nguyen wrote: > >> Hi folks, > > >> As explained in the "Sage Developer's Guide", it's very easy to clone > >> the sage-main repo in order to have a repo for one's own development. > >> Cloning this repo is painless since all one needs to do is something > >> like this: > > >> sage -clone my-repo > > >> Is there a corresponding command or process that I can use to clone the > >> doc-main repo as well? > > >> Whenever I review the official documentation that's shipped with each > >> Sage release, I would go into > > >> /devel/doc-main > > >> and then review the documentation from there. If I'm reviewing someone's > >> patch to any file in the latter directory, I would not clone doc-main > >> (since I don't yet know how to do that). Instead, I would go ahead with > >> applying the patch and then do more review of the patch. At this point, > >> at least one of two things can happen: > > >> [1] If the patch gets a positive review, then all is fine and good. > > >> [2] However, in case there's something wrong with the patched file and I > >> want to un-apply the patch, I would do this: > > >> sage: hg_doc.revert() > > >> This command reverts back to the stage at which the file in question is > >> unpatched. > > >> Another possibility is for me to copy a source distro to more than one > >> directory, and then build (and test) the distro from those different > >> directories. That way, I would have a copy of Sage that I can use and > >> with which I won't apply any documentation patches. And I would also > >> have another copy of Sage for applying documentation patches. Building > >> one copy of a source distro usually takes a _very_ long time on each > >> machine that I have access to --- and running all standard tests further > >> add to my waiting time. As you can imagine, repeating the build and test > >> processes on the same machine for another copy of the same source distro > >> would further add to the waiting time. (Man, I can't wait to work on > >> Sage ;-) > > > Hi Minh, > > > it is fairly simple to add a clone command for the doc repo. If you > > want it just open a ticket and someone will take care of it. You can > > even try yourself - just look at local/bin/sage-clone and ignore > > nearly everything toward the end since that deals with build file > > issues. > > >> -- > >> Regards > >> Minh Van Nguyen > > > Cheers, > > > Michael > > >> Web:http://nguyenminh2.googlepages.com > >> Blog:http://mvngu.wordpress.com --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage benchmarks on website
Hi, I have the idea to create a website for sage benchmarks. It will be part of the "tour" and you can see a stub here: http://sagemath.org/tour-benchmarks.html Therefore I want to collect some examples that show what Sage can do really fast. I can remember the PartitionsP function, polynomials, bernoulli, ... Would be great if you help my by providing some some code examples, timings + short computer specifications and a small explanation if it is not too trivial. Also, a link to something that is already written would be also ok (even better, since it serves as an external reference). It's probably also nice to include the name of the package that provides that functionality, if applicable. Additionally, one thing that should not be missing is something about the new symbolics code. greetings harald --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
Hi John, To give a bit more weight to the counterargument against the alphabetti solution: > I agree, and I did not really mean my alphabetti suggestion to be > taken too seriously. In some version, there was an invasive declaration of single character symbols to be symbolic elements. This caused me all sorts of grief when I forgot to declare some variable, I would get an error message far down the line at some completely irrelevant place. I complained and this "feature" was removed (so blame me Chris). For the same reason I voted to leave QQ, RR, and CC, and remove predefinition of Q, R, and C (originally Q == QQ, etc.). If I forget to declare a variable, I want to see it as soon as I try to use it. Since you declare x to be in Qx in your startup file, you don't see the problem, but symbolic variables are viral: if another generator interacts with one it gets the symbolic virus. The current symbolics package supports a lot of features (which wasn't always the case) so maybe the "typical" user won't notice a problem, however this is one instance where one can easily pass over to the symbolics world: sage: P. = PolynomialRing(QQ); sage: X + x X + x sage: f = X^2 - x^2 sage: f.factor() (X - x)*(X + x) sage: f.parent() Symbolic Ring sage: X = f.parent()(X) sage: type(X) sage: type(f.factor()) sage: fac = (1/f).factor() sage: fac == 1/f 1/((X - x)*(X + x)) == 1/(X^2 - x^2) sage: f.is_unit() ... Not implemented error The sorts of questions and functionality one asks the symbolics variables are not the same questions one asks an element of a polynomial ring or of a function field element. Stumbling into this world by mistake because someone predefined a bunch of variables for me was a real headache. SAGE is doing remarkably well at keeping a balance between ease-of- use for beginners and high-end users. --David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patches for the calculus code
On 2 Nov., 12:10, Wilfried_Huss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have written some code for the Maxima interface.
> You can find the patches at:
> http://www.math.tugraz.at/~huss/sage
>
> calculus1.patch implements the conversion from Maxima
> matrices to Sage matrices.
This is now: #4431
> calculus2.patch adds symbolic gamma and factorial functions.
> (The factorial is named fact() so it doesn't clash with the
> factorial in sage.rings.arith)
This is now: #4432
> Finally calculus3.patch renames the symbolic factorial to factorial(),
> and changes all imports of sage.rings.arith.factorial to
> sage.calculus.calculus.factorial. I had to keep a renamed version
> of the factorial function in sage.rings.arith to avoid circular
> imports at startup.
This is now: #4433
> The patches are against 3.2-alpha1, after applying all 3 patches
> all tests passed.
>
> Here is a sample session with the new functionality:
>
> sage: var('x,y')
> sage: v = maxima('v: vandermonde_matrix([x, y, 1/2])')
> sage: v
> matrix([1,x,x^2],[1,y,y^2],[1,1/2,1/4])
> sage: type(v)
>
> sage: v.sage()
>
> [ 1 x x^2]
> [ 1 y y^2]
> [ 1 1/2 1/4]
> sage: mlist = maxima('[v, sin(x), 1, v.v]').sage()
> sage: mlist
>
> [[ 1 x x^2]
> [ 1 y y^2]
> [ 1 1/2 1/4],
> sin(x),
> 1,
> [ x^2 + x + 1 x*y + x^2/2 + x x*y^2 + 5*x^2/4]
> [ y^2 + y + 1 3*y^2/2 + x y^3 + y^2/4 + x^2]
> [ 7/4 y/2 + x + 1/8 y^2/2 + x^2 + 1/16]]
> sage: [parent(i) for i in mlist]
>
> [Full MatrixSpace of 3 by 3 dense matrices over Symbolic Ring,
> Symbolic Ring,
> Symbolic Ring,
> Full MatrixSpace of 3 by 3 dense matrices over Symbolic Ring]
>
> sage: gamma(x/2)(x=5)
> 3*sqrt(pi)/4
>
> sage: f = factorial(x + factorial(y))
> sage: maxima(f).sage()
> factorial(factorial(y) + x)
>
> sage: f(y=x)(x=3)
> 362880
>
> I hope it is useful.
>
> Greetings,
> Wilfried Huss
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: NIST Digital Library of Mathematical Functions
On Nov 3, 2008, at 9:46 AM, Jason Grout wrote: > Apparently some people are writing a replacement for Abramowitz and > Stegun's Handbook of Mathematical Functions with Formulas, Graphs, and > Mathematical Tables. The first preview of five chapters is here: > http://dlmf.nist.gov/ > > I noticed that the appendix on Software has maxima, pari/gp, mma, > maple, > matlab, etc., but not Sage. I don't know who would be the one to > contact the editors, but it might be worth it to get Sage mentioned > and > included in the tables, especially if this book takes on the > stature and > longevity of the Abramowitz and Stegun's book. > > The software list is here: http://dlmf.nist.gov/software/ > > They have a special category for open source software, which is nice. Interesting. I think Sage definitely belongs on this list, and could probably fill out the entire line of functionality (or at least close). - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hilbert Class Polynomial function in SAGE...
On Nov 3, 2008, at 6:20 AM, eduardo wrote: > Hi there! > > I attended the SAGE DAYS 10 in Nancy (Thanks the people there for > everything!). As other colleague and me are interested in crypto > interesting Elliptic Curves, we noticed that the SAGE function that > calculates the Hilbert class polynomial needs magma, so we proposed at > the > Coding Sprint the implementation of this function, for instance with > CM > Methods or/and the CRT Methods. After some time spending on it we got > some issues that surely can be corrected with some help/discussion: > > We implemented the CM-version of it in purely sage-python code. > Comparing timings with Magma our implementation was almost (here)- > times > slower. So we can emphasize 3 bottlenecks apart from computation of a > j-Invariant: the computation of the appropriate precision, generating > of all > different reduced primitive quadratic forms and the using of Python. > > 1. An idea of the computation of the appropriate precision we > gathered > from Andreas Enge's article [http://hal.inria.fr/inria-1040]. He > gives > an upper bound for the size of the largest coefficient of the > polynomial. > > 2. To generate all reduced primitive quadratic forms we used first the > function > called BinaryQF_reduced_representatives() from quadratic forms > library. After > that we implemented our version of this function and got about 50% > speed up, > and the present code doesn't generate primitive forms if the > discriminant is > non-fundamental. > > 3. But anyway our implementation was a snail comparing to magma's one. > And then > we tried to use Cython to implement the same function. As a result > our > implementation was a bit faster than magma's at least in experiments > we ran. > The only thing worried us was the using of type long long for > discriminant of > quadratic field. It means the input parameter is bounded by 2^63. It > is > O.K. for D around -2^63; even magma will break down since the > complexity > of the algorithm is O(|D|). > > Now I would like to ask some questions: > * Shall we consider the bigger value of D then values fit in long > long? No idea what your constants are like, but 2^63 nanoseconds is something like 290 years, so on face value that seems prohibitively expensive without some massive parallelization of some sort (which would probably require a complete rewrite of your algorithm.) However, if I remember correctly the runtime depended on the factorization of D, not just the size of D itself. What I would suggest is keeping the long-long version, as that is probably the most useful useful case, and the speed improvements are huge. One could also have the mpz version as well, only called when needed. > * Is it safe to use long long? Is it 64-bit on all platforms? Does > Cython care about that? long long always has at least 64 bits, and is required on all platforms we target for Sage, so it is safe to use that. > * We can perhaps use mpz_t (from GMP) instead of long long. Then we > need to know how can we input/ouput a variable of this type in > Cython. Is there some documentation about that? Here is how you would do it (the easy way): from sage.rings.integer cimport Integer def add_via_gmp(Integer a, Integer b): cdef Integer z = PY_NEW(Integer) mpz_add(z.value, a.value, b.value) return z There is also the issue of memory management (if one needs temporary mpz_t values) and the code is much harder to read/debug. Of course, 99% of the savings would be accomplished by just moving the inner loop or two to use the mpz_* functions directly, so writing the whole function this way would be overkill. The speed of this implementation would almost certainly be closer to the speed of the Python version than to the speed of the long-long version, as mpz_t arithmetic is many, many times slower than manipulating long-longs. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] NIST Digital Library of Mathematical Functions
Apparently some people are writing a replacement for Abramowitz and Stegun's Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables. The first preview of five chapters is here: http://dlmf.nist.gov/ I noticed that the appendix on Software has maxima, pari/gp, mma, maple, matlab, etc., but not Sage. I don't know who would be the one to contact the editors, but it might be worth it to get Sage mentioned and included in the tables, especially if this book takes on the stature and longevity of the Abramowitz and Stegun's book. The software list is here: http://dlmf.nist.gov/software/ They have a special category for open source software, which is nice. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patches for the calculus code
On Nov 3, 2008, at 2:23 AM, Wilfried_Huss wrote: > On 2 Nov., 20:46, mabshoff <[EMAIL PROTECTED]> wrote: >> On Nov 2, 11:38 am, "William Stein" <[EMAIL PROTECTED]> wrote: >> >>> On Sun, Nov 2, 2008 at 3:10 AM, Wilfried_Huss I have written some code for the Maxima interface. You can find the patches at: http://www.math.tugraz.at/~huss/sage >> calculus1.patch implements the conversion from Maxima matrices to Sage matrices. >> >> This should come in handy, but starting with 3.2 we will finally have >> pynac available for some of the basic symbolic manipulation tasks. It >> is far from bullet proof, but it is a start, so the days of Maxima as >> the default implementation of the low level symbolic stuff is coming >> finally to an end :) > > Yes, but as far as I understand Maxima will still be used for the high > level > symbolic stuff for the foreseeable future. So I think it makes sense > to have > the conversions between Sage and Maxima as complete as possible. Yes, and even when it's not called in the background for a lot of stuff, it will be very useful to have good conversion routines. For example, right now there is a lot of hard work going on to improve the sage-magma interface despite the fact that magma is an optional package. calculus2.patch adds symbolic gamma and factorial functions. (The factorial is named fact() so it doesn't clash with the factorial in sage.rings.arith) >> >> Provided the factorial bit does not interfere with the current non- >> symbolic code this could be useful. >> Finally calculus3.patch renames the symbolic factorial to factorial(), and changes all imports of sage.rings.arith.factorial to sage.calculus.calculus.factorial. I had to keep a renamed version of the factorial function in sage.rings.arith to avoid circular imports at startup. >> >> I don't like this patch at all since it forces us to use a Maxima >> function even for integers which ought to be the most common use of >> factorial. > > But it doesn't use Maxima for non-symbolic input. > > Just as before factorial(x) just tries to call > > x.factorial() > > only if this raises an exception the symbolic version is > constructed. > > sage: def f(n): > sage: s = 0 > sage: for i in xrange(n): > sage: s += factorial(2^i) > sage: return s.ndigits() > > sage: time f(22) > 12346641 > CPU time: 10.89 s, Wall time: 10.94 s > > This is the same with or without the patch. That sounds very good. Did you make a ticket? - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hilbert Class Polynomial function in SAGE...
2008/11/3 Kiran Kedlaya <[EMAIL PROTECTED]>: > > For the record, Drew Sutherland (cc'd on this) has some screamingly > fast code for the CRT method, which he spoke about at ECC this year. Written in what? C? John > > Kiran > > eduardo wrote: >> Hi there! >> >> I attended the SAGE DAYS 10 in Nancy (Thanks the people there for >> everything!). As other colleague and me are interested in crypto >> interesting Elliptic Curves, we noticed that the SAGE function that >> calculates the Hilbert class polynomial needs magma, so we proposed at >> the >> Coding Sprint the implementation of this function, for instance with >> CM >> Methods or/and the CRT Methods. After some time spending on it we got >> some issues that surely can be corrected with some help/discussion: >> >> We implemented the CM-version of it in purely sage-python code. >> Comparing timings with Magma our implementation was almost (here)- >> times >> slower. So we can emphasize 3 bottlenecks apart from computation of a >> j-Invariant: the computation of the appropriate precision, generating >> of all >> different reduced primitive quadratic forms and the using of Python. >> >> 1. An idea of the computation of the appropriate precision we >> gathered >> from Andreas Enge's article [http://hal.inria.fr/inria-1040]. He >> gives >> an upper bound for the size of the largest coefficient of the >> polynomial. >> >> 2. To generate all reduced primitive quadratic forms we used first the >> function >> called BinaryQF_reduced_representatives() from quadratic forms >> library. After >> that we implemented our version of this function and got about 50% >> speed up, >> and the present code doesn't generate primitive forms if the >> discriminant is >> non-fundamental. >> >> 3. But anyway our implementation was a snail comparing to magma's one. >> And then >> we tried to use Cython to implement the same function. As a result >> our >> implementation was a bit faster than magma's at least in experiments >> we ran. >> The only thing worried us was the using of type long long for >> discriminant of >> quadratic field. It means the input parameter is bounded by 2^63. It >> is >> O.K. for D around -2^63; even magma will break down since the >> complexity >> of the algorithm is O(|D|). >> >> Now I would like to ask some questions: >> * Shall we consider the bigger value of D then values fit in long >> long? >> * Is it safe to use long long? Is it 64-bit on all platforms? >> Does Cython care about that? >> * We can perhaps use mpz_t (from GMP) instead of long long. Then we >> need >> to know how can we input/ouput a variable of this type in Cython. Is >> there >> some documentation about that? >> >> thanks in Advance! >> >> cheers >> Ed > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hilbert Class Polynomial function in SAGE...
For the record, Drew Sutherland (cc'd on this) has some screamingly fast code for the CRT method, which he spoke about at ECC this year. Kiran eduardo wrote: > Hi there! > > I attended the SAGE DAYS 10 in Nancy (Thanks the people there for > everything!). As other colleague and me are interested in crypto > interesting Elliptic Curves, we noticed that the SAGE function that > calculates the Hilbert class polynomial needs magma, so we proposed at > the > Coding Sprint the implementation of this function, for instance with > CM > Methods or/and the CRT Methods. After some time spending on it we got > some issues that surely can be corrected with some help/discussion: > > We implemented the CM-version of it in purely sage-python code. > Comparing timings with Magma our implementation was almost (here)- > times > slower. So we can emphasize 3 bottlenecks apart from computation of a > j-Invariant: the computation of the appropriate precision, generating > of all > different reduced primitive quadratic forms and the using of Python. > > 1. An idea of the computation of the appropriate precision we > gathered > from Andreas Enge's article [http://hal.inria.fr/inria-1040]. He > gives > an upper bound for the size of the largest coefficient of the > polynomial. > > 2. To generate all reduced primitive quadratic forms we used first the > function > called BinaryQF_reduced_representatives() from quadratic forms > library. After > that we implemented our version of this function and got about 50% > speed up, > and the present code doesn't generate primitive forms if the > discriminant is > non-fundamental. > > 3. But anyway our implementation was a snail comparing to magma's one. > And then > we tried to use Cython to implement the same function. As a result > our > implementation was a bit faster than magma's at least in experiments > we ran. > The only thing worried us was the using of type long long for > discriminant of > quadratic field. It means the input parameter is bounded by 2^63. It > is > O.K. for D around -2^63; even magma will break down since the > complexity > of the algorithm is O(|D|). > > Now I would like to ask some questions: > * Shall we consider the bigger value of D then values fit in long > long? > * Is it safe to use long long? Is it 64-bit on all platforms? > Does Cython care about that? > * We can perhaps use mpz_t (from GMP) instead of long long. Then we > need > to know how can we input/ouput a variable of this type in Cython. Is > there > some documentation about that? > > thanks in Advance! > > cheers > Ed --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.alpha2 released
On here: Linux version 2.6.16.60-0.31-smp ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (SUSE Linux)) #1 SMP Tue Oct 7 16:16:29 UTC 2008 I get doctest failures in these: sage -t devel/sage/sage/calculus/calculus.py sage -t devel/sage/sage/matrix/matrix_real_double_dense.pyx sage -t devel/sage/sage/matrix/matrix_complex_double_dense.pyx which I think have all been seen before. they all look like "noise" issues. John 2008/11/2 Jaap Spies <[EMAIL PROTECTED]>: > > mabshoff wrote: >> > >> >> Ok, I am about to open tickets and post patches for all the numerical >> noise I have seen on x86, x86-64, Itanium and a G5. >> > > On Fedora 9, 32 bits: > -- > The following tests failed: > > >sage -t devel/sage/sage/graphs/graph.py >sage -t devel/sage/sage/calculus/calculus.py > > > sage -t devel/sage/sage/graphs/graph.py > File "/home/jaap/downloads/sage-3.2.alpha2/tmp/graph.py", line 5802: > sage: P.spectrum(laplacian=True) > Expected: > [...e-16, 2.0, 2.0, 2.0, 2.0, 2.0, 5.0, 5.0, 5.0, 5.0] > Got: > [-4.96798817464e-17, 2.0, 2.0, 2.0, 2.0, 2.0, 5.0, 5.0, 5.0, 5.0] > ** > > > All known numerical noise issues, I suppose. > > Jaap > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
On Mon, Nov 3, 2008 at 8:05 AM, Robert Dodier <[EMAIL PROTECTED]> wrote: > > William Stein wrote: > >> Incidentally, if we did allow automatic creation of symbolic >> variables, and default calling of symbolic expressions, then >> doing something like this would happen >> all the time and confuse the crap out of people: >> >> sage: function_name_with_slight_typo(10) >> 10 > > Well, that's weird, but it's not weird because of automatically > creating a variable for function_name_with_slight_typo. > Calling symbolic expressions -- that's weird. Would you consider this weird if you read it in a paper, or would you know how to interpret it? "Let $f = x^3 + x + 1$ and consider $f(10)$." >> I think it would be interesting to have at least the capability >> of a mode where variable names are made symbolic if >> not previously used, at least if the calling behavior were redefined >> as above. This would have be done by somehow parsing the >> input, finding all undefined variables, defining them, etc >> It's techincaly possible. Maybe Fernando Perez and I can >> try to make a demo of something like this at Sage Days 11. > > I would be inclined to plug in a custom top-level interpreter loop > which just catches NameError and instantiates suitable variables > and reevaluates the input when that happens. Is there a way to > get Python to parse the input without evaluating it? (Isn't there > an AST package or s.t.l.t. which could do that?) Then you could > (I guess) detect undefined variables without causing side-effects > from any part of the input. Just a guess -- I'm no expert on Python. Those are two good ideas to try. Obviously, as you say, the parsing one is better since it avoids nasty confusing side effects that catching NameError's would result in. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Why Sage needs var(...) commands unlike Mathematica?
William Stein wrote: > Incidentally, if we did allow automatic creation of symbolic > variables, and default calling of symbolic expressions, then > doing something like this would happen > all the time and confuse the crap out of people: > > sage: function_name_with_slight_typo(10) > 10 Well, that's weird, but it's not weird because of automatically creating a variable for function_name_with_slight_typo. Calling symbolic expressions -- that's weird. > I think it would be interesting to have at least the capability > of a mode where variable names are made symbolic if > not previously used, at least if the calling behavior were redefined > as above. This would have be done by somehow parsing the > input, finding all undefined variables, defining them, etc > It's techincaly possible. Maybe Fernando Perez and I can > try to make a demo of something like this at Sage Days 11. I would be inclined to plug in a custom top-level interpreter loop which just catches NameError and instantiates suitable variables and reevaluates the input when that happens. Is there a way to get Python to parse the input without evaluating it? (Isn't there an AST package or s.t.l.t. which could do that?) Then you could (I guess) detect undefined variables without causing side-effects from any part of the input. Just a guess -- I'm no expert on Python. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hilbert Class Polynomial function in SAGE...
On Monday 03 November 2008, eduardo wrote: > * We can perhaps use mpz_t (from GMP) instead of long long. Then we > need to know how can we input/ouput a variable of this type in Cython. Is > there some documentation about that? Hi there, AFAIK there is no documentation as such but plenty of examples. Note, that Sage integers are basically mpz_t. See sage.rings.integer.pyx for details. In particular there are C functions to get/set mpz_ts from/for Integers. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Hilbert Class Polynomial function in SAGE...
Just one comment, about your use of BinaryQF_reduced_representatives() . There are patches undergoing review now relevant to this (at #4120). That function was made a lot more efficient in #3857 (now merged) but that function returns a list of the representative forms, while you only need the number. The patch at #4120 has a function to give the number but unfortunately does not use the speedups implemented (by be and then Nils Skoruppa) in #3857. For such a critical function I am sure that it should be implemented in cython anyway. John 2008/11/3 eduardo <[EMAIL PROTECTED]>: > > Hi there! > > I attended the SAGE DAYS 10 in Nancy (Thanks the people there for > everything!). As other colleague and me are interested in crypto > interesting Elliptic Curves, we noticed that the SAGE function that > calculates the Hilbert class polynomial needs magma, so we proposed at > the > Coding Sprint the implementation of this function, for instance with > CM > Methods or/and the CRT Methods. After some time spending on it we got > some issues that surely can be corrected with some help/discussion: > > We implemented the CM-version of it in purely sage-python code. > Comparing timings with Magma our implementation was almost (here)- > times > slower. So we can emphasize 3 bottlenecks apart from computation of a > j-Invariant: the computation of the appropriate precision, generating > of all > different reduced primitive quadratic forms and the using of Python. > > 1. An idea of the computation of the appropriate precision we > gathered > from Andreas Enge's article [http://hal.inria.fr/inria-1040]. He > gives > an upper bound for the size of the largest coefficient of the > polynomial. > > 2. To generate all reduced primitive quadratic forms we used first the > function > called BinaryQF_reduced_representatives() from quadratic forms > library. After > that we implemented our version of this function and got about 50% > speed up, > and the present code doesn't generate primitive forms if the > discriminant is > non-fundamental. > > 3. But anyway our implementation was a snail comparing to magma's one. > And then > we tried to use Cython to implement the same function. As a result > our > implementation was a bit faster than magma's at least in experiments > we ran. > The only thing worried us was the using of type long long for > discriminant of > quadratic field. It means the input parameter is bounded by 2^63. It > is > O.K. for D around -2^63; even magma will break down since the > complexity > of the algorithm is O(|D|). > > Now I would like to ask some questions: > * Shall we consider the bigger value of D then values fit in long > long? > * Is it safe to use long long? Is it 64-bit on all platforms? > Does Cython care about that? > * We can perhaps use mpz_t (from GMP) instead of long long. Then we > need > to know how can we input/ouput a variable of this type in Cython. Is > there > some documentation about that? > > thanks in Advance! > > cheers > Ed > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Hilbert Class Polynomial function in SAGE...
Hi there! I attended the SAGE DAYS 10 in Nancy (Thanks the people there for everything!). As other colleague and me are interested in crypto interesting Elliptic Curves, we noticed that the SAGE function that calculates the Hilbert class polynomial needs magma, so we proposed at the Coding Sprint the implementation of this function, for instance with CM Methods or/and the CRT Methods. After some time spending on it we got some issues that surely can be corrected with some help/discussion: We implemented the CM-version of it in purely sage-python code. Comparing timings with Magma our implementation was almost (here)- times slower. So we can emphasize 3 bottlenecks apart from computation of a j-Invariant: the computation of the appropriate precision, generating of all different reduced primitive quadratic forms and the using of Python. 1. An idea of the computation of the appropriate precision we gathered from Andreas Enge's article [http://hal.inria.fr/inria-1040]. He gives an upper bound for the size of the largest coefficient of the polynomial. 2. To generate all reduced primitive quadratic forms we used first the function called BinaryQF_reduced_representatives() from quadratic forms library. After that we implemented our version of this function and got about 50% speed up, and the present code doesn't generate primitive forms if the discriminant is non-fundamental. 3. But anyway our implementation was a snail comparing to magma's one. And then we tried to use Cython to implement the same function. As a result our implementation was a bit faster than magma's at least in experiments we ran. The only thing worried us was the using of type long long for discriminant of quadratic field. It means the input parameter is bounded by 2^63. It is O.K. for D around -2^63; even magma will break down since the complexity of the algorithm is O(|D|). Now I would like to ask some questions: * Shall we consider the bigger value of D then values fit in long long? * Is it safe to use long long? Is it 64-bit on all platforms? Does Cython care about that? * We can perhaps use mpz_t (from GMP) instead of long long. Then we need to know how can we input/ouput a variable of this type in Cython. Is there some documentation about that? thanks in Advance! cheers Ed --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Links between worksheets
I have a question about hyperlinks between worksheets. I am trying to convert my open-source linear algebra textbook (http:// linear.ups.edu/) into a group of Sage worksheets. Right now, I convert the LaTeX for each of the 50 or so sections into its own page of XHTML that is acceptable to jsMath (conversion via the ht4tex tool). It is relatively easy to convert these into Sage worksheets that render perfectly. Long-term I would like to add "live" Sage code to my LaTeX sources and have them migrate to the worksheets as cells, demonstrating the use of Sage for the relevant aspects of linear algebra. The end result would be a "Sage-enhanced" version of the book. I use extensive hyperlinks to reference between definitions, theorems and proofs. Within a worksheet (one section in the book) these work fine. I've done some experiments, making minor edits by hand to convert to worksheets. But no matter what I try, when a link points to a different worksheet and is clicked on, the new worksheet gets loaded but the page does not position itself at the target location in the new worksheet. I have been able hack up a pair of small demonstration worksheets, and make linking work properly with HTML tags (using name="" for the target). In the XHTML/jsMath pages produced by tex4ht, the targets are specified with id="", and it seems that the use of name="" is no longer acceptable in XHTML (and doesn't seem to work anyway). I'd appreciate any advice, hints or pointers on how to accomplish this type of cross-worksheet linking with XHTML in the worksheets. Examples of the types of pages I'm planning to convert can be found starting at http://linear.ups.edu/jsmath/latest/fcla-jsmath-latest.html The links all have filenames in them which will need to be converted as well, but they should be easy to parse with sed or a script. In my experiments, I've edited those out by hand and basically replaced with them with worksheet numbers. Thanks, Rob --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patches for the calculus code
On 2 Nov., 20:46, mabshoff <[EMAIL PROTECTED]> wrote:
> On Nov 2, 11:38 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Nov 2, 2008 at 3:10 AM, Wilfried_Huss
>
> Hi,
>
>
>
> > <[EMAIL PROTECTED]> wrote:
>
> > > Hi,
>
> > > I have written some code for the Maxima interface.
> > > You can find the patches at:
> > > http://www.math.tugraz.at/~huss/sage
>
> > > calculus1.patch implements the conversion from Maxima
> > > matrices to Sage matrices.
>
> This should come in handy, but starting with 3.2 we will finally have
> pynac available for some of the basic symbolic manipulation tasks. It
> is far from bullet proof, but it is a start, so the days of Maxima as
> the default implementation of the low level symbolic stuff is coming
> finally to an end :)
Yes, but as far as I understand Maxima will still be used for the high
level
symbolic stuff for the foreseeable future. So I think it makes sense
to have
the conversions between Sage and Maxima as complete as possible.
> > > calculus2.patch adds symbolic gamma and factorial functions.
> > > (The factorial is named fact() so it doesn't clash with the
> > > factorial in sage.rings.arith)
>
> Provided the factorial bit does not interfere with the current non-
> symbolic code this could be useful.
>
> > > Finally calculus3.patch renames the symbolic factorial to factorial(),
> > > and changes all imports of sage.rings.arith.factorial to
> > > sage.calculus.calculus.factorial. I had to keep a renamed version
> > > of the factorial function in sage.rings.arith to avoid circular
> > > imports at startup.
>
> I don't like this patch at all since it forces us to use a Maxima
> function even for integers which ought to be the most common use of
> factorial.
But it doesn't use Maxima for non-symbolic input.
Just as before factorial(x) just tries to call
x.factorial()
only if this raises an exception the symbolic version is
constructed.
sage: def f(n):
sage: s = 0
sage: for i in xrange(n):
sage: s += factorial(2^i)
sage: return s.ndigits()
sage: time f(22)
12346641
CPU time: 10.89 s, Wall time: 10.94 s
This is the same with or without the patch.
> When the point counting code was using Maxima to compute
> ceil, floor and sqrt the code as a whole was slower by a factor of
> three which illustrates nicely why we don't want to use Maxima unless
> there is a good reason to do so. Especially considering that using
> mpfr's functions was abotu a million times faster since there is no
> pexpect overhead. I could see using that code in case the argument is
> non-integer, but not using the highly optimized gmp implementation for
> something that is many orders of magnitude slower is just not what we
> want to do.
>
> Cheers,
>
> Michael
>
> > > The patches are against 3.2-alpha1, after applying all 3 patches
> > > all tests passed.
>
> > > Here is a sample session with the new functionality:
>
> > > sage: var('x,y')
> > > sage: v = maxima('v: vandermonde_matrix([x, y, 1/2])')
> > > sage: v
> > > matrix([1,x,x^2],[1,y,y^2],[1,1/2,1/4])
> > > sage: type(v)
> > >
> > > sage: v.sage()
>
> > > [ 1 x x^2]
> > > [ 1 y y^2]
> > > [ 1 1/2 1/4]
> > > sage: mlist = maxima('[v, sin(x), 1, v.v]').sage()
> > > sage: mlist
>
> > > [[ 1 x x^2]
> > > [ 1 y y^2]
> > > [ 1 1/2 1/4],
> > >sin(x),
> > >1,
> > >[ x^2 + x + 1x*y + x^2/2 + xx*y^2 + 5*x^2/4]
> > > [ y^2 + y + 13*y^2/2 + x y^3 + y^2/4 + x^2]
> > > [ 7/4 y/2 + x + 1/8 y^2/2 + x^2 + 1/16]]
> > > sage: [parent(i) for i in mlist]
>
> > > [Full MatrixSpace of 3 by 3 dense matrices over Symbolic Ring,
> > >Symbolic Ring,
> > >Symbolic Ring,
> > >Full MatrixSpace of 3 by 3 dense matrices over Symbolic Ring]
>
> > > sage: gamma(x/2)(x=5)
> > > 3*sqrt(pi)/4
>
> > > sage: f = factorial(x + factorial(y))
> > > sage: maxima(f).sage()
> > > factorial(factorial(y) + x)
>
> > > sage: f(y=x)(x=3)
> > > 362880
>
> > > I hope it is useful.
>
> > > Greetings,
> > > Wilfried Huss
>
> > Thanks! Could you write to Michael Abshoff (<[EMAIL PROTECTED]>) and ask
> > for a trac account, then open three trac tickets, one
> > for each of the above? Thanks again!
>
> > William
Greetings,
Wilfried
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: patches for the calculus code
> > Thanks! Could you write to Michael Abshoff (<[EMAIL PROTECTED]>) and ask > for a trac account, then open three trac tickets, one > for each of the above? Thanks again! Yes, I just did. Greetings, Wilfried --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
