Re: [sage-devel] Re: Question about cysignals installation

['Martin R. Albrecht' via sage-devel]

FWIW this PR https://github.com/sagemath/cysignals/pull/174 does this porting, 
I think.

CI complaints but I don’t understand the complaint.

On Wed, Aug 16 2023, Dima Pasechnik wrote:
> I think your cython is too new (3.0.0).
>
> Cysignals has not been ported to it yet.
>
> On Wednesday, August 16, 2023 at 4:00:24 PM UTC+1 JC wrote:
>
>> Dear Sage developers,
>>
>> I'm trying to install the cysignals 1.11.2 package in Python 3.9.7 using 
>> pip (on a computer with macOS system and Apple M2 chip) and have already 
>> installed the prerequisite packages Cython and Sphinx, but still failed 
>> with some Cython compiling errors (please see the error message attached). 
>> Do you know what the problem might be and how I can fix it?
>>
>> Thank you very much!
>>


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87jztvui7p.fsf%40googlemail.com.

Re: [sage-devel] fpylll really slow in sage9.x, when compared to sage8.x

['Martin R. Albrecht' via sage-devel]

Thanks, it’s this function and a similar one the other way, i.e. an FPyLLL 
issue when used inside Sage: 

```
cdef int assign_mpz(mpz_t& t, value) except -1:
"""
Assign Python integer to Z_NR[mpz_t]
"""
if isinstance(value, int) and PY_MAJOR_VERSION == 2:
mpz_set_si(t, PyInt_AS_LONG(value))
return 0
if isinstance(value, long):
mpz_set_pylong(t, value)
return 0
if have_sage:
from sage.rings.integer import Integer
if isinstance(value, Integer):
value = long(value)
mpz_set_pylong(t, value)
return 0
```

Per your profiler output we’re calling this 2*250*250 times, i.e. once to 
convert in and once to convert out.

This should be fixed with this PR:

  https://github.com/fplll/fpylll/pull/239

I’ll cut a new release and update https://trac.sagemath.org/ticket/34870

Cheers,
Martin

On Wed, Jan 11 2023, Nils Bruin wrote:
> Of course going back to py2 is not a solution but the data point is 
> indicative that a regression was introduced, and that would be worth 
> solving. It looks to me the following code is what exhibits the problematic 
> behaviour. Run on a recent sage (9.7 or so):
>
> sage: from fpylll import *
> sage: FPLLL.set_random_seed(0)
> sage: dim = 250
> : bits = 3
> : A = IntegerMatrix.random(dim, "uniform", bits = bits)
> sage: %prun B = LLL.reduction(A)
>
> (with profiling to see if anything comes to light):
>
>  19250003 function calls (1853 primitive calls) in 6.983 seconds
>
>Ordered by: internal time
>
>ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>1250000.6650.0003.1270.000  importlib._bootstrap>:921(_find_spec)
> 375000/1250000.6120.0006.3680.000  importlib._bootstrap>:1022(_find_and_load)
> 10.5480.5486.9836.983 :1()
>1250000.5040.0001.5250.000  importlib._bootstrap_external>:1536(find_spec)
>3750000.3890.0000.7190.000  importlib._bootstrap>:179(_get_module_lock)
> 375000/1250000.3260.0005.4720.000  importlib._bootstrap>:987(_find_and_load_unlocked)
>6250000.2680.0000.6680.000  importlib._bootstrap_external>:126(_path_join)
>3750000.2640.0000.3280.000  importlib._bootstrap>:125(release)
>3750000.2610.0000.3250.000  importlib._bootstrap>:100(acquire)
>6250000.2490.0000.3310.000  importlib._bootstrap_external>:128()
>3750000.2060.0000.2730.000  importlib._bootstrap>:71(__init__)
>1250000.2000.0000.2000.000 {built-in method posix.stat}
> ...
>  
> Nevermind that the times don't add up, we see a profile that is completely 
> dominated by import stuff! So it looks to me we may have ended up with an 
> import in some fairly tight loop. Regardless of whether this is the actual 
> source of the problem observed here, I think it's problematic in its own 
> right.


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87sfggpuuf.fsf%40googlemail.com.

Re: [sage-devel] fpylll really slow in sage9.x, when compared to sage8.x

['Martin R. Albrecht' via sage-devel]

Hi there,

I don’t think A*B is a good benchmark for FPyLLL does the same slowdown also 
appear for, say, LLL?

Cheers,
Martin

On Tue, Jan 10 2023, 'Julian Nowakowski' via sage-devel wrote:
> Hi all,
>
> we recently noticed that the IntegerMatrix class from fpylll is (on our 
> hardware) much slower in sage9.x, than it is in sage8.x.
>
> Please consider the following code snippet:
>
> import time
> from fpylll import IntegerMatrix
>
> dim = 30
> bits = 10
>
> A = IntegerMatrix.random( dim, "uniform", bits = bits )
> B = IntegerMatrix.random( dim, "uniform", bits = bits )
>
> start = time.time()
> C = A*B
> stop = time.time()
>
> print( "Multiplication took %f seconds." % (stop-start) )
>
>
> We tried running this code in Sage 8.1, 8.9, 9.3 and 9.7. In the 8.x 
> versions, the multiplications takes less than 0.2 seconds. In the 9.x 
> versions, it takes more than 6 seconds.
>
> Any ideas?
>
> Best,
> Julian
>
> --
>
> https://juliannowakow.ski/


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87cz7m1wto.fsf%40googlemail.com.

Re: [sage-devel] VOTE: move Sage development to Github

['Martin R. Albrecht' via sage-devel]

+1 for GitHub

On Wed, Sep 21 2022, David Roe wrote:
> Dear Sage developers,
> Following extensive discussion, both recently
>  
> (prompted
> by issues upgrading the trac server) and over
>  the
>  last
>  decade
> , we
> are calling a vote on switching Sage development from Trac
>  to Github .  We've
> created a summary of the pros and cons of each system
> , a 
> description
> of the development model to be used on github
> , and
> a trac ticket  for coordinating
> work on the transition.  More work will need to be done to carry out the
> actual transition once voting is complete.
>
> The voting will last until noon Eastern time (16:00 UTC) on Wednesday,
> October 5.  Please use this thread only for sending votes, to make it
> easier to count them afterward; there is a parallel thread where you can
> make arguments in favor of either system.
>
> Finally, I will close with a plea to be involved in this vote and
> discussion even if you are not a core Sage developer.  By definition, core
> Sage developers have become comfortable with trac, and I think that one of
> the major arguments in favor of github is that it will help bring in new
> contributors who are not familiar with Sage's development workfow
> .  Anyone who has
> ever contributed to the Sage code base or who maintains a Sage user package
> is welcome to vote.
> David


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87tu4z5pip.fsf%40googlemail.com.

[sage-devel] M1?

['Martin R. Albrecht' via sage-devel]

Hi there,

Do “we” (in some broad, fuzzy sense) have SSH-able access to an M1?

