[sage-devel] Re: Inverse of a p-adic matrix fails. Is this a bug?

2018-01-30 Thread Simon King
Hi!

I am afraid I don't know a definitive answer to your question.
But at least I find the following a bit strange:
  sage: d = M.det()
  sage: d == -1
  True
  sage: d == 0
  False

So, the inversion of M should work, I think. Let us do compute
the inverse "manually" (i.e., by applying Gaussian elimination
to the augmented matrix) to see where it fails:

sage: N = M.augment(M.parent()(1))
sage: N.swap_rows(0,3)
sage: N.add_multiple_of_row(1,0,-N[1,0])
sage: N.add_multiple_of_row(2,0,-N[2,0])
sage: N.add_multiple_of_row(2,1,-N[2,1])
sage: N.rescale_row(2,~N[2,2])
sage: N.add_multiple_of_row(3,2,-N[3,2])
sage: N.add_multiple_of_row(1,2,-N[1,2])
sage: N.add_multiple_of_row(0,2,-N[0,2])
sage: N.rescale_row(3,~N[3,3])
sage: N.add_multiple_of_row(2,3,-N[2,3])
sage: N.add_multiple_of_row(0,3,-N[0,3])
sage: N[:,:4] == 1
True

Therefore, N[:,4:] should be inverse to M. But it isn't:

sage: N[:,4:]*M == 1
False
sage: M*N[:,4:] == 1
False

I suppose that there is some p-adic rounding going on. Which would also
explain why there is a division-by-zero error (a number which is
p-adically close to zero may have been rounded to zero).

Best regards,
Simon



On 2018-01-30, Simon Brandhorst  wrote:
> The following may be a bug or me not understanding p-adic floating point 
> computations:
>
>
> sage: R = Qp(2,type='floating-point',print_mode='terse')
> sage: M = Matrix(R,4,[0, 0, 1, 1, 2^20, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1])
> sage: M.det()
> 1048575
> sage: M.inverse()
> ---
> ZeroDivisionError Traceback (most recent call last)
> 
>
> ZeroDivisionError: input matrix must be nonsingular
>
> sage: M = Matrix(R,4,[0, 0, 1, 1, 2^19, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1])
> sage: M.inverse()
> [ 1048575201]
> [274878955520   5242881  1048575]
> [  524289   5242871   524287]
> [274877382656   524289  1048575   524289]
>
> Works. 
>

-- 
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] Reworked configure

2018-01-30 Thread Jeroen Demeyer

On 2018-01-30 13:19, Erik Bray wrote:

I think the resulting Makefile, and its
template, are easier to understand for one.


This is unfortunately the part where I disagree and it is also the 
reason why I am against the current patch. The resulting Makefile uses 
some macro constructions which make it hard to understand: the Makefile 
does not contain the actual rules for building the packages, only 
macros. Most of the time, this might be fine. But when some obscure bug 
in the build system comes around, not seeing the actual rules nor being 
able to edit them is going to make things difficult.


I can imagine that there are things to be improved in the way how the 
Makefile is generated. So I'm not against improvements or changes in 
general. But I am against changes which make the resulting Makefile 
harder to understand.


--
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] Re: trac not usable using https

2018-01-30 Thread Ralf Stephan
Found out I had to reload the ssh information.

Sorry for the noise.

-- 
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] trac not usable using https

2018-01-30 Thread Ralf Stephan
After a make distclean I can no longer push to trac via https (of git trac)

ralf@ark:~/sage> git trac push 24604 --branch=u/rws/24604
Pushing to Trac #24604...
Specified remote branch: u/rws/24604

To trac.sagemath.org:sage.git
 * [new branch]HEAD -> u/rws/24604

Traceback (most recent call last):
  File "/home/ralf/sage/local/bin/git-trac", line 18, in 
cmdline.launch()
  File 
"/home/ralf/sage/local/lib/python2.7/site-packages/git_trac/cmdline.py", 
line 223, in launch
app.push(ticket_number, remote=args.remote, force=args.force)
  File "/home/ralf/sage/local/lib/python2.7/site-packages/git_trac/app.py", 
line 217, in push
ticket = self.trac.load(ticket_number)
  File 
"/home/ralf/sage/local/lib/python2.7/site-packages/git_trac/trac_server.py", 
line 118, in load
ticket = TracTicket(ticket_number, self.anonymous_proxy)
  File 
