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 Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
