[sage-devel] Re: [ARM] pickling problem : help needed

[Dima Pasechnik]

The doctest picks up the pickled stuff from 
$SAGE_ROOT/data/extcode/pickle_jar/pickle_jar.tar.bz2
which you get in the source distribution.

Actually, if I try, on ARM, at the sage prompt the following:
sage: sage.structure.sage_object.unpickle_all()
I get the same "Failed to unpickle 5 objects." result.

In short, ARM cannot unpickle correctly some stuff pickled elsewhere
You can reproduce this by 
untarring $SAGE_ROOT/data/extcode/pickle_jar/pickle_jar.tar.bz2
somewhere, creating a directory, say, /tmp/jah/, and say, putting there 
_class__sage_coding_linear_code_LinearCode__.sobj
_class__sage_coding_linear_code_LinearCode__.txt

Then we see:

sage: sage.structure.sage_object.unpickle_all('/tmp/jah/')
 * unpickle failure: 
load('/tmp/jah//_class__sage_coding_linear_code_LinearCode__.sobj')
Failed:
_class__sage_coding_linear_code_LinearCode__.sobj
Successfully unpickled 0 objects.
Failed to unpickle 1 objects.






-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [ARM] pickling problem : help needed

[Dima Pasechnik]

Here is an experiment I just tried on ARM:
create linear code from the example in LinearCode? (it's the same as in 
pickle_jar.tar.bz2)

Pickle it:
sage: sage.structure.sage_object.picklejar(C,dir='/tmp/jj')
Quit Sage.

Start Sage and unpickle it:
sage: sage.structure.sage_object.unpickle_all('/tmp/jj/')  
Successfully unpickled 1 objects.
Failed to unpickle 0 objects.

Now try unpickling this pickle on x86:
sage: sage.structure.sage_object.unpickle_all('/tmp/jj/')
 * unpickle failure: 
load('/tmp/jj//_class__sage_coding_linear_code_LinearCode__.sobj')
Failed:
_class__sage_coding_linear_code_LinearCode__.sobj
Successfully unpickled 0 objects.
Failed to unpickle 1 objects.


Thus, there is a genuine pickle/unpickle bug on ARM
(FYI, I've uploaded the pickle produced on ARM)

Dima



-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org


bad_arm_pickle.tar.bz2
Description: Binary data

Re: [sage-devel] Fwd: Atelier PARI/GP slides

[Jeroen Demeyer]

On 2012-01-29 04:00, William Stein wrote:
> Pari Days slides!
Some feature which could be useful for Sage in the future: PARI has an
experimental patch changing the format for real numbers to allow a
precision in *bits*.  Right now, precision in PARI must be a multiple of
the wordsize (32 or 64).  With the patch from Bill one could actually
get 53 bits of precision.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Willem Jan Palenstijn]

On Sun, Jan 29, 2012 at 02:53:49AM -0800, Dima Pasechnik wrote:
> Here is an experiment I just tried on ARM:
> create linear code from the example in LinearCode? (it's the same as in 
> pickle_jar.tar.bz2)
> 
> Pickle it:
> sage: sage.structure.sage_object.picklejar(C,dir='/tmp/jj')
> Quit Sage.
> 
> Start Sage and unpickle it:
> sage: sage.structure.sage_object.unpickle_all('/tmp/jj/')  
> Successfully unpickled 1 objects.
> Failed to unpickle 0 objects.
> 
> Now try unpickling this pickle on x86:
> sage: sage.structure.sage_object.unpickle_all('/tmp/jj/')
>  * unpickle failure: 
> load('/tmp/jj//_class__sage_coding_linear_code_LinearCode__.sobj')
> Failed:
> _class__sage_coding_linear_code_LinearCode__.sobj
> Successfully unpickled 0 objects.
> Failed to unpickle 1 objects.
> 
> 
> Thus, there is a genuine pickle/unpickle bug on ARM
> (FYI, I've uploaded the pickle produced on ARM)

Displaying the actual unpickle exception, I get:

('value too large to convert to char', , (4, 7, [137, 80, 78, 71, 13, 10, 26, 10, 0, 0, 
0, 13, 73, 72, 68, 82, 0, 0, 0, 7, 0, 0, 0, 4, 1, 3, 0, 0, 0, 120, 8, 183, 62, 
0, 0, 0, 6, 80, 76, 84, 69, 0, 0, 0, 255, 255, 255, 165, 217, 159, 221, 0, 0, 
0, 16, 73, 68, 65, 84, 8, 153, 99, 144, 99, 72, 99, 88, 197, 160, 3, 0, 5, 2, 
1, 91, 3, 248, 139, 52, 0, 0, 0, 0, 73, 69, 78, 68, 174, 66, 96, 130], 91))

So this is the same issue with char being unsigned on your platform.
Specifically, it seems the corresponding __reduce__ function converts a char
array into a list of python ints, which has range 0-255 for you, instead of the
-128-127 on x86. And the unpickle function has the opposite issue.

I wonder how many of these are around, and if there is any general fix for
them.


-Willem Jan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Dima Pasechnik]