"/home/ralf/sage/local/lib/python2.7/site-packages/git_trac/trac_ticket.py", 
line 155, in TracTicket
change_log = server_proxy.ticket.changeLog(ticket_number)
  File "/home/ralf/sage/local/lib/python2.7/xmlrpclib.py", line 1243, in 
__call__
return self.__send(self.__name, args)
  File "/home/ralf/sage/local/lib/python2.7/xmlrpclib.py", line 1602, in 
__request
verbose=self.__verbose
  File "/home/ralf/sage/local/lib/python2.7/xmlrpclib.py", line 1283, in 
request
return self.single_request(host, handler, request_body, verbose)
  File 
"/home/ralf/sage/local/lib/python2.7/site-packages/git_trac/digest_transport_py2.py",
 
line 127, in single_request
response = self.opener.open(req)
  File "/home/ralf/sage/local/lib/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
  File "/home/ralf/sage/local/lib/python2.7/urllib2.py", line 447, in _open
'_open', req)
  File "/home/ralf/sage/local/lib/python2.7/urllib2.py", line 407, in 
_call_chain
result = func(*args)
  File "/home/ralf/sage/local/lib/python2.7/urllib2.py", line 1241, in 
https_open
context=self._context)
  File "/home/ralf/sage/local/lib/python2.7/urllib2.py", line 1198, in 
do_open
raise URLError(err)
urllib2.URLError: 

This works:
ralf@ark:~/sage> git push --set-upstream trac HEAD:u/rws/24604
Branch tmp14 set up to track remote branch u/rws/24604 from trac.
Everything up-to-date

Regards,

-- 
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] Re: sagemath problems

2018-01-30 Thread John H Palmieri
Yes, can someone please look into this? zulip hasn't worked in a few days 
now.

  John


On Sunday, January 28, 2018 at 11:51:39 PM UTC-8, Ralf Stephan wrote:
>
> Hello,
> processing of ticket actions is quite slow and zulip.sagemath.org gives a 
> 502, both since at least yesterday. Can someone please have a look?
>
> Regards,
>

-- 
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] Inverse of a p-adic matrix fails. Is this a bug?

2018-01-30 Thread Simon Brandhorst
The following may be a bug or me not understanding p-adic floating point 
computations:


sage: R = Qp(2,type='floating-point',print_mode='terse')
sage: M = Matrix(R,4,[0, 0, 1, 1, 2^20, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1])
sage: M.det()
1048575
sage: M.inverse()
---
ZeroDivisionError Traceback (most recent call last)


ZeroDivisionError: input matrix must be nonsingular

sage: M = Matrix(R,4,[0, 0, 1, 1, 2^19, 1, 0, 1, 1, 1, 1, 1, 1, 0, 1, 1])
sage: M.inverse()
[ 1048575201]
[274878955520   5242881  1048575]
[  524289   5242871   524287]
[274877382656   524289  1048575   524289]

Works. 

-- 
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] Re: embedding sage in c or c++

2018-01-30 Thread J. Javan
I can see that you have successfully linked against sage.
I also have a Qt GUI application which needs to do some mathematics in the 
background.
This application is targeted for windows platforms. I have installed sage 
from this link 

.
Could you please guide me on how to link my app with sage?

I'm running your code as below

#include 


int main(int argc, char *argv[])

{


int retVal = 0;

Py_Initialize();

PySys_SetArgv(argc, (wchar_t**) argv);

printf("1+1:\n");

PyRun_SimpleString("print (1+1)");

printf("Load sage \n");

retVal = PyRun_SimpleString("from sage.all import *");

printf("Factor 2310:\n");

PyRun_SimpleString("print factor(2310)");

Py_Finalize();

return 0;

}


And this gives me the following output:

1+1:
2
Load sage
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'sage'
Factor 2310:
  File "", line 1
print factor(2310)
   ^
SyntaxError: invalid syntax
Press  to close this window...

The output is clearly stating that sage cannot be found.
This is because I have linked to my locally compiled python static 
libraries(Actually I have downloaded python source code and linked against 
it.) which are not aware of sage.

Also I tried to link against python provided in sage installation but I 
can't find any "python.lib" in it.
I have also set an environment variable $SAGE_LOCAL pointing to "C:\Program 
Files\SageMath 8.1\runtime\opt\sagemath-8.1\local" but no luck.