M4RIE (included in Sage) is reportedly acting up on those:

https://bitbucket.org/malb/m4rie/issues/23/trying-to-compile-on-apple-m1

Cheers,
Martin

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87a6e7z9hi.fsf%40googlemail.com.

[sage-devel] M4RIE testing on Apple M1?

['Martin R. Albrecht' via sage-devel]

Hi there,

There’s a bug report about Sage’s linear algebra over GF(2^e) here:

https://trac.sagemath.org/ticket/33212

which seems to boil down to a problem M4RIE on Apple M1s:

https://bitbucket.org/malb/m4rie/issues/23/trying-to-compile-on-apple-m1

Could someone with an Apple M1 compile and ‘make check‘ M4RIE and report back 
on either ticket? This is to at least get confirmation it’s an Apple M1 issue 
and not something else.

The Trac ticket reports the failure on two different M1s so I presume it is an 
M1 issue, but good to be sure.

Cheers,
Martin


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io
_prn: he/him or they/them

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87mtjkhq86.fsf%40googlemail.com.

[sage-devel] Virtual FPLLL Days 6: 19/20 November

['Martin R. Albrecht' via sage-devel]

Hi there,

We’ll be hold the 6th FPLLL Days (inspired by Sage Days) on 19/20 November.

https://github.com/fplll/fplll/wiki/Virtual-FPLLL-Days-6-aka-Bounded-Distance-Development

FPLLL is a lattice reduction library that powers Sage’s lattice reduction, 
among other things, see https://github.com/fplll/

We have a few project ideas that touch on better integration with Sage, so if 
that’s your jam, feel free to come along and help out.

Cheers,
Martin
-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87eelan4r3.fsf%40googlemail.com.

Re: [sage-devel] Unimodular transformation matrix of LLL algorithm

['Martin R. Albrecht' via sage-devel]

Seems like the cost of doing business, the entries of U are pretty big:

sage: print(RR(log(abs(U[0][0]),2)))
1277.66401749439

Santanu Sarkar  writes:
> Dear Martin,
>   Kindly see the following code.
>
> from fpylll import (IntegerMatrix, LLL)
> row=160
> col=100
> tt=cputime()
> A = random_matrix(ZZ,  row,col,x=-2000, y=2000)
> U = IntegerMatrix.identity(row)
> tt=cputime()
> B = LLL.reduction(IntegerMatrix.from_matrix(A), U).to_matrix(matrix(ZZ,
> row,col))
> print cputime(tt)
> tt=cputime()
> A=A.LLL()
> print cputime(tt)
>
> Lattice reduction takes 49 seconds in the first case and 7 seconds in the
> second case.
> Maybe I am missing something.
>
> Best regards,
> Santanu
>
> On Tue, 29 Sep 2020 at 09:01, 'Martin R. Albrecht' via sage-devel <
> sage-devel@googlegroups.com> wrote:
>
>> Hi there,
>>
>> Sage is using FP(y)LLL under the hood, so there shouldn’t be that much of
>> a performance difference. As far as I can see, both Sage and FPyLLL have
>> the same defaults so it’s not clear to me why you see this performance
>> difference.
>>
>> Cheers,
>> Martin
>>
>>
>> Santanu Sarkar  writes:
>> > Dear Martin,
>> > Thank you so much. It works!
>> > Can we make it faster?
>> > It took 17 seconds for my problem but
>> > M1.LLL() took only 3 seconds. Of course I understand we
>> > are calculating extra matrix U.
>> >
>> > Thanks again for your help.
>> >
>> > Regards,
>> > Santanu
>> >
>> >
>> >
>> > On Sun, 27 Sep 2020 at 20:45, 'Martin R. Albrecht' via sage-devel <
>> > sage-devel@googlegroups.com> wrote:
>> >
>> >> Hi there,
>> >>
>> >> This should do the trick:
>> >>
>> >> sage: from fpylll import *
>> >> sage: A = random_matrix(ZZ, 6, 90)
>> >> sage: U = IntegerMatrix.identity(6)
>> >> sage: B = LLL.reduction(IntegerMatrix.from_matrix(A),
>> >> U).to_matrix(matrix(ZZ, 6,
>> >> 90))
>> >> sage: U = U.to_matrix(matrix(ZZ, 6,6))
>> >> sage: B == U*A
>> >> True
>> >> sage: abs(U.det())
>> >> 1
>> >>
>> >> Cheers,
>> >> Martin
>> >>
>> >>
>> >> Santanu Sarkar  writes:
>> >> > Dear all,
>> >> >I have a matrix M1 with integer entries with 90 rows and 6 columns.
>> >> > After applying LLL algorithm of M1, I get M2=M1.LLL(). I want to get
>> >> > corresponding unimodular transformation matrix T such that
>> >> > T*M1=M2. We can find T by
>> >> > T=M2*M1.pseudoinverse() or T== M1.solve_left(M2), but determinant of T
>> >> > becomes 0 i.e.,  T.det()=0.
>> >> > I want T.det()=1.
>> >> >
>> >> > Best regards,
>> >> > Santanu
>> >>
>> >>
>> >> --
>> >>
>> >> _pgp: https://keybase.io/martinralbrecht
>> >> _www: https://malb.io
>> >>
>> >> --
>> >> 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 view this discussion on the web visit
>> >>
>> https://groups.google.com/d/msgid/sage-devel/87h7rjmesx.fsf%40googlemail.com
>> >> .
>> >>
>>
>>
>> --
>>
>> _pgp: https://keybase.io/martinralbrecht
>> _www: https://malb.io
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-devel/87blhrm5uu.fsf%40googlemail.com
>> .
>>


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/874knfe0py.fsf%40googlemail.com.

Re: [sage-devel] Unimodular transformation matrix of LLL algorithm

['Martin R. Albrecht' via sage-devel]

Hi there,

Sage is using FP(y)LLL under the hood, so there shouldn’t be that much of a 
performance difference. As far as I can see, both Sage and FPyLLL have the same 
defaults so it’s not clear to me why you see this performance difference.

Cheers,
Martin


