[sage-devel] Re: failures on 8.3.beta3 (probably due to meataxe?)
PS: I find the wording "failures on 8.3.beta3 (probably due to meataxe?)" misleading. Neither MeatAxe nor its wrapper in Sage have changed. So, the failure is (probably) due to Sage. The change in Sage broke one of its optional packages and should thus better not be part of an official release, IMHO. Can you tell what ticket has introduced the bug? 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.
[sage-devel] Re: failures on 8.3.beta3 (probably due to meataxe?)
On 2018-05-30, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > Hallo Simon, > > I did not open a ticket. And I confirm that not installing meataxe > solves the problem (quasar is up and running). For the record: I created ticket #25476. -- 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: failures on 8.3.beta3 (probably due to meataxe?)
Hallo Simon,
I did not open a ticket. And I confirm that not installing meataxe
solves the problem (quasar is up and running).
Vincent
On 30/05/2018 17:49, Simon King wrote:
Hi Vincent,
On 2018-05-30, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
A.rescale_row(r, a_inverse, c)
File "sage/matrix/matrix0.pyx", line 3005, in
sage.matrix.matrix0.Matrix.rescale_row
(build/cythonized/sage/matrix/matrix0.c:21880)
self.rescale_row_c(i, s, start_col)
File "sage/matrix/matrix_gfpn_dense.pyx", line 944, in
sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense.rescale_row_c
(build/cythonized/sage/matrix/matrix_gfpn_dense.c:9339)
raise ValueError("We can only rescale a full row of a non-empty
matrix")
ValueError: We can only rescale a full row of a non-empty matrix
**
Did you create a ticket? Set me on Cc of course. Is it perhaps the case
that c>0? I.e., that we rescale only a part of a row? I can implement
that functionality of course, although it will be slightly slower than
the current implementation.
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.
Re: [sage-devel] Re: python3 status
On Wednesday, May 30, 2018 at 9:01:59 AM UTC-7, Nils Bruin wrote:
>
>
> Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal
> environment (where SAGE_ROOT is not set) then I get:
>
> Error: You must set the SAGE_ROOT environment variable or run this
> script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory.
> Error setting environment variables by sourcing
> '/usr/local/sage/sage-git/local/bin/sage-env';
> possibly contact sage-devel (see http://groups.google.com/group/sage-devel
> ).
>
> If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is
> figured out and everything works fine when called from my normal
> environment.
>
>
I agree that we should make $SAGE_LOCAL/bin/sage work without environment
variables set.
We discussed this in https://trac.sagemath.org/ticket/21479 ("./configure
--prefix=SAGE_LOCAL"), when $SAGE_LOCAL/bin/sage-env-config was introduced;
but then a less ambitious solution was implemented for that ticket.
We could add a line setting $SAGE_ROOT in $SAGE_LOCAL/bin/sage-env-config
(via src/bin/sage-env-config.in).
On the other hand, of course, most uses of SAGE_ROOT have been eliminated
(see https://trac.sagemath.org/ticket/21591 - Replace use of SAGE_ROOT by
more specific environment variables); and it would be good to finish this
job and allow sage to work without having to complain about this
environment variable.
--
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: Matrix groups are not uniquely represented, why?
> Well, that's not a matrix group in a canonical way, so there's a good reason for that (and, if you're interested in the abstract group it may well be that the permutation representation is the fastest to work with). Agree, but it would be nice to say G = PGL(2,13) and then G(some matrix) to get its class or backwards to represent an element by a matrix, etc. But that is a different stroy than what this tread was about. -- 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: Matrix groups are not uniquely represented, why?
On Wednesday, May 30, 2018 at 1:35:43 AM UTC-7, chris wuthrich wrote: > I am also often unhappy about PGL, which returns a permutation group, by > the way. > Well, that's not a matrix group in a canonical way, so there's a good reason for that (and, if you're interested in the abstract group it may well be that the permutation representation is the fastest to work with). -- 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: python3 status
On Wednesday, May 30, 2018 at 1:28:25 AM UTC-7, Jeroen Demeyer wrote: > > On 2018-05-29 22:57, Nils Bruin wrote: > > it would also be useful to > > use a "sage" executable that can figure out $SAGE_ROOT from scratch. > > Can you say more precisely what you mean with this? > Currently, if I run the script $SAGE_LOCAL/bin/sage in my normal environment (where SAGE_ROOT is not set) then I get: Error: You must set the SAGE_ROOT environment variable or run this script from the SAGE_ROOT or SAGE_ROOT/local/bin/ directory. Error setting environment variables by sourcing '/usr/local/sage/sage-git/local/bin/sage-env'; possibly contact sage-devel (see http://groups.google.com/group/sage-devel). If instead I run the script $SAGE_ROOT/sage a value for SAGE_ROOT is figured out and everything works fine when called from my normal environment. If I change sage's kernel_spec to run the latter, I can use the whole SAGE_LOCAL/share/jupyter/kernels/sagemath jupyter kernel description directly with /usr/bin/jupyter (via a symlink or so). I think that's an advantage. If it were up to me, I would probably inject the logic of SAGE_ROOT/sage into SAGE_LOCAL/bin/sage because for me that would work fine. Linking to SAGE_LOCAL/share/jupyter/kernels/sagemath has the advantage that upgrades are automatically picked up when I use /usr/bin/jupyter. I can of course copy & edit files, but then they are not kept up-to-date. Similarly, I could edit the file in-place (e.g., equip the script with a hard-coded value for SAGE_ROOT), but then I have to deal with a source tree that is forever patched wrt. vanilla. -- 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: failures on 8.3.beta3 (probably due to meataxe?)
Hi Vincent,
On 2018-05-30, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> A.rescale_row(r, a_inverse, c)
>File "sage/matrix/matrix0.pyx", line 3005, in
> sage.matrix.matrix0.Matrix.rescale_row
> (build/cythonized/sage/matrix/matrix0.c:21880)
> self.rescale_row_c(i, s, start_col)
>File "sage/matrix/matrix_gfpn_dense.pyx", line 944, in
> sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense.rescale_row_c
> (build/cythonized/sage/matrix/matrix_gfpn_dense.c:9339)
> raise ValueError("We can only rescale a full row of a non-empty
> matrix")
> ValueError: We can only rescale a full row of a non-empty matrix
> **
Did you create a ticket? Set me on Cc of course. Is it perhaps the case
that c>0? I.e., that we rescale only a part of a row? I can implement
that functionality of course, although it will be slightly slower than
the current implementation.
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.
[sage-devel] failures on 8.3.beta3 (probably due to meataxe?)
Dear all,
On beta3 the quasar patchbot found failures related to matrices. A
prototypical example is
**
File "src/sage/coding/linear_code.py", line 2039, in
sage.coding.linear_code.AbstractLinearCode.__getitem__
Failed example:
C = random_matrix(GF(25,'a'), 2, 7).row_space()
Exception raised:
Traceback (most recent call last):
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/doctest/forker.py",
line 572, in _run
self.compile_and_execute(example, compiler, test.globs)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/doctest/forker.py",
line 982, in compile_and_execute
exec(compiled, globs)
File "sage.coding.linear_code.AbstractLinearCode.__getitem__[4]>", line 1, in
C = random_matrix(GF(Integer(25),'a'), Integer(2),
Integer(7)).row_space()
File "sage/matrix/matrix2.pyx", line 4592, in
sage.matrix.matrix2.Matrix.row_space
(build/cythonized/sage/matrix/matrix2.c:34495)
return self.row_module(base_ring=base_ring)
File "sage/matrix/matrix2.pyx", line 4565, in
sage.matrix.matrix2.Matrix.row_module
(build/cythonized/sage/matrix/matrix2.c:34373)
return M.span(self.rows(), already_echelonized=False)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/modules/free_module.py",
line 3850, in span
self.ambient_module(), gens=gens, check=check,
already_echelonized=already_echelonized)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/modules/free_module.py",
line 6961, in __init__
echelonize=not already_echelonized,
already_echelonized=already_echelonized)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/modules/free_module.py",
line 6763, in __init__
echelonized_basis=echelonized_basis,
already_echelonized=already_echelonized)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/modules/free_module.py",
line 5691, in __init__
basis = self._echelonized_basis(ambient, basis)
File
"/home/vdelecro/sage_patchbot/local/lib/python2.7/site-packages/sage/modules/free_module.py",
line 6894, in _echelonized_basis
E = A.echelon_form()
File "sage/matrix/matrix2.pyx", line 6819, in
sage.matrix.matrix2.Matrix.echelon_form
(build/cythonized/sage/matrix/matrix2.c:53810)
v = E.echelonize(cutoff=cutoff, **kwds)
File "sage/matrix/matrix2.pyx", line 6719, in
sage.matrix.matrix2.Matrix.echelonize
(build/cythonized/sage/matrix/matrix2.c:53210)
self._echelon_in_place(algorithm)
File "sage/matrix/matrix2.pyx", line 6984, in
sage.matrix.matrix2.Matrix._echelon_in_place
(build/cythonized/sage/matrix/matrix2.c:54847)
A.rescale_row(r, a_inverse, c)
File "sage/matrix/matrix0.pyx", line 3005, in
sage.matrix.matrix0.Matrix.rescale_row
(build/cythonized/sage/matrix/matrix0.c:21880)
self.rescale_row_c(i, s, start_col)
File "sage/matrix/matrix_gfpn_dense.pyx", line 944, in
sage.matrix.matrix_gfpn_dense.Matrix_gfpn_dense.rescale_row_c
(build/cythonized/sage/matrix/matrix_gfpn_dense.c:9339)
raise ValueError("We can only rescale a full row of a non-empty
matrix")
ValueError: We can only rescale a full row of a non-empty matrix
**
Vincent
--
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: Matrix groups are not uniquely represented, why?
> I think it is a bad thing in this case for == to be equality as sets. > Imagine if these are two really big, equal, but differently constructed > subgroups. This would be a really long and expensive check, whereas in most > cases, checking the defining objects are sufficient. I believe we have > other places in Sage where == is not strict mathematical equality for > similar reasons. -1 on changing the == semantics here. > > I am strongly in favour of changing all the other instances of wrong ==; or, at least, that they are well documented aberations. Or that we rename things (like subgroups_with_generator) to make it mathematically correct again. If ever a user wants to check that the two subgroups were given by the same generators then he will check if .gens() are equal. Otherwise he will know that it may take time to test equality, just like with any other function. I am happy with John's example of quadratic fields. The QQ-algebras QuadraticField(2) and QuadraticField(8) are not equal in any canonical thing they are contained in as there are two isomorphisms between them. > Now I would say the equality as sets (which really comes down to equality > of elements) is a bug. Two matrix group elements should compare by their > matrices and not have the coercion system involved otherwise. My guess is > the coercion system tries to convert the elements of H into H3 and vice > versa, which is cannot do, and hence, results in a False for equality. This > probably requires a reimplementation of the comparison method of matrix > group elements. > Yes, fully agree. In fact elements should not have a "matrix" at all, since they are matrices by definition to the user. The element class, like many other group things, may want to be worked over completely. I am also often unhappy about PGL, which returns a permutation group, by the way. Chris -- 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: Matrix groups are not uniquely represented, why?
> In summary, if we implement subgroups in such a way that testing equality is not implemented then it is very misleading to return False every time. I've run into this issue before (that two subgroups of the same ambient matrix group can compare as unequal, despite having the same elements). See https://trac.sagemath.org/ticket/24301, where there is some discussion between Travis and me whether this should be considered a bug. (Of course, however one feels about that matter, there is no question that testing Set( h for h in H ) == Set( h for h in H3 ) should return True and anything else is a definite bug.) David On 30 May 2018 at 09:06, John Cremona wrote: > > > On 30 May 2018 at 07:14, Travis Scrimshaw wrote: > >> >> >> On Tuesday, May 29, 2018 at 9:01:51 PM UTC+10, chris wuthrich wrote: >>> >>> >>> As a simple-minded user I stumbled over exactly this last week. I don't >>> understand much of what this thread is discussing, but I know what a >>> simple-minded user wants. >>> >>> sage: G = GL(2,13) >>> sage: G = G.as_matrix_group() >>> sage: H = G.subgroup([ matrix(GF(13),[[1,0],[1,1]]) ]) >>> sage: H2 = G.subgroup([ matrix(GF(13),[[1,1],[0,1]]) ]) >>> sage: H3 = G.subgroup([ matrix(GF(13),[[1,0],[2,1]]) ]) >>> >>> I expect H == H3 to say True as they are the same subgroup. >>> I expect H = H2 to say False, since they are not the same subgroup, even >>> though they are isomorphic. >>> Instead >>> >>> sage: H == H3 >>> False >>> sage: matrix(GF(13),[[1,0],[1,1]]) in H3 >>> True >>> sage: matrix(GF(13),[[1,0],[2,1]]) in H >>> True >>> sage: H.is_isomorphic(H3) >>> True >>> sage: H.is_isomorphic(H2) >>> True >>> sage: matrix(GF(13),[[1,0],[1,1]]) in H2 >>> False >>> >>> I though of working around it by checking if they are the same as sets, >>> but to my surprise: >>> >>> sage: Set( h for h in H ) == Set( h for h in H3 ) >>> False >>> sage: Set( h.matrix() for h in H ) == Set( h.matrix() for h in H3 ) >>> True >>> >>> In short: I consider this a bug. No matter how this is done at the back, >>> the user expects == to mean mathematical equality, here equality of >>> subgroups. Otherwise the function should be called >>> subgroups_with_given_generators. >>> >>> I think it is a bad thing in this case for == to be equality as sets. >> Imagine if these are two really big, equal, but differently constructed >> subgroups. This would be a really long and expensive check, whereas in most >> cases, checking the defining objects are sufficient. I believe we have >> other places in Sage where == is not strict mathematical equality for >> similar reasons. -1 on changing the == semantics here. >> > > We should then admit that users will regularly be surprised. Perhaps this > is similar to the situation for evaluating boolean expressions, where (I > seem to remember) False is returned in case of "don't know". Any subgroup > constructor (e.g. from generators) which results in a subgroup for which > testing membership is impossible (or worse, silently returns False for > every element of the ambient group) is surely not going to be very useful; > and if there is a membership test then testing two subgroups for equality > is easy (though of course possibly slow). > > In summary, if we implement subgroups in such a way that testing equality > is not implemented then it is very misleading to return False every time. > > >> >> Now I would say the equality as sets (which really comes down to equality >> of elements) is a bug. Two matrix group elements should compare by their >> matrices and not have the coercion system involved otherwise. My guess is >> the coercion system tries to convert the elements of H into H3 and vice >> versa, which is cannot do, and hence, results in a False for equality. This >> probably requires a reimplementation of the comparison method of matrix >> group elements. >> > > +1 to that. > > >> >> Best, >> Travis >> >> -- >> 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. >> > > -- > 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. > -- 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
Re: [sage-devel] Re: python3 status
On 2018-05-29 22:57, Nils Bruin wrote: it would also be useful to use a "sage" executable that can figure out $SAGE_ROOT from scratch. Can you say more precisely what you mean with this? -- 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] Book Review of Stein book
On 30 May 2018 at 08:10, Erik Bray wrote: > On Fri, May 25, 2018 at 9:13 PM, John Cremona > wrote: > > > > > > On 25 May 2018 at 18:47, kcrisman wrote: > >> > >> Less relevant, but still ... Also probably behind a paywall ... anyway, > >> this is a review of Barry Mazur and William Stein's book on the Riemann > >> Hypothesis by someone who knows something about writing good books about > >> analytic number theory and representation theory. No Sage in the > review but > >> see the Github repo for the book https://github.com/williamstein/rh > for the > >> worksheets/code that generated the illustrations. > >> > >> https://www.tandfonline.com/doi/full/10.1080/00029890.2018.1438005 > > > > > > Yes, there is a paywall for all but the first page of the review. (They > > offered to let me have 24 hours access to the review for £35 which is > rather > > more than the entire book costs). > > Huh, maybe it's because I'm on an academic network or something but i > was able to get the full review directly at that link without doing > anything. > Unfortunately that's not the case from the University of Warwick. > > Sounds like a good book! ;) > > -- > 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. > -- 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: Matrix groups are not uniquely represented, why?
On 30 May 2018 at 07:14, Travis Scrimshaw wrote: > > > On Tuesday, May 29, 2018 at 9:01:51 PM UTC+10, chris wuthrich wrote: >> >> >> As a simple-minded user I stumbled over exactly this last week. I don't >> understand much of what this thread is discussing, but I know what a >> simple-minded user wants. >> >> sage: G = GL(2,13) >> sage: G = G.as_matrix_group() >> sage: H = G.subgroup([ matrix(GF(13),[[1,0],[1,1]]) ]) >> sage: H2 = G.subgroup([ matrix(GF(13),[[1,1],[0,1]]) ]) >> sage: H3 = G.subgroup([ matrix(GF(13),[[1,0],[2,1]]) ]) >> >> I expect H == H3 to say True as they are the same subgroup. >> I expect H = H2 to say False, since they are not the same subgroup, even >> though they are isomorphic. >> Instead >> >> sage: H == H3 >> False >> sage: matrix(GF(13),[[1,0],[1,1]]) in H3 >> True >> sage: matrix(GF(13),[[1,0],[2,1]]) in H >> True >> sage: H.is_isomorphic(H3) >> True >> sage: H.is_isomorphic(H2) >> True >> sage: matrix(GF(13),[[1,0],[1,1]]) in H2 >> False >> >> I though of working around it by checking if they are the same as sets, >> but to my surprise: >> >> sage: Set( h for h in H ) == Set( h for h in H3 ) >> False >> sage: Set( h.matrix() for h in H ) == Set( h.matrix() for h in H3 ) >> True >> >> In short: I consider this a bug. No matter how this is done at the back, >> the user expects == to mean mathematical equality, here equality of >> subgroups. Otherwise the function should be called >> subgroups_with_given_generators. >> >> I think it is a bad thing in this case for == to be equality as sets. > Imagine if these are two really big, equal, but differently constructed > subgroups. This would be a really long and expensive check, whereas in most > cases, checking the defining objects are sufficient. I believe we have > other places in Sage where == is not strict mathematical equality for > similar reasons. -1 on changing the == semantics here. > We should then admit that users will regularly be surprised. Perhaps this is similar to the situation for evaluating boolean expressions, where (I seem to remember) False is returned in case of "don't know". Any subgroup constructor (e.g. from generators) which results in a subgroup for which testing membership is impossible (or worse, silently returns False for every element of the ambient group) is surely not going to be very useful; and if there is a membership test then testing two subgroups for equality is easy (though of course possibly slow). In summary, if we implement subgroups in such a way that testing equality is not implemented then it is very misleading to return False every time. > > Now I would say the equality as sets (which really comes down to equality > of elements) is a bug. Two matrix group elements should compare by their > matrices and not have the coercion system involved otherwise. My guess is > the coercion system tries to convert the elements of H into H3 and vice > versa, which is cannot do, and hence, results in a False for equality. This > probably requires a reimplementation of the comparison method of matrix > group elements. > +1 to that. > > Best, > Travis > > -- > 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. > -- 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: performance problems with Set (again)
> I am sorry, I certainly did not want to offend. Please excuse me. > It's okay; I wasn't offended, but it was off-putting to me. I hope I was able to explain my impression without offending you. > > Thank you also for your explanation of the reason for having Set. Related > to this: is OK if > > sage: [b for b in my_set_partition] > > yields a list of frozensets? If so, I am almost done (currently running > all doctests outside of combinat, combinat is already passing). > This would be acceptable from an internal workings point of view, but you would not want it to be public. Publicly it should be a SetPartition, but an iteration over that can yield a frozenset. We might need to issue some kind of warning because there are slight behavioral differences between a frozenset and a Sage Set. Best, Travis -- 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] Book Review of Stein book
On Fri, May 25, 2018 at 9:13 PM, John Cremona wrote: > > > On 25 May 2018 at 18:47, kcrisman wrote: >> >> Less relevant, but still ... Also probably behind a paywall ... anyway, >> this is a review of Barry Mazur and William Stein's book on the Riemann >> Hypothesis by someone who knows something about writing good books about >> analytic number theory and representation theory. No Sage in the review but >> see the Github repo for the book https://github.com/williamstein/rh for the >> worksheets/code that generated the illustrations. >> >> https://www.tandfonline.com/doi/full/10.1080/00029890.2018.1438005 > > > Yes, there is a paywall for all but the first page of the review. (They > offered to let me have 24 hours access to the review for £35 which is rather > more than the entire book costs). Huh, maybe it's because I'm on an academic network or something but i was able to get the full review directly at that link without doing anything. Sounds like a good book! ;) -- 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: performance problems with Set (again)
Dear Travis, I am sorry, I certainly did not want to offend. Please excuse me. Thank you also for your explanation of the reason for having Set. Related to this: is OK if sage: [b for b in my_set_partition] yields a list of frozensets? If so, I am almost done (currently running all doctests outside of combinat, combinat is already passing). (I opened a ticket at https://trac.sagemath.org/ticket/25462) Thanks again, Martin -- 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: performance problems with Set (again)
On Wed, May 30, 2018 at 8:38 AM, Travis Scrimshaw wrote: > Hi Martin, > >> I am frustrated with the following and would like to fix it: >> >> >> Is "Set" supposed to be slow? Replacing "Set" with "set" in >> "SetPartition.__init__" is a huge improvement, we go down to about 5.5 ms >> per loop, but "Set" has bitten me performance >> (https://trac.sagemath.org/ticket/23877) and featurewise >> (https://trac.sagemath.org/ticket/23324) already so often, that I'd rather >> get rid of it altogether. Is there any point at all in having "Set"? > > > I can certainly hear your frustration, but these kinds of comments make me > far less willing to help you as it makes me feel like it is flamebait and > you are too narrowly focused on your issues. > > Yes, there are a number of reasons to have Set. It allows you to work within > Sage's Parent/Element framework, the nice output representations, it is > hashable when the input objects are hashable, and the code can be easier to > understand (e.g., you cannot do X + Y with (frozen)sets and it doesn't have > a method to get subsets). However, as Sébastien said, it is better to use > frozenset internally, but there is a caveat, this only works whenever you > want to assume your objects are hashable. Now for SetPartition, I think that > is a reasonable assumption and should be changed. However, it might require > a fairly substantial overhaul of that code and a number of other places > where that code is used to build iterators. +1 for you making such > improvements to SetPartitions. The way I see it, Set is a high-level object representing a mathematical Set in the sense needed to fit in with Sage's categorical framework. It has many more features than the set built-in. Comparing it performance to the set built-in is unfair because they serve different purposes (that said, I'm sure the performance of Set could be improved). The set built-in is just a low-level data structure. Saying it's slow is like saying that a list of lists is slower than a matrix type. Yes they're effectively able to represent the same data structure, but were designed for different use cases. I'd say for implementation details of some code just use set or frozenset (if you want immutability/hashability) and only use Sage's Set for when it's explicitly needed. -- 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.