Environment:
Qt_v5.9
Windows 7
Python_v3.6.4
Sage_v8.1

On Wednesday, September 14, 2011 at 4:15:58 AM UTC+4:30, Michael Rubinstein 
wrote:
>
> Thanks! That worked for me too, though I'm not sure how you decided on 
> the specific 
> choices of libraries to link to. 
>
> Mike 
>
> On Sep 13, 6:39 pm, Willem Jan Palenstijn  wrote: 
> > On Tue, Sep 13, 2011 at 08:46:05AM -0700, Michael Rubinstein wrote: 
> > 
> > > I tried adding PySys_SetArgv(argc, argv); after Py_Initialize(); 
> > > It gets me further but then gives a strange error message: 
> > 
> > > Loading the Sage library... 
> > 
> > >  
> > > Unhandled SIGSEGV: A segmentation fault occurred in Sage. 
> > > This probably occurred because a *compiled* component 
> > > of Sage has a bug in it (typically accessing invalid memory) 
> > > or is not properly wrapped with _sig_on, _sig_off. 
> > > You might want to run Sage under gdb with 'sage -gdb' to debug this. 
> > > Sage will now terminate (sorry). 
> > >  
> > 
> > I've just tried it here with your embed.c + PySys_SetArgv(argc, argv), 
> and it 
> > works for me when I link against libpython2.6 dynamically: 
> > 
> > $ gcc -I$SAGE_LOCAL/include/python2.6 embed.c -lpython2.6  -lm -lutil 
> -lpthread -ldl -o embed 
> > $ ./embed 
> > 1+1: 
> > 2 
> > Load sage 
> > Factor 2310: 
> > 2 * 3 * 5 * 7 * 11 
> > $ 
> > 
> > This is 64 bit linux with sage 4.7.1rc1. 
> > 
> > -Willem Jan

-- 
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] Re: embedding sage in c or c++

2018-01-30 Thread Jafar Javan
Hi Michael,
I can see that you have successfully linked against sage.
I also have a Qt GUI application which needs to do some mathematics in the 
background.
This application is targeted for windows platforms. I have installed sage 
from this link 

.
Could you please guide me on how to link my app with sage?

On Wednesday, September 14, 2011 at 4:15:58 AM UTC+4:30, Michael Rubinstein 
wrote:
>
> Thanks! That worked for me too, though I'm not sure how you decided on 
> the specific 
> choices of libraries to link to. 
>
> Mike 
>
> On Sep 13, 6:39 pm, Willem Jan Palenstijn  wrote: 
> > On Tue, Sep 13, 2011 at 08:46:05AM -0700, Michael Rubinstein wrote: 
> > 
> > > I tried adding PySys_SetArgv(argc, argv); after Py_Initialize(); 
> > > It gets me further but then gives a strange error message: 
> > 
> > > Loading the Sage library... 
> > 
> > >  
> > > Unhandled SIGSEGV: A segmentation fault occurred in Sage. 
> > > This probably occurred because a *compiled* component 
> > > of Sage has a bug in it (typically accessing invalid memory) 
> > > or is not properly wrapped with _sig_on, _sig_off. 
> > > You might want to run Sage under gdb with 'sage -gdb' to debug this. 
> > > Sage will now terminate (sorry). 
> > >  
> > 
> > I've just tried it here with your embed.c + PySys_SetArgv(argc, argv), 
> and it 
> > works for me when I link against libpython2.6 dynamically: 
> > 
> > $ gcc -I$SAGE_LOCAL/include/python2.6 embed.c -lpython2.6  -lm -lutil 
> -lpthread -ldl -o embed 
> > $ ./embed 
> > 1+1: 
> > 2 
> > Load sage 
> > Factor 2310: 
> > 2 * 3 * 5 * 7 * 11 
> > $ 
> > 
> > This is 64 bit linux with sage 4.7.1rc1. 
> > 
> > -Willem Jan

-- 
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] Reworked configure