Santanu Sarkar  writes:
> Dear Martin,
> Thank you so much. It works!
> Can we make it faster?
> It took 17 seconds for my problem but
> M1.LLL() took only 3 seconds. Of course I understand we
> are calculating extra matrix U.
>
> Thanks again for your help.
>
> Regards,
> Santanu
>
>
>
> On Sun, 27 Sep 2020 at 20:45, 'Martin R. Albrecht' via sage-devel <
> sage-devel@googlegroups.com> wrote:
>
>> Hi there,
>>
>> This should do the trick:
>>
>> sage: from fpylll import *
>> sage: A = random_matrix(ZZ, 6, 90)
>> sage: U = IntegerMatrix.identity(6)
>> sage: B = LLL.reduction(IntegerMatrix.from_matrix(A),
>> U).to_matrix(matrix(ZZ, 6,
>> 90))
>> sage: U = U.to_matrix(matrix(ZZ, 6,6))
>> sage: B == U*A
>> True
>> sage: abs(U.det())
>> 1
>>
>> Cheers,
>> Martin
>>
>>
>> Santanu Sarkar  writes:
>> > Dear all,
>> >I have a matrix M1 with integer entries with 90 rows and 6 columns.
>> > After applying LLL algorithm of M1, I get M2=M1.LLL(). I want to get
>> > corresponding unimodular transformation matrix T such that
>> > T*M1=M2. We can find T by
>> > T=M2*M1.pseudoinverse() or T== M1.solve_left(M2), but determinant of T
>> > becomes 0 i.e.,  T.det()=0.
>> > I want T.det()=1.
>> >
>> > Best regards,
>> > Santanu
>>
>>
>> --
>>
>> _pgp: https://keybase.io/martinralbrecht
>> _www: https://malb.io
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/sage-devel/87h7rjmesx.fsf%40googlemail.com
>> .
>>


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87blhrm5uu.fsf%40googlemail.com.

Re: [sage-devel] Unimodular transformation matrix of LLL algorithm

['Martin R. Albrecht' via sage-devel]

Hi there,

This should do the trick:

sage: from fpylll import *
sage: A = random_matrix(ZZ, 6, 90)
sage: U = IntegerMatrix.identity(6)
sage: B = LLL.reduction(IntegerMatrix.from_matrix(A), U).to_matrix(matrix(ZZ, 6,
90))
sage: U = U.to_matrix(matrix(ZZ, 6,6))
sage: B == U*A
True
sage: abs(U.det())
1

Cheers,
Martin


Santanu Sarkar  writes:
> Dear all,
>I have a matrix M1 with integer entries with 90 rows and 6 columns.
> After applying LLL algorithm of M1, I get M2=M1.LLL(). I want to get
> corresponding unimodular transformation matrix T such that
> T*M1=M2. We can find T by
> T=M2*M1.pseudoinverse() or T== M1.solve_left(M2), but determinant of T
> becomes 0 i.e.,  T.det()=0.
> I want T.det()=1.
>
> Best regards,
> Santanu


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87h7rjmesx.fsf%40googlemail.com.

Re: [sage-devel] Re: #28664 (Lattice Reduction Strategies in Sage binaries)

['Martin R. Albrecht' via sage-devel]

Hi all,

A follow up: I ran

$ git clone https://github.com/sagemath/binary-pkg.git
$ cd binary-pkg
$ make bdist-sage-linux
$ cd ..
$ unp binary-pkg/dist/sage-9.0.beta6-Debian_GNU_Linux_9-x86_64.tar.bz2
$ cd SageMath
$ ./sage

(watch the patching going on)

sage: from fpylll import *
sage: BKZ.DEFAULT_STRATEGY_PATH
b'/bulk/home/malb/software/SageMath/local/share/fplll/strategie'
print(load_strategies_json(b"/home/malb/projects/lattices/fplll/strategies/default.json")[60])
Strategy< 60, (40), 0.29-0.50>

So the patching thing does seem to work when I do it locally.

Cheers,
Martin


Martin R. Albrecht  writes:
> Hi Nils,
>
> Thanks, this is helpful.
>
> Is there a straight-forward way in which I can trigger the relocation, I’m 
> trying to test what goes wrong, so:
>
> 1/ I built sage from source, all works as expected
> 2a/ I move the installation, Sage barks at me.
> 2b/ However, just starting python from the relocated binary and issuing
>
>   >>> from fpylll import *
>   >>> BKZ.DEFAULT_STRATEGY
>   
> '/bulk/home/malb/software/sage-long-path-for-binary-building/local/share/fplll/strategies/default.json'
>   >>> print 
> load_strategies_json("/home/malb/projects/lattices/fplll/strategies/default.json")[60]
>   Strategy< 60, (40), 0.29-0.50>
>
> seems to work.
>
> 3/ How do I get the relocation script to run to see if that indeed breaks the 
> above code?
>
> Sorry, if that should be obvious.
>
> Cheers,
> Martin
>
>
> Nils Bruin  writes:
>> If you see a difference in behaviour between binary and source 
>> distributions, then perhaps it's due to
>>
>> https://github.com/sagemath/binary-pkg/blob/master/binary_pkg/templates/relocate-once.py
>>
>> From what I understand, a binary distribution is originally built on a 
>> rather long and distinctive path, so that a search-and_replace on absolute 
>> path names should work (and should have enough room to make the 
>> replacements). Perhaps this is what goes wrong? Perhaps only part of 
>> fpylll's files are picked up to make replacements on?
>>
>> It may be worth comparing the files like bkz.so etc. on the binary install 
>> *before* anything was run and *after*. The mangled path names distinctly 
>> suggest that some path name rewrite is tried, but that it doesn't succeed 
>> (although the error might very well originate from your own C++ code -- 
>> that's not so easy for me to see).


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87mucr1pmu.fsf%40road.

Re: [sage-devel] Re: #28664 (Lattice Reduction Strategies in Sage binaries)

['Martin R. Albrecht' via sage-devel]

Hi Nils,

Thanks, this is helpful.

Is there a straight-forward way in which I can trigger the relocation, I’m 
trying to test what goes wrong, so:

1/ I built sage from source, all works as expected
2a/ I move the installation, Sage barks at me.
2b/ However, just starting python from the relocated binary and issuing

  >>> from fpylll import *
  >>> BKZ.DEFAULT_STRATEGY
  
'/bulk/home/malb/software/sage-long-path-for-binary-building/local/share/fplll/strategies/default.json'
  >>> print 
load_strategies_json("/home/malb/projects/lattices/fplll/strategies/default.json")[60]
  Strategy< 60, (40), 0.29-0.50>

seems to work.

3/ How do I get the relocation script to run to see if that indeed breaks the 
above code?

Sorry, if that should be obvious.

Cheers,
Martin


Nils Bruin  writes:
> If you see a difference in behaviour between binary and source 
> distributions, then perhaps it's due to
>
> https://github.com/sagemath/binary-pkg/blob/master/binary_pkg/templates/relocate-once.py
>
> From what I understand, a binary distribution is originally built on a 
> rather long and distinctive path, so that a search-and_replace on absolute 
> path names should work (and should have enough room to make the 
> replacements). Perhaps this is what goes wrong? Perhaps only part of 
> fpylll's files are picked up to make replacements on?
>
> It may be worth comparing the files like bkz.so etc. on the binary install 
> *before* anything was run and *after*. The mangled path names distinctly 
> suggest that some path name rewrite is tried, but that it doesn't succeed 
> (although the error might very well originate from your own C++ code -- 
> that's not so easy for me to see).


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87eey43h0m.fsf%40road.

[sage-devel] #28664 (Lattice Reduction Strategies in Sage binaries)

['Martin R. Albrecht' via sage-devel]

Hi all,

At https://trac.sagemath.org/ticket/28664 I’m/we’re confronted with a bug where 
I’m not sure how to make progress.

Essentially, if you build Sage from source, all is well. But if you use the 
binaries provided then lattice reduction reverts to something really really 
slow by being unable to load the strategies that speed it up:

First problem:

sage:  from fpylll import *
sage: BKZ.DEFAULT_STRATEGY
'/home/malb/software/SageMath/local/share/fplll/strategieparse error - 
unpreprocessing_blpruning_parameteError: gptr == nullpoints/default.json'

This should be a filename.

But even loading from a correct path fails:

sage: from fpylll import *
load_strategies_json("/home/malb/projects/lattices/fplll/strategies/default.json")[60]
Strategy< 60, (), 1.00-1.00>

The above should read `Strategy< 60, (40), 0.29-0.50>`

Any ideas?

Cheers,
Martin

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://malb.io

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/87muct4flv.fsf%40road.

Re: [sage-devel] Re: Anyone used SBox.interpolation_polynomial?

['Martin R. Albrecht' via sage-devel]

Hi there,

I probably wrote the code and the documentation (?) but I haven’t used either 
in a while. If it’s all the same, perhaps keeping the current behaviour (and 
changing the documentation) is the strategy of least surprise?

Cheers,
Martin


Travis Scrimshaw  writes:
> Anyone have any thoughts on this? If not, then I will assume that the 
> documentation was the intended behavior.
>
> Best,
> Travis
>
>
> On Sunday, December 23, 2018 at 7:15:00 AM UTC+10, Travis Scrimshaw wrote:
>>
>> It has to do more specifically with how GF(2^k) elements are interpreted 
>> by an SBox. The documentation says they are treated differently than the 
>> code, and I wanted to know which was correct. In particular, it was 
>> interpreted in the code as a list in opposite order. So I would like to 
>> know which is the correct behavior, which shows up in the 
>> interpolation_polynomial doctests.
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, December 20, 2018 at 1:17:38 AM UTC+10, Friedrich Wiemer 
>> wrote:
>>>
>>> Is there anyone who used the SBox.interpolation_polynomial?
>>> Travis and I found a wird behaviour of the  SBox.__call__ regarding 
>>> finitie field elements as inputs and think that this is a bug.This is fixed 
>>> in #25633 but it would be nice if someone who used this input (e.g. 
>>> indirectly with the `interpolation_polynomial` method) could review this 
>>> change and check if this brakes something?
>>>
>>


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: how to use a singular lib

['Martin R. Albrecht' via sage-devel]

Indeed, this should work:

_ = sage.libs.singular.function.lib("symodstd.lib")
syModStd = sage.libs.singular.function.singular_function("syModStd")


Simon King  writes:
> Hi Daniel,
>
> On 2018-11-23, Daniel Krenn  wrote:
>> Singular is shipped with symodstd.lib (it contains an algorithm for
>> computing a Groebner basis in a special case).
>> How can I access it from within Sage?
>>
>> I looked up the code and coming from an ideal's groebner_basis method,
>> it is somehow clear how to extend this, but how do I make the actual
>> call to one of the library's functions? (I seems just straight forward
>> to call something in Singular's standard library.)
>>
>> Is there any code that calls some function from a Singular-library that
>> I can look up?
>
> How do you plan to use singular? Via pexpect or via libsingular?
>
> For the former, there is code in
> src/sage/groups/matrix_gps/finitely_generated.py (where Singular's
> finvar.lib is used).
>
> For the latter, I am not so sure. However, there is
> sage.libs.singular.function.SingularLibraryFunction. I am guessing that
> its documentation will explain how to use a function from one of
> Singular's libraries.
>
> Best regards,
> Simon


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] A Sage interface for FGb (Gröbner bases)

