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
-~----------~----~----~----~------~----~------~--~---

Reply via email to