2018-01-30 Thread Erik Bray
Hi anyone interested in Sage (the distribution's) build system,

I have a ticket that's been languishing for months now which makes
some significant overhauls to how Sage's build/make/Makefile is
generated and structured: https://trac.sagemath.org/ticket/21524
I know we're all very busy and that it's a difficult patch to
evaluate, so I haven't been too pushy about trying to get eyes on it.

But I've been doing some new work (rather successful so far) to
implement a general method for how I can easily add configure-time
checks to use system packages for more of Sage's dependencies, and
I've been doing this work on top of #21524.  So if I want to proceed
any further with that work I think progress is needed on this ticket.

The basic issue is that Sage's old configure.ac contains code in it
for directly writing the Makefile, rather than using a template (a
Makefile.in) per the usual autoconf pattern.  Of course, the fact that
we weren't doing that isn't *wrong*--after all there's nothing else
very "standard" about Sage's Makefile--so there was some question as
to why this was worth doing at all.  I think my approach to fixing the
issue answers that question: I think the resulting Makefile, and its
template, are easier to understand for one. And the resulting
configure script runs *much* faster. Especially on Cygwin where it has
always been painfully slow, but the speedup is even noticeable on a
fast Linux machine.

To summarize what this ticket changed:

1) The configure.ac template does not contain code that directly
writes the Makefile.  Instead, it loops *once* over all the packages
in build/pkgs, classifies them into various categories, and generates
some variables that are easily consumed by make (e.g. a list of
standard packages, and variables containing each package's
dependencies).

2) These variables are then inserted into a Makefile template
(Makefile.in) by config.status, at the end of running the configure
script, via the standard AC_OUTPUT mechanism.

3) Unlike the old Makefile, neither the new Makefile nor the template
it is generated from contain explicit rules for building each package.
As a result it's actually quite a bit shorter.  Instead it uses
relatively advanced features of GNU make (but easy to understand, I
think, especially with the inline comments I've added)--it uses the
variables substituted into the Makefile.in by configure along with
some simple templates and foreach/eval loops to generate the build and
clean rules for each package.

The result is a more compact Makefile that, for the most part, just
contains some variables with information about the individual
packages, and some templates for generating rules for the packages.

Most other parts of the Makefile, such as those included from
build/make/deps, remain mostly unchanged for now.

The resulting configure script is also much faster, as it only loops
over the packages once and performs some relatively simple checks,
since it has much less text to generate.  The old configure had a
shell function in it called filtered_packages_list that would loop
over all the packages and filter them according to some criteria, and
the old configure script called this four or five times, which was
responsible for much of the slowness.  The new script loops over the
packages only once to generate the variables needed by the Makefile.

Hopefully this makes sense, and will be of interest to someone.  I'm
not 100% married to all the details of my current approach, but I
think the general approach is much cleaner and, as I've noted, faster.

Best,
E

-- 
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] Re: TypeError: unsupported operand parent(s) for *: <(1,3)(2,4), (1,4,3,2)> and S4

2018-01-30 Thread Simon King
PS:

On 2018-01-30, Simon King  wrote:
> The coercion model chooses coercion to the left factor's parent, if
> there are coercions available in *both* directions. However, if there
> only is a coercion from the left factor's parent to the right factor's
> parent but not vice versa, that coercion is supposed to be used.

Jeroen just pointed out on trac, that indeed Sage believes that there is
not only a coercion from the subgroup to the group, but also from the
group to the subgroup, which is totally wrong (and the "coercion map"
from group to subgroup indeed raises an error when being applied to an
element of the group).

That would explain it.

-- 
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] Re: TypeError: unsupported operand parent(s) for *: <(1,3)(2,4), (1,4,3,2)> and S4

2018-01-30 Thread Simon King
Dear Hsin-Po Wang,

On 2018-01-30, Hsin-Po Wang  wrote:
> But it is still interesting to see if this is an unintentional bug in, say, 
> the coercion model and can be fixed.

We have
  sage: S4.has_coerce_map_from(S4.subgroups()[19])
  True

Hence, the coercion model is supposed to *automatically* convert the
element S4.subgroups()[19][1] into an element of S4, and then do the
multiplication.

Oddly enough,
  sage: S4[1]*S4.subgroups()[19][1]
  (1,4,2,3)
works (i.e., the right factor is automatically converted into the parent
of the left factor), but
  sage: S4.subgroups()[19][1]*S4[1]
doesn't work (as you reported).

The coercion model chooses coercion to the left factor's parent, if
there are coercions available in *both* directions. However, if there
only is a coercion from the left factor's parent to the right factor's
parent but not vice versa, that coercion is supposed to be used.

So, shortly, it is a clear bug. I created
https://trac.sagemath.org/ticket/24612 for it.

Thank you for reporting it!
Best regards,
Simon

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