['Martin R. Albrecht' via sage-devel]

parisse  writes:
> Le jeudi 22 novembre 2018 10:11:39 UTC+1, Thierry (sage-googlesucks@xxx) a 
> écrit :
>>
>> Hi, 
>>
>>
>> It was on my todo list for a while too, since our implementations are very 
>> slow. Here "very" means "prohibitively", since some systems can not be 
>> solved with Sage in decent time (via Singular), while FGb could solve them 
>> quickly. 
>
>
> That's not correct, Sage has a wrapper to Giac which has fast GB code and 
> is also open-source. I really wonder why it seems to be ignored.

Hi,

speaking of Giac (sorry, if this should rather be on sage-support or off-list):

Can I get the degree reached during the computation and the sizes of the 
matrices considered out somehow?

Rationale: In crypto, we usually want to see if the system under consideration 
behaves like a random-system despite not being one. One way of testing this is 
to compute the degree of semi-regularity for a semi-regular sequence and 
compare with the degree reached during a GB computation of an actual instance.

Cheers,
Martin


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] A Sage interface for FGb (Gröbner bases)

['Martin R. Albrecht' via sage-devel]

Hi Markus,

Works without a hitch here (Debian/testing, Sage 8.4). I have been planning on 
doing this over the years but never got around to it, so really cool to see 
that you did. Nice work!

Cheers,
Martin


