I agree with the teaching and research justifying a slow implementation. But in the not so distant future when every one is making Cython wrappers of their c code and placing their code in SAGE won't it then be a problem with duplication of functionality? Couldn't a lot of similar functions "water down" the whole quality of SAGE?
Is there a defined group of people to join on getting the pbc library into SAGE? /David On 13 Nov., 17:12, "William Stein" <[EMAIL PROTECTED]> wrote: > On Thu, Nov 13, 2008 at 8:02 AM, David Møller Hansen > > <[EMAIL PROTECTED]> wrote: > > > Good point on the multi-user system. Maybe a script is the best way to > > go about the problem of initializing the signature scheme for my > > thesis professors. > > > I will gladly contribute, but I'm guessing that my code will be pretty > > obsolete when the pbc library is ported into SAGE... > > > - I'll just have to be fast then :-) > > 1. There is value to having a native Sage implementation of algorithms, > even if it is slower, since it can be more flexible and useful for teaching > and some research purposes. > > 2. Maybe you could help with getting "the pbc library is ported into SAGE", > which might mean making a Cython wrapper for it. > > > > > > > Thank you for your advice. > > > /David > > > On 13 Nov., 15:28, "William Stein" <[EMAIL PROTECTED]> wrote: > >> On Thu, Nov 13, 2008 at 3:03 AM, David Møller Hansen > > >> <[EMAIL PROTECTED]> wrote: > > >> > Hi > > >> > So I'm getting to the point in my masters thesis where I have coded > >> > some different .sage files and now I have to package it in some way > >> > making it easy to use with SAGE for my professor and the censor. > > >> > I just want to explain the content of my implementation in short: > >> > It is basically a slow pairing based signature system (BLS). > >> > signature_scheme.sage file which uses some of the different components > >> > in sage: field_ext, elliptic_curves etc. > >> > And then it also uses a weil pairing function I've written in sage, I > >> > do not want to make this part of the signature scheme code, since if I > >> > have some extra time later I want to work on trying to make this > >> > function faster (haven't really figured out how) > >> > I'm currently in the process of wrapping the functions in my > >> > signature_cheme.sage file in a signature_scheme class providing a > >> > static scheme setup and maybe making it possible to generate a > >> > interact in notebook() mode. > > >> > I've looked at making a .spkg but I'm not really sure that this is the > >> > correct thing to do, since I want to call components in SAGE and all > >> > the optional packages I've looked at is mostly just code ported from c > >> > by wrapping with some python setup files (I haven't looked at all the > >> > packages). > > >> > I guess what I am asking is: Is making a spkg from my sage code, the > >> > right thing to do or is it complete nonsense? Since I've yet only > >> > encountered spkg's made from external code bases. If there is a > >> > counter example of this, then please let me know, then I can use it as > >> > a template if I were to package my code. > > >> First, I think the best thing to do is to work on getting your code into > >> Sage itself soon. Even if it isn't optimal speedwise, that's not a show > >> stopper -- correct code that adds new functionality is something we > >> definitely want. We release new versions of Sage every 2 weeks or > >> less, so once in Sage your code would rapidly get distributed. > >> Regarding pairings, we specifically don't have *anything* in Sage for > >> computing any pairings. > > >> Regarding your above question, probably the best thing for you to do > >> is a make a tar-ball or zip archive that contains all the sage files, > >> and instructions > >> about how to use them (e.g., attach "foo.sage" and type "blah" to test that > >> this works). Then put that code on a web page. Installing an > >> spkg has the drawback that it requires modifying the > >> Sage install (e.g., something that requires write permissions on a Sage > >> install), so wouldn't work for "end users" who didn't install Sage > >> themselves > >> (e.g., on a multi-user system). > > >> William > > >> William > > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://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 -~----------~----~----~----~------~----~------~--~---