Are you saying it's actually a Python bug, not a Sage bug?

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Willem Jan Palenstijn]

On Sun, Jan 29, 2012 at 03:18:45AM -0800, Dima Pasechnik wrote:
> Are you saying it's actually a Python bug, not a Sage bug?

(Aside: please quote at least part of the message you're replying to.
I'll assume you're asking me...)


No, not python, but the custom reduce/unpickle functions we have for
matrix_mod2_dense.


-Willem Jan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Julien Puydt]

Le 29/01/2012 12:13, Willem Jan Palenstijn a écrit :

So this is the same issue with char being unsigned on your platform.
Specifically, it seems the corresponding __reduce__ function converts a char
array into a list of python ints, which has range 0-255 for you, instead of the
-128-127 on x86. And the unpickle function has the opposite issue.

I wonder how many of these are around, and if there is any general fix for
them.


Well, if there is a nice inheritance graph, there's hope fixing the base 
class will maket the rest just go smooth.


Now, to fix the base class... If the goal is to take a "char" on one 
platform and turn it into a "char" on another, then it's a lost battle.


What are those "char" really encoding? If they are really "foo", then 
turning a "foo" on one platform into a "foo" on another might not be 
impossible!


Snark on #sagemath

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Willem Jan Palenstijn]

On Sat, Jan 28, 2012 at 04:36:17PM +0100, Julien Puydt wrote:
> Le 29/01/2012 12:13, Willem Jan Palenstijn a écrit :
> >So this is the same issue with char being unsigned on your platform.
> >Specifically, it seems the corresponding __reduce__ function converts a char
> >array into a list of python ints, which has range 0-255 for you, instead of 
> >the
> >-128-127 on x86. And the unpickle function has the opposite issue.
> >
> >I wonder how many of these are around, and if there is any general fix for
> >them.
> 
> Well, if there is a nice inheritance graph, there's hope fixing the
> base class will maket the rest just go smooth.
> 
> Now, to fix the base class... If the goal is to take a "char" on one
> platform and turn it into a "char" on another, then it's a lost
> battle.

Which base class do you mean exactly?

> What are those "char" really encoding? If they are really "foo",
> then turning a "foo" on one platform into a "foo" on another might
> not be impossible!

In this particular case, it seems Matrix_mod2_dense's __reduce__ serializes its
data by compressing it as a black/white PNG image. So it's really just a raw
byte stream.


-Willem Jan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Dima Pasechnik]

On Sunday, 29 January 2012 20:05:26 UTC+8, Willem Jan Palenstijn wrote:
>
> On Sat, Jan 28, 2012 at 04:36:17PM +0100, Julien Puydt wrote:
> > Le 29/01/2012 12:13, Willem Jan Palenstijn a �crit :
> > >So this is the same issue with char being unsigned on your platform.
> > >Specifically, it seems the corresponding __reduce__ function converts a 
> char
> > >array into a list of python ints, which has range 0-255 for you, 
> instead of the
> > >-128-127 on x86. And the unpickle function has the opposite issue.
> > >
> > >I wonder how many of these are around, and if there is any general fix 
> for
> > >them.
> > 
> > Well, if there is a nice inheritance graph, there's hope fixing the
> > base class will maket the rest just go smooth.
> > 
> > Now, to fix the base class... If the goal is to take a "char" on one
> > platform and turn it into a "char" on another, then it's a lost
> > battle.
>
> Which base class do you mean exactly?
>
> > What are those "char" really encoding? If they are really "foo",
> > then turning a "foo" on one platform into a "foo" on another might
> > not be impossible!
>
> In this particular case, it seems Matrix_mod2_dense's __reduce__ 
> serializes its
> data by compressing it as a black/white PNG image. So it's really just a 
> raw
> byte stream.
>
and then it does (line 1750):

cdef char *buf = gdImagePngPtr(im, &size) 
data = [buf[i] for i in range(size)]

and this data goes into the pickle. No wonder it gets different on 
different platforms!

Dima



> -Willem Jan
>
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Julien Puydt]

Le 29/01/2012 13:38, Dima Pasechnik a écrit :

and then it does (line 1750):

cdef char *buf = gdImagePngPtr(im, &size)
data = [buf[i] for i in range(size)]

and this data goes into the pickle. No wonder it gets different on
different platforms!


Would that also be a case of just using uint8_t and everything will be ok?

Snark on #sagemath

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Martin Albrecht]