Markus Wageringel  writes:
> Hi everyone.
>
> I created a Sage wrapper for the C interface of FGb, which makes it easy to 
> call FGb from within Sage. The sources are available on Github [1] and can 
> be installed as a Python package into Sage:
>
> [1] https://github.com/mwageringel/fgb_sage
>
>
> FGb is a C-library by J. C. Faugère for computing Gröbner bases and 
> supposedly it is one of the faster implementations that exist. It is 
> included with Maple [2]. FGb is closed source, but comes with a C interface 
> that is freely distributed for academic use. Some of the features:
>
> • The computations run in parallel. (This only seems to work for 
> computations over finite fields.)
> • Elimination/block orders are supported.
> • It runs on Linux and Mac. (There seem to be some issues, though. I could 
> not get FGb to work on my Ubuntu machine. It fails with an "Illegal 
> instruction" error.)
>
>
> In my Sage interface, I implemented just two functions: computing Gröbner 
> bases and elimination ideals. Supposedly, the FGb C-library supports other 
> functionality like computing Hilbert polynomials, but that part of the 
> library is not documented very well, so it does not make sense to try to 
> create wrappers for that. The focus is finding a Gröbner basis which, once 
> computed, can be used by Sage for further computations.
>
> I just wanted to share this. Maybe it is useful for someone.
>
> Markus
>
> [2] https://www-polsys.lip6.fr/~jcf/FGb/Maple/index.html


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Representation of LinearLayers in the crypto module

['Martin R. Albrecht' via sage-devel]

Hi Friedrich,

I was thinking maybe something like this:

from sage.matrix.matrix_mod2_dense import Matrix_mod2_dense, 
from sage.matrix.matrix_gf2e_dense import Matrix_gf2e_dense

class LinearLayer:
def foo(self):
return self[0, 1]

def LinearLayerFactory(K):
if K.characteristic() == 2 and K.degree() == 1:
return type("LinearLayerGF2", (Matrix_mod2_dense, LinearLayer), {})
if K.characteristic() == 2 and K.degree() == 1:
return type("LinearLayerGF2E", (Matrix_gf2e_dense, LinearLayer), {})
else:
raise NotImplementedError

T = LinearLayerFactory(GF(2))

T(MatrixSpace(GF(2), 2, 2), [0, 1, 2, 3], False, False).foo()

Cheers,
Martin


Friedrich Wiemer  writes:
> Hi,
>
> I worked on an implementation of linear layers (basically a matrix over
> GF(2) or GF(2^n) with some special methods) in the crypto module during
> the sage days 94 and came up with this: #25735.
>
> Martin commented that it might make sense to just inherit from an
> appropriate matrix class, to avoid another layer of indirection. Seems a
> totally valid point for me, so I'm now trying to find out, what would be
> the appropriate inheritance. As we only need matrices over GF(2) or
> GF(2^n), I assume the correct super class would be their common super
> class Matrix_dense. But when I implement it, e.g. like this:
>
> %%cython
> cimport sage.matrix.matrix_dense as matrix_dense
> from sage.matrix.constructor import matrix
> cdef class LinearLayer(matrix_dense.Matrix_dense):
>   cdef public object _m
>  
>   def __init__(self, parent, entries=None):
> m = matrix(parent, entries)
> self._m = m
>
> the matrix self._m "forgets" that it was a Matrix_mod2_dense or
> Matrix_gf2e_dense before:
>
> test_m = random_matrix(GF(2**4), 4, 4)
> test_m.__class__.__mro__
> (,
> ,
> ,
> ,
> ,
> ,
> ,
> ,
> ,
> )
> LinearLayer(test_m.parent(), test_m)
> test1._m.__class__.__mro__
> (,
> ,
> ,
> ,
> ,
> ,
> ,
> ,
> ,
> )
>
> Thus operations which are specialised in Matrix_mod2_dense or 
> Matrix_gf2e_dense are not available anymore.
> Am I misunderstanding some concept here?
>
> Thanks in advance for your help,
> Friedrich


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What does MPolynomial_libsingular.reduce() do?

['Martin R. Albrecht' via sage-devel]

Hi there,

I’m fairly certain that I wrote that code or was at least involved 
since I wrote most of the first version of the libsingular stuff, 
David’s commit output by `git blame` is a merge commit.


The algorithm in question is described in “Ideals, Varieties, and 
Algorithms” by David Cox, John Little and Donal O’Shea in Section 
"§3 A Division Algorithm in k[x_1 , … , x_n]".


I didn’t check, though, if under the hood Singular does some 
additional tricks which might modify the output when I is not a 
GB.


Cheers,
Martin

PS: Checking if something is a GB calls reduce to check. See 
`basis_is_groebner`.


Luca De Feo  writes:

+1 for doing something.

What about the following fix: When the input is a list/tuple, 
we check
if it is a Groebner basis or not. If it is, do the computation, 
if not,

print a warning or raise an error.


Sounds reasonable.

Other options would be:

- Just refuse list input.
- Always compute a Groebner basis.

Since it seems that David Roe wrote the original code, his 
opinion

would be very valuable.

Luca



--

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What does MPolynomial_libsingular.reduce() do?

['Martin R. Albrecht' via sage-devel]

Hi there,

AFAIK if you do that you prevent high-level implementation of 
Gröbner basis algorithms in Sage which call reduce, 
i.e. polynomial division with remainders, on S-polynomials wrt to 
the current basis.


Cheers,
Martin

Daniel Krenn  writes:

On 2017-10-17 11:49, Luca De Feo wrote:
It takes I as the generators of the ideal and uses that as the 
reduction

set.


That's not a definition. I'm in front of a class asking what 
this
function does, and I'm unable to give a mathematical definition 
of
what Sage means by "reduction" modulo something that's not a 
Groebner

basis.

What it does is probably do the reduction using the list in 
reverse order

for this case.


"Probably" is not a mathematical definition. Besides, I think 
it's

more complicated than that.

Am I the only one who's regularly embarassed explaining Sage's 
quirks

to an audience of beginners (or not beginners)?


+1 for doing something.

What about the following fix: When the input is a list/tuple, we 
check
if it is a Groebner basis or not. If it is, do the computation, 
if not,

print a warning or raise an error.

Testing if something is a Groebner basis could be done by 
converting the

list to an object of

and use its method .is_groebner()

Daniel



--

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] What does MPolynomial_libsingular.reduce() do?

['Martin R. Albrecht' via sage-devel]

Hi there,

this is already documented:

“ Return the normal form of self w.r.t. "I", i.e. return the
  remainder of this polynomial with respect to the polynomials in
  "I". If the polynomial set/list "I" is not a (strong) Groebner
  basis the result is not canonical.
”

Cheers,
Martin

Daniel Krenn  writes:

On 2017-10-16 18:41, Luca De Feo wrote:

Here's a Sage session:

sage: A. = QQ[]
sage: (x+y).reduce([(x-y), (x+y)])
0
sage: (x-y).reduce([(x-y), (x+y)])
-2*y

The docstring says reduce computes "the normal form of self 
w.r.t. I,

i.e. [...] the remainder of this polynomial with respect to the
polynomials in I".

Does anyone have any idea how this normal form is defined? It 
doesn't

seem to depend on the order of the polynomials in I.


It computes the polynomial "modulo" the given ideal (i.e. 
compute a
Groebner basis of the ideal and reduce the given polynomial by 
this basis).


My guess: If only a list of polynomials is given, then it is 
assumed
that these form a Groebner basis, which seems not to be the 
case.


From the source code, I can only tell it calls Singular's kNF, 
but I
can't find any doc for it. Maybe this function should be 
underscored?


Once we know what it does with lists, the documentation should 
be made

precise.

I am against underscoring, as for ideals as parameter, this is a
standard operation.



--

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

['Martin R. Albrecht' via sage-devel]

Hi all,

this is now  https://trac.sagemath.org/ticket/21728

Cheers,
Martin

Martin R. Albrecht writes:
> Hi there,
>
> Ximin Luo writes:
>> We can do "pre-install tests" with Sage 7.3, by doing a "dummy
>> install" using Sage's Makefiles, running the tests here, then
>> installing them to the "real location". (This requires some patching,
>> but we have achieved this already and it works.) However with Sage 7.4
>> this is not possible, due to the fpylll situation. Packages in Debian
>> (and most other buildsystems) are built and tested as distinct units,
>> we can't build A, install A, build B, install B, then test A.
>
> I see the problem here.
>
>> So, a much better alternative of resolving the fpylll issue would be
>> to not have fpylll build-depend on Sage.
>
>> (1) I can see that it's possible to build fpylll without Sage, it will
>> just have a different API. Could we patch Sage-the-library to use
>> fpylll-without-Sage, then have Sage itself convert the non-Sage
>> integers into Sage integers?
>
> […]
>
>> So, what are the problems with (1)? If there are no problems, could we
>> patch this *before* Sage 7.4 is released? I would be happy to write
>> the patch myself, but guidance on where to start would also be much
>> appreciated.
>
> It’d be easy to make that work as far as tests are concerned, we’d lose
> convenience, though: none of the fpylll functions taking integer
> arguments would work out of the box.
>
> Alternatively, we could do the conversion on the Python level instead of
> C/C++/Cython. This way, it could be resolved at runtime. There’d be some
> overhead, but the Integer conversion functions aren’t really used all
> that much.
>
> I’ll give that a try.
>
> Cheers,
> Martin


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

['Martin R. Albrecht' via sage-devel]

Hi there,

Ximin Luo writes:
> We can do "pre-install tests" with Sage 7.3, by doing a "dummy
> install" using Sage's Makefiles, running the tests here, then
> installing them to the "real location". (This requires some patching,
> but we have achieved this already and it works.) However with Sage 7.4
> this is not possible, due to the fpylll situation. Packages in Debian
> (and most other buildsystems) are built and tested as distinct units,
> we can't build A, install A, build B, install B, then test A.

I see the problem here.

> So, a much better alternative of resolving the fpylll issue would be
> to not have fpylll build-depend on Sage.

> (1) I can see that it's possible to build fpylll without Sage, it will
> just have a different API. Could we patch Sage-the-library to use
> fpylll-without-Sage, then have Sage itself convert the non-Sage
> integers into Sage integers?

[…]

> So, what are the problems with (1)? If there are no problems, could we
> patch this *before* Sage 7.4 is released? I would be happy to write
> the patch myself, but guidance on where to start would also be much
> appreciated.

It’d be easy to make that work as far as tests are concerned, we’d lose
convenience, though: none of the fpylll functions taking integer
arguments would work out of the box.

Alternatively, we could do the conversion on the Python level instead of
C/C++/Cython. This way, it could be resolved at runtime. There’d be some
overhead, but the Integer conversion functions aren’t really used all
that much.

I’ll give that a try.

Cheers,
Martin



-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] fplll 5.0 in sage

['Martin R. Albrecht' via sage-devel]

This is now

  https://trac.sagemath.org/ticket/21221

Cheers,
Martin

Jean-Pierre Flori writes:
> Yes!
>
> Did you open a ticket for this?


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] fplll 5.0 in sage

['Martin R. Albrecht' via sage-devel]

Hi Sage developers,

*tl;dr* Fplll 5.0 is about to hit the streets. It’s a major improvement
 over Fplll 4.* which we currently ship with Sage. To update we need to
 change the user interface of the function `IntegerMatrix.BKZ`. I
 suggest to drop Sage’s own interface to Fplll in favour of the official
 Fpylll interface, which I propose to make a standard package.

[ ] Yes
[ ] No
[ ] Maybe

# Details #

We are getting ready to release Fplll 5.0.0. Here are some highlights
from the changelog https://raw.githubusercontent.com/fplll/fplll/master/NEWS

- fplll switched to more open development model on GitHub
  with a bigger development community

- public implementation of all techniques collectively known as BKZ 2.0.
  BKZ in block size 80 is a reasonably easy computation now.

- build system overhaul, automated tests, test coverage increase

- Self-Dual BKZ and Slide reduction

- faster, recursive enumeration implementation

- Gaussian lattice sieving

- optional support for doubledouble and quaddouble

  https://github.com/fplll/fplll

If you care only about LLL then this release won’t change much for you,
because Sage doesn’t ship libqd. But if you care about stronger lattice
reduction this release makes a huge difference.

# Sage Interface #

(a) Sage’s public interface is through the functions `IntegerMatrix.LLL` and
`IntegerMatrix.BKZ` and a few functions on the integer lattice class.

(b) These call some in `libs.fplll`

The the interface for calling BKZ has changed and does not match Sage’s
interface (a). We could write a translation layer, but I’d prefer to
simply change it. Users will want to use the new interface.

I also suggest to replace (b) completely with 

  https://github.com/fplll/fpylll

It’s a Cython interface to fplll + additional Python code which started
as a fork of Sage’s Cython interface. It’s much more flexible and
powerful than what Sage has to offer. For example, it (easily) allows to
implement BKZ and LLL variants in pure Python. Strong lattice reduction
is a major area of research for cryptographers at the moment and this
library aims to make experimentation for this easy.

It is mainly written and maintained by me. Lattice-based cryptography
will be research area for the foreseeable future and this code is a key
component of this research for me, so I plan to maintain and improve it
over the next few years. I do commit to maintaining it in Sage, too.

The code has tests which are run on every check in.

Yes, No, Maybe?

Cheers,
Martin

PS: Here is some random benchmark:

$ ./latticegen q 100 50 30 b > ~/test_lattice.txt

new fplll

$ time ./fplll -a bkz -s ../strategies/default.json -bkzautoabort -v -b 60 
~/test_lattice.txt > /dev/null
Entering BKZ:
block size:  60, flags: 0x0021, max_loops:   0, max_time: 0.0, autoAbort: 
(1.,  5), 

End of BKZ loop0, time =12.832s, r_0 = 1.80e10, slope = -0.056809, 
log2(nodes) = 28.142067
End of BKZ loop1, time =25.072s, r_0 = 1.07e10, slope = -0.050003, 
log2(nodes) = 29.120454
End of BKZ loop2, time =36.836s, r_0 = 1.00e10, slope = -0.048468, 
log2(nodes) = 29.623702
End of BKZ loop3, time =48.944s, r_0 = 9.42e9, slope = -0.048443, 
log2(nodes) = 29.991966
End of BKZ loop4, time =58.176s, r_0 = 9.42e9, slope = -0.048230, 
log2(nodes) = 30.207781
End of BKZ loop5, time =67.904s, r_0 = 9.42e9, slope = -0.048134, 
log2(nodes) = 30.414377
End of BKZ loop6, time =78.040s, r_0 = 9.42e9, slope = -0.048500, 
log2(nodes) = 30.611421
End of BKZ loop7, time =87.780s, r_0 = 9.42e9, slope = -0.048197, 
log2(nodes) = 30.784449
End of BKZ loop8, time =96.468s, r_0 = 9.42e9, slope = -0.047948, 
log2(nodes) = 30.910345
End of BKZ loop9, time =   117.404s, r_0 = 9.42e9, slope = -0.048360, 
log2(nodes) = 31.053923
End of BKZ loop   10, time =   143.812s, r_0 = 9.42e9, slope = -0.048163, 
log2(nodes) = 31.180644
End of BKZ loop   11, time =   164.652s, r_0 = 9.42e9, slope = -0.047898, 
log2(nodes) = 31.286769
End of BKZ loop   12, time =   203.492s, r_0 = 9.20e9, slope = -0.048275, 
log2(nodes) = 31.392854
End of BKZ loop   13, time =   236.376s, r_0 = 9.20e9, slope = -0.047879, 
log2(nodes) = 31.501613
End of BKZ loop   14, time =   284.636s, r_0 = 9.20e9, slope = -0.048120, 
log2(nodes) = 31.608491
End of BKZ loop   15, time =   310.472s, r_0 = 9.20e9, slope = -0.047999, 
log2(nodes) = 31.696863
End of BKZ loop   16, time =   328.624s, r_0 = 9.20e9, slope = -0.048367, 
log2(nodes) = 31.795334
End of BKZ loop   17, time =   340.940s, r_0 = 9.20e9, slope = -0.048103, 
log2(nodes) = 31.876720
End of BKZ loop   18, time =   350.668s, r_0 = 9.20e9, slope = -0.048362, 
log2(nodes) = 31.940467
End of BKZ: success