On Sunday 29 January 2012, Dima Pasechnik wrote:
> On Sunday, 29 January 2012 20:05:26 UTC+8, Willem Jan Palenstijn wrote:
> > On Sat, Jan 28, 2012 at 04:36:17PM +0100, Julien Puydt wrote:
> > > Le 29/01/2012 12:13, Willem Jan Palenstijn a �crit :
> > > >So this is the same issue with char being unsigned on your platform.
> > > >Specifically, it seems the corresponding __reduce__ function converts
> > > >a
> > 
> > char
> > 
> > > >array into a list of python ints, which has range 0-255 for you,
> > 
> > instead of the
> > 
> > > >-128-127 on x86. And the unpickle function has the opposite issue.
> > > >
> > > >I wonder how many of these are around, and if there is any general fix
> > 
> > for
> > 
> > > >them.
> > > 
> > > Well, if there is a nice inheritance graph, there's hope fixing the
> > > base class will maket the rest just go smooth.
> > > 
> > > Now, to fix the base class... If the goal is to take a "char" on one
> > > platform and turn it into a "char" on another, then it's a lost
> > > battle.
> > 
> > Which base class do you mean exactly?
> > 
> > > What are those "char" really encoding? If they are really "foo",
> > > then turning a "foo" on one platform into a "foo" on another might
> > > not be impossible!
> > 
> > In this particular case, it seems Matrix_mod2_dense's __reduce__
> > serializes its
> > data by compressing it as a black/white PNG image. So it's really just a
> > raw
> > byte stream.
> 
> and then it does (line 1750):
> 
> cdef char *buf = gdImagePngPtr(im, &size)
> data = [buf[i] for i in range(size)]
> 
> and this data goes into the pickle. No wonder it gets different on
> different platforms!

The new version of M4Ri has PNG support built in directly, but I'm not sure it 
makes things better or worse. It uses libPNG directly though.

 for(rci_t i=0; iwidth-1; j++) {
  tmp = ((word)row[8*j+7])<<56 | ((word)row[8*j+6])<<48 \
|   ((word)row[8*j+5])<<40 | ((word)row[8*j+4])<<32 \
|   ((word)row[8*j+3])<<24 | ((word)row[8*j+2])<<16 \
|   ((word)row[8*j+1])<< 8 | ((word)row[8*j+0])<< 0;
  A->rows[i][j] = ~tmp;
}
tmp = 0;
switch((n/8 + ((n%8) ? 1 : 0))%8) {
case 7: tmp |= ((word)row[8*j+7])<<56;
case 6: tmp |= ((word)row[8*j+6])<<48; 
case 5: tmp |= ((word)row[8*j+5])<<40;
case 4: tmp |= ((word)row[8*j+4])<<32;
case 3: tmp |= ((word)row[8*j+3])<<24;
case 2: tmp |= ((word)row[8*j+2])<<16;
case 1: tmp |= ((word)row[8*j+1])<< 8;
case 0: tmp |= ((word)row[8*j+0])<< 0;
};
A->rows[i][j] |= (~tmp & bitmask_end);
  }

It's not in Sage yet, but I could cut a release if it helps.

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinralbre...@jabber.ccc.de

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Dima Pasechnik]

On Sunday, 29 January 2012 00:34:28 UTC+8, Snark wrote:
>
> Le 29/01/2012 13:38, Dima Pasechnik a �crit :
> > and then it does (line 1750):
> >
> > cdef char *buf = gdImagePngPtr(im, &size)
> > data = [buf[i] for i in range(size)]
> >
> > and this data goes into the pickle. No wonder it gets different on
> > different platforms!
>
> Would that also be a case of just using uint8_t and everything will be ok?
>
rather, int8_t (char = unsigned char on ARM, right?)
Cause int8_t would retain the compatibility with the existing pickles 
created on x86.

I guess we should write a sage-devel post asking people to look at other 
cases of this they are aware about

Dima

 

> Snark on #sagemath
>
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Factorising RSA modulus with high/low-order bits known module or relevent

[Ermis]

Hi all,

I am focusing on the LLL algorithm for my PhD.
Specifically, on its application on Factorising RSA modulus N with
high or low-order bits (of the prime p) known.
My scope is to use an implementation and run tests on the
factorisation problem.

SAGE has embedded Stehle's LLL version: the fplll.
But, I have not found any module on SAGE for factorising an RSA
modulus with high or low-order bits known (there is a module called
SmallRoots on MAGMA, but it is not practical).

So - given that SAGE contains a lot of related modules in this area -
my question is whether there is plan to create such a module in SAGE,
or if there is some alternative solution for the RSA factorisation
problem

Thank you.


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] sagemath.org, sagenb.org and mobile devices

[Ivan Andrus]

On Jan 25, 2012, at 2:52 PM, kcrisman wrote:

> Ivan's iPhone app is cool.  However, when it links to sagenb or
> sagemath.org, it looks ... unhelpful.  Perhaps this is possible to fix
> easily - exchange below.  Is there someone for whom this would be only
> epsilon/two of effort to fix, who has epsilon/two time available?
> 
> - kcrisman
> 
> +++
>> Incidentally, the Sage website is totally sucky for iDevice,
>> apparently.  Screenshot attached :( though I don't think there is much
>> you can do about that.   Sagenb is similar :(
> 
> Yes indeed!  It would be very nice to fix this someday.  I think it
> would simply be a matter of add a css files specifically for mobile
> devices:
> 
>  media="handheld" />
> 
> Also adding an iPhone icon would be nice:
> 
> http://www.icantinternet.org/
> icon.png”>
> 
> I guess I should just do it since it probably takes more effort to
> ignore it than to do it. :-)

Actually, it might be easier than that even, at least for the notebook.  
According to a stack overflow question [1] the problem with iPhone is that it 
tries to "scale your content for optimal viewing".  The solution is to add



which tells the (mobile) browser to use the actual width of the device.  IMHO 
this makes it (much more) usable on the iPhone. There could probably be some 
tweaks to the css just for mobile devices, but the notebook actually scales 
really well layout-wise.  Some of the plots and such are cut off, but they fit 
pretty well when viewed in landscape.

Now, sagemath.org doesn't appear to scale as well, at least the front page.  
The documentation doesn't work well until you collapse the side bar--which I 
had no idea you could do until I started trying to figure out the page to fix 
the css.  After that it's quite nice.  I'm not sure how, but it would be nice 
if that were more discoverable--especially on mobile devices.

-Ivan

[1] 
http://stackoverflow.com/questions/5031910/div-with-fixed-width-rendering-too-wide-in-ipad

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Julien Puydt]

Le 29/01/2012 13:54, Dima Pasechnik a écrit :



On Sunday, 29 January 2012 00:34:28 UTC+8, Snark wrote:

Le 29/01/2012 13:38, Dima Pasechnik a �crit :
 > and then it does (line 1750):
 >
 > cdef char *buf = gdImagePngPtr(im, &size)
 > data = [buf[i] for i in range(size)]
 >
 > and this data goes into the pickle. No wonder it gets different on
 > different platforms!

Would that also be a case of just using uint8_t and everything will
be ok?

rather, int8_t (char = unsigned char on ARM, right?)
Cause int8_t would retain the compatibility with the existing pickles
created on x86.


Fair point. Are you working on it?


I guess we should write a sage-devel post asking people to look at other
cases of this they are aware about


Well, that won't hurt. At least the doctest didn't seem to uncover other 
such cases.


Snark on #sagemath

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: webgl

[Jonathan]

William,

I guess I would like to know which of the problems you refer to still
are a problem in the updates to Jmol that are awaiting review?

The things left that I know about are:
1) The way Jmol functions in interacts is a problem, but this has
nothing to do with Jmol.  It is the way the interact code is written.
The interact code insists on reloading the whole applet every time the
server does a recalculation, rather than just send the applet a
command to load the recalculated graphics file (this would get you a
factor of 10 - 100 in response time).
2) Jmol will not work on iOS.  There is a way to get it to work on
Android, but we cannot look at that until Sage upgrades to a much more
recent Jmol (also awaiting review).  A temporary fix is to generate
static 3D images and not load the applet unless the user wishes to
make them interactive (also in the updates awaiting review).

I also agree that you should be looking at supporting other rendering
methods as the world of web interfaces is constantly shifting.

Jonathan


On Jan 28, 12:15 pm, William Stein  wrote:

> Sorry to trouble you, but I think it is time to  move past jmol.   We could
> keep jmol as an option indefinitely... but i do not think it should be the
> default for 3d.   It is not robust enough, and it is very, very
> frusratingly non-interactive: despite many attempts i have never seen a
> compelling demo of genuine sage <> jmol interaction.   Three.js will
> make this possible; it will make it easier for prople take 3d images from
> sage and put them in their own web pages (much more lightweight), supports
> ios and android -- which is *hugely important* - etc.
>
 --
> William Stein
> Professor of Mathematics
> University of Washingtonhttp://wstein.org

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Unifying Command line options

[Keshav Kini]

On Sun, Jan 29, 2012 at 13:55, R. Andrew Ohana  wrote:
> On Sat, Jan 28, 2012 at 21:19, David Roe  wrote:
>> * I would like to still allow "sage -t" as a way to access the "sage
>> test" subcommand, "sage -b" to access the "sage build" subcommand,
>> etc.
> This is fairly straightforward with the argparse in python 3.2+ (it
> supports subcommand aliases), however we would have to backport this
> functionality since it isn't in the 2.7 copy of argparse. Although, I
> don't really like this, subcommands aren't arguments (shouldn't start
> with a dash), rather what happens is "hg commit" becomes "hg co".

`hg co` actually is aliased to `hg update`, NOT `hg commit`, because
it's a common abbreviation for "checkout" (which is I guess
Mercurial's effort to be friendly to SVN users). But in any case, this
is different from short/long options as in the getopt/posix syntax. hg
just accepts any unambiguous abbreviations: `hg up` expands to `hg
update`, but so does `hg upd` or `hg upda` etc.

>> I think the key change should be to become Posix compliant, and
>> these are allowable short options.  And they combine nicely: "sage
>> -bta" would mean rebuild everything and test everything.
> These commands are odd. For most programs you only ever use one
> subcommand at a time, here we use two, and argparse doesn't deal with
> this case. What I was thinking of doing was having a subcommand
> "buildtest" (with alias "bt") which would pass its arguments to
> "build" and then to "test". ("sage -bta" would become "sage bt -a")

I find this really ugly to be honest. Subcommands are supposed to be
for launching entirely difficult functionalities from each other, no?
Making one subcommand that basically runs two other ones in order
seems bizarre. This is starting to make me question whether
subcommands are really a good idea. Maybe we should just have long and
short options a la getopt/posix, with some well defined execution
order, for example first do a build if -b or --build is specified,
then do a test if -t or --test is specified, then run, either the
notebook if -n or --notebook is specified, or the bare console, if -r
or --run is specified or if none of -b, -t, -n, or -r or their long
versions were specified. All external programs could be handled by the
thin shell script.

Or actually, why don't we just create an option "-C/--shell-command"
which feeds "-c" to the sage subshell? Then we would have, for
example, "sage -C gp" or "sage -C python" or whatever, which just adds
two characters. Some of the commands which call external programs seem
to have some initialization stuff done before the program is actually
called, so we could prepend some directory to PATH in sage-env which
contains scripts named after the actual program binaries in
$SAGE_LOCAL/bin, that initialize and call the actual program binaries,
just as we are currently doing with a bunch of five-line if statements
in $SAGE_ROOT/spkg/bin/sage .

-Keshav


Join us in #sagemath on irc.freenode.net !

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Android app

[kilucas]

I couldn't spot the version in the app, but the Android market told me
there was an update and this immediately told me it contained the web
page not available fix. It also contained new examples. Very
pleasingly, they all appeared to work, including the sliders, and the
plots.

Marvellous!! And thanks!

On Jan 28, 8:48 pm, Volker Braun  wrote:
> Just do double check, you have v0.2? (Menu->Changelog)

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Android app

[Alex Kramer]

> On Jan 28, 8:48 pm, Volker Braun  wrote:
> Just do double check, you have v0.2? (Menu->Changelog)

The update fixed the page not available problem for me.
Also, this app is really awesome.

A couple of (minor) things I've noticed with what's been
implemented so far:

* Changing screen orientations results in interact controls
disappearing:

If I have a slider and I change from portrait to landscape
view (or the other way around), the output remains but the
slider goes away.

* Output doesn't dynamically resize:

Using this code:

```
@interact
def f(n = (1..1000)):
  for i in xrange(n):
print i
```

if I move the slider to 1000, everything prints properly, but if
I then move the slider back to 1, things print but there is a
large amount of whitespace at the end that used to be taken
up by the previous output.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: webgl

[Keshav Kini]

Well, I wonder if we shouldn't ask around a bit more. If a day later you 
found something better than pre3d, maybe soon you will find something even 
better than three.js? :P As to who would be a good community to ask about 
this stuff, though, I have no idea.

-Keshav


Join us in #sagemath on irc.freenode.net !

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: [ARM] pickling problem : help needed

[Volker Braun]

On Sunday, January 29, 2012 4:54:58 AM UTC-8, Dima Pasechnik wrote:
>
> Cause int8_t would retain the compatibility with the existing pickles 
> created on x86.
> I guess we should write a sage-devel post asking people to look at other 
> cases of this they are aware about
>

+1

>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Help needed on readline library in Sage

[Kwankyu Lee]

Hi,

My cython patch "readline_extra_commands" works well on Mac but fails on 
Ubuntu at runtime with the following message:

ImportError: ../sage/misc/readline_extra_commands.so: undefined symbol: 
rl_last_func

So the linker do not find the symbol in the readline library linked to 
Python. What is the difference in the readline library (or the way it is 
linked) between Mac and Ubuntu?

Thanks for your wisdom in advance.


Kwankyu

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Unifying Command line options

[Ivan Andrus]

On Jan 29, 2012, at 7:57 PM, Keshav Kini wrote:

>>> I think the key change should be to become Posix compliant, and
>>> these are allowable short options.  And they combine nicely: "sage
>>> -bta" would mean rebuild everything and test everything.
>> These commands are odd. For most programs you only ever use one
>> subcommand at a time, here we use two, and argparse doesn't deal with
>> this case. What I was thinking of doing was having a subcommand
>> "buildtest" (with alias "bt") which would pass its arguments to
>> "build" and then to "test". ("sage -bta" would become "sage bt -a")
> 
> I find this really ugly to be honest. Subcommands are supposed to be
> for launching entirely difficult functionalities from each other, no?
> Making one subcommand that basically runs two other ones in order
> seems bizarre. This is starting to make me question whether
> subcommands are really a good idea. Maybe we should just have long and
> short options a la getopt/posix, with some well defined execution
> order, for example first do a build if -b or --build is specified,
> then do a test if -t or --test is specified, then run, either the
> notebook if -n or --notebook is specified, or the bare console, if -r
> or --run is specified or if none of -b, -t, -n, or -r or their long
> versions were specified. All external programs could be handled by the
> thin shell script.

I agree it's ugly.  I think what the user really wants is things like

sage test --build-first

rather than

sage build test

I can't imagine any ever wanting 

sage build shell test notebook

In other words, the test command would know how to (optionally) build first, 
but the build command wouldn't know how to test afterwards.  I suppose run 
could know how to build and test first, but I don't see a real use case for 
that off the top of my head.


> Or actually, why don't we just create an option "-C/--shell-command"
> which feeds "-c" to the sage subshell? Then we would have, for
> example, "sage -C gp" or "sage -C python" or whatever, which just adds
> two characters. Some of the commands which call external programs seem
> to have some initialization stuff done before the program is actually
> called, so we could prepend some directory to PATH in sage-env which
> contains scripts named after the actual program binaries in
> $SAGE_LOCAL/bin, that initialize and call the actual program binaries,
> just as we are currently doing with a bunch of five-line if statements
> in $SAGE_ROOT/spkg/bin/sage .

This would be a nice feature to have, but I want to be able to run something 
like 

sage gap -o 2g 

to tell GAP how much memory to use.  I _think_ sub command parsers handle that 
where as I would have to run

sage -C gap -- -o 2g

if there were no subcommands.

-Ivan

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Factorising RSA modulus with high/low-order bits known module or relevent

[Martin Albrecht]

On Sunday 29 January 2012, Ermis wrote:
> Hi all,

Hi,

> I am focusing on the LLL algorithm for my PhD.
> Specifically, on its application on Factorising RSA modulus N with
> high or low-order bits (of the prime p) known.
> My scope is to use an implementation and run tests on the
> factorisation problem.
> 
> SAGE has embedded Stehle's LLL version: the fplll.
> But, I have not found any module on SAGE for factorising an RSA
> modulus with high or low-order bits known (there is a module called
> SmallRoots on MAGMA, but it is not practical).

We have small roots as well:

sage: F = Zmod(3*7)
sage: F
Ring of integers modulo 21
sage: P. = F[]  
sage: type(x)

sage: x.small_roots?

   See "sage.rings.polynomial.polynomial_modn_dense_ntl.small_roots()"
   for the documentation of this function.

   EXAMPLE:

  sage: N = 10001
  sage: K = Zmod(10001)
  sage: P. = PolynomialRing(K)
  sage: f = x^3 + 10*x^2 + 5000*x - 222
  sage: f.small_roots()
  [4]

Furthermore, 

sage: sage.rings.polynomial.polynomial_modn_dense_ntl.small_roots?

even gives RSA factoring with known bits as an explicit example.

> So - given that SAGE contains a lot of related modules in this area -
> my question is whether there is plan to create such a module in SAGE,
> or if there is some alternative solution for the RSA factorisation
> problem
> 
> Thank you.

Actually, since you're doing a PhD about LLL: the version of fpLLL we ship 
with Sage is very old and it would be a great service to the community to 
update it to the most recent upstream release which 4.0:

  http://perso.ens-lyon.fr/xavier.pujol/fplll/

This version also has an implementation of BKZ which likely is faster than 
what we wrap of NTL. Having that readily available in Sage would be awesome!

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinralbre...@jabber.ccc.de

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Help needed on readline library in Sage

[Volker Braun]

Are you linking with -lreadline? Whats the entry in module_list.py


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Unifying Command line options

[Keshav Kini]

On Mon, Jan 30, 2012 at 04:36, Ivan Andrus  wrote:
> I agree it's ugly.  I think what the user really wants is things like
>
> sage test --build-first
>
> rather than
>
> sage build test
>
> I can't imagine any ever wanting
>
> sage build shell test notebook
>
> In other words, the test command would know how to (optionally) build first, 
> but the build command wouldn't know how to test afterwards.  I suppose run 
> could know how to build and test first, but I don't see a real use case for 
> that off the top of my head.

I think this is solved by having an enforced action order and just
using options instead of subcommands.

$ sage --build --shell --test --notebook # equivalently sage -bstn

would build, then test, then open a shell and ignore the notebook
option, or, perhaps better, quit with an error message about
conflicting actions.

>> Or actually, why don't we just create an option "-C/--shell-command"
>> which feeds "-c" to the sage subshell? Then we would have, for
>> example, "sage -C gp" or "sage -C python" or whatever, which just adds
>> two characters. Some of the commands which call external programs seem
>> to have some initialization stuff done before the program is actually
>> called, so we could prepend some directory to PATH in sage-env which
>> contains scripts named after the actual program binaries in
>> $SAGE_LOCAL/bin, that initialize and call the actual program binaries,
>> just as we are currently doing with a bunch of five-line if statements
>> in $SAGE_ROOT/spkg/bin/sage .
>
> This would be a nice feature to have, but I want to be able to run something 
> like
>
> sage gap -o 2g
>
> to tell GAP how much memory to use.  I _think_ sub command parsers handle 
> that where as I would have to run
>
> sage -C gap -- -o 2g
>
> if there were no subcommands.

Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for
example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b`
doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's a
workaround. The question then becomes, would we want `sage -C` to be
consistent with `sh -c`, or would we want it to be consistent with how
`sage -gap` et al. work currently? I would be fine with the latter
(say, wrapping $@ into a single argument to the -c of the subshell).

-Keshav


Join us in #sagemath on irc.freenode.net !

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Unifying Command line options

[Keshav Kini]

On Mon, Jan 30, 2012 at 05:27, Keshav Kini  wrote:
> Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for
> example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b`
> doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's a
> workaround. The question then becomes, would we want `sage -C` to be
> consistent with `sh -c`, or would we want it to be consistent with how
> `sage -gap` et al. work currently? I would be fine with the latter
> (say, wrapping $@ into a single argument to the -c of the subshell).

Er, I should mention that this -C option should be handled by the thin
bash script, of course - it doesn't make sense to start Python and
load argparse just to open a subshell! :) And we could just not check
for -C anywhere except in $1, thus making it a defensible choice to
pass $@ to the subshell ("if you use -C, you may not use any other
options to Sage").

-Keshav


Join us in #sagemath on irc.freenode.net !

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Factorising RSA modulus with high/low-order bits known module or relevent

[Bill Hart]

There's an LLL in flint 1.5, called ULLL which is very fast for large
lattice entries. It is probably subquadratic with respect to bit size
of the entries though likely not quasilinear. (We also have a highly
hacked version of fpLLL in flint specifically set up for knapsack
lattices.)

I recently bumped into an algorithm for factoring with known bits,
called the p^2+p+1 algorithm. It has a generalisation to other
cyclotomic polynomials. I think there are still some open questions
there, but I don't recall LLL being used in that algorithm, so I guess
this may not be of interest to you.

Bill.

On Jan 29, 8:41 pm, Martin Albrecht 
wrote:
> On Sunday 29 January 2012, Ermis wrote:
>
> > Hi all,
>
> Hi,
>
> > I am focusing on the LLL algorithm for my PhD.
> > Specifically, on its application on Factorising RSA modulus N with
> > high or low-order bits (of the prime p) known.
> > My scope is to use an implementation and run tests on the
> > factorisation problem.
>
> > SAGE has embedded Stehle's LLL version: the fplll.
> > But, I have not found any module on SAGE for factorising an RSA
> > modulus with high or low-order bits known (there is a module called
> > SmallRoots on MAGMA, but it is not practical).
>
> We have small roots as well:
>
> sage: F = Zmod(3*7)
> sage: F
> Ring of integers modulo 21
> sage: P. = F[]
> sage: type(x)
> 
> sage: x.small_roots?
>
>        See "sage.rings.polynomial.polynomial_modn_dense_ntl.small_roots()"
>        for the documentation of this function.
>
>        EXAMPLE:
>
>           sage: N = 10001
>           sage: K = Zmod(10001)
>           sage: P. = PolynomialRing(K)
>           sage: f = x^3 + 10*x^2 + 5000*x - 222
>           sage: f.small_roots()
>           [4]
>
> Furthermore,
>
> sage: sage.rings.polynomial.polynomial_modn_dense_ntl.small_roots?
>
> even gives RSA factoring with known bits as an explicit example.
>
> > So - given that SAGE contains a lot of related modules in this area -
> > my question is whether there is plan to create such a module in SAGE,
> > or if there is some alternative solution for the RSA factorisation
> > problem
>
> > Thank you.
>
> Actually, since you're doing a PhD about LLL: the version of fpLLL we ship
> with Sage is very old and it would be a great service to the community to
> update it to the most recent upstream release which 4.0:
>
>  http://perso.ens-lyon.fr/xavier.pujol/fplll/
>
> This version also has an implementation of BKZ which likely is faster than
> what we wrap of NTL. Having that readily available in Sage would be awesome!
>
> Cheers,
> Martin
>
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://martinralbrecht.wordpress.com/
> _jab: martinralbre...@jabber.ccc.de

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Unifying Command line options

[Jeroen Demeyer]

On 2012-01-29 22:29, Keshav Kini wrote:
> On Mon, Jan 30, 2012 at 05:27, Keshav Kini  wrote:
>> Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for
>> example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b`
>> doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's a
>> workaround. The question then becomes, would we want `sage -C` to be
>> consistent with `sh -c`, or would we want it to be consistent with how
>> `sage -gap` et al. work currently? I would be fine with the latter
>> (say, wrapping $@ into a single argument to the -c of the subshell).
> 
> Er, I should mention that this -C option should be handled by the thin
> bash script, of course - it doesn't make sense to start Python and
> load argparse just to open a subshell! :)
And -C is one of the useful options even when Sage has not been built
completely, so we should not rely on Python for this -C option.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Help needed on readline library in Sage

[Kwankyu Lee]

It is

Extension('sage.misc.readline_extra_commands',
  sources = ['sage/misc/readline_extra_commands.pyx']),

Do I need to add "-lreadline" somewhere here? 






 



-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: webgl

[Dima Pasechnik]

On Monday, 30 January 2012 03:49:45 UTC+8, Keshav Kini wrote:
>
> Well, I wonder if we shouldn't ask around a bit more. If a day later you 
> found something better than pre3d, maybe soon you will find something even 
> better than three.js? :P As to who would be a good community to ask about 
> this stuff, though, I have no idea.
>

stackoverflow, maybe?
 

>
> -Keshav
>
>

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Help needed on readline library in Sage

[Volker Braun]

Yes you need at least libraries = ['readline']. If you need other libraries 
they must be declared as well.




-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Help needed on readline library in Sage

[Kwankyu Lee]

I wonder why that was not necessary for Mac. Anyway, thank you very much!


Kwankyu

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] abuse of char C type in Cython (several places in sage/) - please review your code

[Dima Pasechnik]

Working on the ARM port (kudos to Snark), which has, unlike x86, unsigned 
char, we stumbled upon several places in Sage library (in Cython code) 
where char type was used for (essentially) operating on bit strings.

One example (in Sage 4.8) is computing pickle for a dense Z_2-matrix in 
matrix/Matrix_mod2_dense.pyx (line 1750):

cdef char *buf = gdImagePngPtr(im, &size) 
data = [buf[i] for i in range(size)]

and then data (list of Python ints) goes into the pickle, resulting in a 
plaform-dependent pickle (as on x86 there are signed bytes, i.e. -128..127, 
and on ARM unsigned, i.e. 0..255).

Another example is in graphs/graph_decompositions/vertex_separation.pyx, 
where
a similar abuse of char type is taking place 
(spottedby 
Willem-Jan).

Volker 
sayswe 
should "use C99 integer types if the code assumes signedness and/or a 
particular bit width for "char". Just include inttypes.h (C) or cinttypes 
(C++), then int8_t is a signed 8-bit integer and uint8_t is an unsigned 
8-bit integer."

Thus, if you are aware of other places where char is abused in a similar 
fashion, please fix them!
Probably it's got to be mentioned in the developer's guide, too.

References:
https://groups.google.com/d/msg/sage-devel/2HwMYI1CY98/j0L5xvhnPSIJ
https://groups.google.com/d/msg/sage-devel/_OuLJdHk-So/ZG4jpbIG5h0J

Dima


-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: Help needed on readline library in Sage

[Volker Braun]

Because OSX uses the old ld behavior of implicitly guessing DSOs. For 
various reasons this is a bad idea and has been turned off on linux 
distributions in the last couple of years.

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] abuse of char C type in Cython (several places in sage/) - please review your code

[Julien Puydt]

Le 30/01/2012 03:10, Dima Pasechnik a écrit :

Working on the ARM port (kudos to Snark), which has, unlike x86,
unsigned char, we stumbled upon several places in Sage library (in
Cython code) where char type was used for (essentially) operating on bit
strings.


To be more specific : all platforms have "unsigned char" and "signed 
char", but the unadorned "char" can be either of those, depending on the 
platform. On most platforms, "char" means "signed char" ; on ARM, it 
means "unsigned char".


So if your code uses bare "char", it might have portability issues.

If you just use "char*" for runtime data buffers, then all is ok. If you 
make sign tests, things get murky. If you write those buffers on disk 
with the hope to use them with the same code on another platform, it's 
wrong.


If you have any doubt about a piece of code, please write to sage-devel 
so we can help assess if there's a problem, and if so, get rid of it.


Thanks,

Snark on #sagemath

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org