fplll 4.* in Sage:

$ time fplll -a bkz -bkzautoabort -v -b 60 -bkzmaxloops 1
~/test_lattice.txt

-> killed after 80 minutes without finishing the first tour.

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: 

[sage-devel] fplll upgrade review

['Martin R. Albrecht' via sage-devel]

Hi there,

anybody up for reviewing

  http://trac.sagemath.org/ticket/20291

which upgrades fplll to the current upstream master. This enables to
install fpylll[1] in Sage, which is a much nicer Python interface for
lattice-reduction than what Sage currently has (optional package in 
preparation.)

Cheers,
Martin


Footnotes: 
[1]  https://github.com/malb/fpylll

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[sage-devel] Re: interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Hi all,

work on this has started:

  https://github.com/malb/signal.pyx

  http://trac.sagemath.org/ticket/20002

So far, it’s pretty standard setup.py stuff, i.e. no autoconf.

Help welcome:

  https://github.com/malb/signal.pyx/issues

Cheers,
Martin

Martin R. Albrecht writes:
> Hi all,
>
> In a thread over at [sage-support] William wrote:
>> I've suggested numerous times that we should massively refactor the
>> sage library to be a bunch of smaller Python libraries, develop them
>> say on github (?), use Pypi and pip. If people would realize how
>> important it is that we revamp how Sage development is done in a much
>> less monolithic way, and better using existing tools, then I would be
>> happy and enjoy watching as people do the revamp (e.g., like happened
>> with switching from Mercurial to Git, which I didn't do much on, but
>> definitely supported).
>
> I don’t mean to restart a general strategy/development discussion here,
> but perhaps turning Sage into a bunch of smaller Python libraries is
> something which can be accomplished step-by-step.
>
> In particular, I am *very* interested in turning Sage’s interrupt
> handling into something that can be easily installed from PyPI. For
> those who don’t know what Sage’s interrupt handling does: it allows that
> you can press Ctrl-C to interrupt long running C code and that crashes
> in a library do not necessarily crash your Python shell. It is a
> difference between night and day to interface with external C/C++ code
> From Python without and with it.
>
> Having this code available outside of Sage enables, for example, to turn
> some of our C/C++ library interfaces into stand-alone libraries[^1], like
> I’ve done with our fplll interface at
>
>   https://github.com/malb/fpylll
>
> Sage’s interrupt handling lives at
>
>   https://github.com/sagemath/sage/tree/master/src/sage/ext/interrupt
>
> I think the technical challenges are manageable. I’m using a copy of it
> separately in
>
>   https://github.com/malb/fpylll/tree/master/src/fpylll/interrupt
>
> without issues. Making this code independent would mean one big patch
> to the library, though, where we replace all
>
>   include 'sage/ext/interrupt.pxi'
>
> with an appropriate new line depending on where we’d install the file.
>
> My question is: am I overlooking some technical challenge or another
> reason why making this code independent could be a problem?
>
> I’m happy to put some work into this, in case you’re wondering.
>
> Cheers,
> Martin
>
> [^1]: Okay, there’s also the small issue of how to do type conversion
> Sage ←→ library in a nice modular yet fast way, but one step at a time.


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Hi Volker,

I’m not sure I follow. Many Python packages have tests, pick your
favourite Python testing framework. Why should this be a problem here?
In addition, Sage can/should run its own doctests to check there’s no
mismatch.

Cheers,
Martin

Volker Braun writes:
> On Monday, February 1, 2016 at 10:40:42 AM UTC+1, Martin Albrecht wrote:
>>
>> but perhaps turning Sage into a bunch of smaller Python libraries is 
>> something which can be accomplished step-by-step. 
>>
>
> The first order of business should then be to modularize the doctest 
> framework, otherwise you end up with a bunch of packages that have no 
> working testsuite. Which nobody in their right mind would want to base 
> their work on.
>
> Also, namespace packages (i.e. multiple packages sharing sage.*) are easier 
> in Python >= 3.3 thanks to PEP420.
>
> Splitting of non-mathematical tools would be definitely an advantage since 
> they would be useful in other projects. And some fairly isolated interfaces 
> with third-party programs could be factored out, too. But I don't think 
> there is much value in splitting up most of the core functionality; If the 
> doctests can't be run independently then modules are irreducible. And there 
> aren't many doctests that you can run without libgmp or libsingular, for 
> example. 
>
> Also, the semver coolaid doesn't really work if there is nobody running e2e 
> tests. Which really is admitting defeat, if I can't develop packages 
> independently then they are not independent. At least in npm one can work 
> around broken semver by installing specific versions in parallel, but pip 
> does not support that. On the plus side, one can still install install pip 
> packages without pages of warnings about unsupported/abandoned versions 


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

I guess this ends my plan to just

  pip install -r requirements.txt

it. But it makes sense.

This is now http://trac.sagemath.org/ticket/20002

libcynterupt?

Cheers,
Martin

Volker Braun writes:
> The system-specific part could be a separate C library "libinterrupt" that 
> the python package depends on. That is how many other Python packages 
> depend on system-specific libraries...
>
>
>
> On Tuesday, February 2, 2016 at 9:41:13 AM UTC+1, Jeroen Demeyer wrote:
>>
>> One more thing: I think that this "interrupt" project would really 
>> benefit from autoconf. I know that Python + autoconf is not a common 
>> combination, but there are some non-trivial system-specific things which 
>> are best handled by autoconf. Moreover, I have always wanted to add 
>> support for handling stack overflows using sigaltstack(), possibly also 
>> using getcontext()/setcontext(), which might again require autoconf 
>> checks. 
>>


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Jean-Pierre Flori writes:
> "cygnals"? 

+1

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Hi Jeroen,

my concern is mainly of convention: I don’t think people expect pip to
install shared libraries. Also, virtual environments tend not to set
LD_LIBRARY_PATH but many people use pip with virtualenvs.

Cheers,
Martin

Jeroen Demeyer writes:
> On 2016-02-02 10:16, 'Martin R. Albrecht' via sage-devel wrote:
>> I guess this ends my plan to just
>>
>>pip install -r requirements.txt
>
> I'm not sure it does. I have no idea what pip install $FOO actually 
> does. If it just runs setup.py, we can still run ./configure from setup.py.
>
>> libcynterupt?
> Bikeshedding time! For of all, I would certainly drop the "lib".
>
> Then we should consider if we want to refer to "interrupt" or to 
> "signal". Arguments for "signal" are that the interrupt/signal framework 
> handles more signals than just SIGINT and that the macros are also 
> called sig_on()/sig_off(). So what about "cysignals"?


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[sage-devel] interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Hi all,

In a thread over at [sage-support] William wrote:
> I've suggested numerous times that we should massively refactor the
> sage library to be a bunch of smaller Python libraries, develop them
> say on github (?), use Pypi and pip. If people would realize how
> important it is that we revamp how Sage development is done in a much
> less monolithic way, and better using existing tools, then I would be
> happy and enjoy watching as people do the revamp (e.g., like happened
> with switching from Mercurial to Git, which I didn't do much on, but
> definitely supported).

I don’t mean to restart a general strategy/development discussion here,
but perhaps turning Sage into a bunch of smaller Python libraries is
something which can be accomplished step-by-step.

In particular, I am *very* interested in turning Sage’s interrupt
handling into something that can be easily installed from PyPI. For
those who don’t know what Sage’s interrupt handling does: it allows that
you can press Ctrl-C to interrupt long running C code and that crashes
in a library do not necessarily crash your Python shell. It is a
difference between night and day to interface with external C/C++ code
>From Python without and with it.

Having this code available outside of Sage enables, for example, to turn
some of our C/C++ library interfaces into stand-alone libraries[^1], like
I’ve done with our fplll interface at

  https://github.com/malb/fpylll

Sage’s interrupt handling lives at

  https://github.com/sagemath/sage/tree/master/src/sage/ext/interrupt

I think the technical challenges are manageable. I’m using a copy of it
separately in

  https://github.com/malb/fpylll/tree/master/src/fpylll/interrupt

without issues. Making this code independent would mean one big patch
to the library, though, where we replace all

  include 'sage/ext/interrupt.pxi'

with an appropriate new line depending on where we’d install the file.

My question is: am I overlooking some technical challenge or another
reason why making this code independent could be a problem?

I’m happy to put some work into this, in case you’re wondering.

Cheers,
Martin

[^1]: Okay, there’s also the small issue of how to do type conversion
Sage ←→ library in a nice modular yet fast way, but one step at a time.

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] Can anyone provide access to recent Intel or AMD machines?

['Martin R. Albrecht' via sage-devel]

Hi Bill,

we got 16 cores (w/o HT) of

  Intel(R) Xeon(R) CPU E5-2667 v2 @ 3.30GHz

here. If that helps, let me know off list and I can grant Alex access.

Cheers,
Martin

'Bill Hart' via sage-devel writes:
> Hi all,
>
> today Alex Best started in Kaiserslautern on this OpenDreamKit project.
> He's working on support in MPIR for the latest Intel and AMD processors.
> However, we have very little access to anything later than about 2010.
>
> Does anyone have more recent Intel and AMD machines (linux servers) that
> they could provide log in access to? We'd be doing timings of all the basic
> MPIR functions and eventually superoptimising the assembly language
> functions.
>
> In general, one can expect up to a 2x speedup for each different
> microarchitecture (code from previous arches is rarely anywhere near
> optimal for more recent ones). E.g. we just tried some code which is
> roughly optimal for bobcat on a piledriver and it was two times slower than
> the old K10 code we have!
>
> If you can help, please contact me off list.
>
> Bill.
>
> P.S: We are aware of the GCC farm, but almost everything there we have
> access to elsewhere.


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] interrupt.pyx on PyPi?

['Martin R. Albrecht' via sage-devel]

Hi Jeroen,

Jeroen Demeyer writes:
> On 2016-02-01 10:40, 'Martin R. Albrecht' via sage-devel wrote:
>> In particular, I am *very* interested in turning Sage’s interrupt
>> handling into something that can be easily installed from PyPI. For
>> those who don’t know what Sage’s interrupt handling does: it allows that
>> you can press Ctrl-C to interrupt long running C code and that crashes
>> in a library do not necessarily crash your Python shell.
>
> First of all, do you assume that the code you want to interrupt is 
> Cython? Or do you want something which could work more generally?

Cython-only is enough for me.

> I guess it could be separated from Sage. It might be a good project for 
> some Sage Days workshop.

+1, I don’t think I’ll attend any anytime soon. Let’s see if I can find
some time to work on this in the mean time. I’ll wait a bit more if
there are objects here and then open a ticket, where we can move
technical discussions.

> One non-trivial thing is that the Sage interrupt framework also refers 
> directly to PARI. So this would need to be abstracted.

Ah, I forgot about removing that one for my hack. Good point.

> And of course it will only work on POSIX systems.

I guess we could provide some noop for non-POSIX systems?

Cheers,
Martin



-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[sage-devel] Re: [sage-support] building Software Carpentry "lesson" for Sagemath

['Martin R. Albrecht' via sage-devel]

Hi Dima,

I’m not sure how much time I can contribute, but I’m in principle
interested and would appreciate being kept in the loop.

Cheers,
Martin

Dima Pasechnik writes:
> Software Carpentry, see http://software-carpentry.org, is a charity that 
> does "Teaching basic lab skills for research computing". But goes beyond 
> that; their workshops can include more nontrivial components, e.g. recently 
> GAP people conducted such an introductory GAP workshop:
> https://kkwakwa.github.io/2015-11-16-manchester-codima/
> Such workshop materials are prepared to a standard and are reusable.
>
> As a followup, I did a 3-hour  introduction to Sage there. 
>
> Now the idea is to create and run specifically Sage(math) Software 
> Carpentry workshops.
> Alex Konovalov (who did the bulk of work for the GAP S.C. workshop, in cc:) 
> created a skeleton git repo for such a 
> lesson: https://github.com/alex-konovalov/sage-lesson 
> and is assembling a team to work on this. Not sure about the timeline at 
> the moment, but most probably we'd like to organise such a Software 
> Carpentry workshop for Sage(math) in the autumn.
>
> In case you're interested, please get in touch.
> Dima

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [sage-devel] modulo operators (integers, rationals, real numbers)

['Martin R. Albrecht' via sage-devel]

Hi sage-devel,

I think 1) should be the default but I find myself needing 2) quite a
bit these days (also for integers)

Cheers,
Martin

Vincent Delecroix writes:
> Hello,
>
> While responding to this ask question
>
> http://ask.sagemath.org/question/31740/why-112321-and-111320
>
> I discovered some inconsistencies with the modulo operators in Sage. We 
> indeed have three coexisting definitions for x % y
>
>   1) the unique x' between [0,y) of the form x + ny  (used when both x 
> and y are integers)
>
>   2) the unique x' between (-y/2, y/2] of the form x+ny (used when x is 
> a float)
>
>   3) the result of an operation in Zmod(y) and a lift to {0, ..., y-1} 
> (used when x is a rational and y a float)
>
> I would suggest to always use 1) but I am not sure if my opinion is 
> shared by many mathematicians and Sage programmers...
>
> Best,
> Vincent

-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature