Re: [sage-devel] Names of objects in sage

[Johan S. H. Rosenkilde]

> The current implementations of _repr_ gets somewhat ridiculous when we 
> combine these naming conventions in classes like CombinatorialFreeModules 
> where we end up producing things like:
>
> sage: IwahoriHeckeAlgebra('A3',q,1)
> Iwahori-Hecke algebra of type A3 in q,1 over Univariate Polynomial Ring in q 
> over Finite Field of size 5
>
> If you happen to be working over nested multivariate polynomial rings, as I 
> happen to be at the moment, then it can take 3-4 lines to print the object. 
> Personally, in the last case I would rather print

For coding theory, we recently shortened the printing considerably for
the same reason. We used to have

sage: codes.random_linear_code(GF(25), 10, 3)
Linear code of length 10 and dimension 3 over Finite Field in z2 of size 5^2

but now use the standard nomenclature for coding theory with a short
field description:

sage: C = codes.random_linear_code(GF(25), 10, 3); C
[10, 3] linear code over GF(25)

This is especially very nice in composite constructions where the
printing of the code enters as a sub-string:

sage: C.encoder()
Generator matrix-based encoder for [10, 3] linear code over GF(25)

sage: C.punctured([0, 1])
Puncturing of [10, 3] linear code over GF(125) on position(s) [0, 1]

sage: codes.SubfieldSubcode(C, GF(5))
Subfield subcode of [10, 3] linear code over GF(125) down to GF(5)

One argument in favour of having a special convention here is that a
linear code is always over a finite field, so there's not much room for
confusion. The main argument against this kind of thing is of course
that it is Bad to go against the general Sage convention, and that it is
clumsy to have special printing code in each sub-module of Sage.

Best,
Johan

-- 
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] Senseless leading_ methods introduced on all matrices

[Johan S. H. Rosenkilde]

Vincent Delecroix writes:

> If the basis of a "Finite dimensional module with basis" is always assumed to 
> be
> ordered, then such method make sense. However, the terminology is quite 
> strange.
> I see 1+1/2 ambiguities for matrices over polynomial ring such as Mat(ZZ[X], 
> 3).
>
> 1) leading_coefficient might be a termwise application of leading_coefficient
>
>  [1X^2+X+1]
>  [X+3  2*X-3  ]
>
> would result in
>
>  [1 1]
>  [1 2]
>
> 2) There is an additional trouble if Mat(ZZ[X], 3) is intended to be 
> equivalent
> to polynomial ring over matrices Mat(ZZ, 3)[X]. Such matrix can naturally be
> written as
>
>   M0 + M1 X + M2 X^2 + ... + Md X^d
>
> where M0, M1, ..., Md are matrices with coefficients in ZZ. With the above
> writing, the leading coefficient is Md.

Indeed. And then, as a third option, the one we are introducing in
#23619 as leading_matrix, where we take for each row v, the coefficients
of terms of deg(v):

[1X^2+X+1]  [0 1]
leading_matrix( [X+3  2*X-3  ] ) =  [1 1]

Best,
Johan

-- 
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: Senseless leading_ methods introduced on all matrices

[Johan S. H. Rosenkilde]

Travis Scrimshaw writes:
>> While it is arguably too rigid to say that this is "senseless" (as I 
>> wrote in the subject),
>
> You already did that, and because you started off calling them "senseless," 
> you have polluted this issue with your heavily loaded question. That is 
> unfair and demeaning.

Yes, I'm guilty, I gave the thread a provocative name to make people
read it...


>> I believe that the use of these functions for 
>> matrices is very narrow.
>
> That is untrue. They are very useful to create any sort of 
> submodule/algebra of the matrix module/algebra to be consistent with all 
> other modules or algebras with a distinguished basis. There is also a 
> natural order on the basis too, so things like triangularity of module 
> morphisms need such methods. So perhaps the field of representation theory 
> and triangularity of morphisms is "very narrow."

Good point, as was Simon's concrete example.

> Let's get rid of hamming_weight for polynomials since polynomials are also 
> extremely central objects that beginners start playing around with. Of 
> course, I am not actually proposing this, but this is in the same spirit.

I disagree that this is in the same spirit: the hamming weight/sparsity
of a polynomial is a readily understandable concept, pertaining to
polynomials directly, whose functionality anyone "playing around" with
polynomials will recognise. As opposed to this, these generic finite
rank module methods seem not useful for matrices themselves, but
primarily as glue in a much more abstract context that you described
above.


>> (this came up during #23619 where we are introducing "leading_matrix" 
>> and "leading_position" for matrices over a univariate polynomial ring.) 
>>
>> I think you should be more explicit with your method names and call the 
> first one leading_term_matrix() and the second one I have no idea why it 
> would do.

I would argue that the burden of explicit method names should be *much
higher* on abstract, inherited methods! While I can see the argument for
preferring "leading_term_matrix" in favour of "leading_matrix", it is
important to keep in mind that this method will only appear for matrices
over univariate polynomials, and the user therefore expects its methods
to be named and behave accordingly.

Compare this with "leading_coefficient" on a matrix; most users would
have no idea what that is before they read the doc, and even then -
since the doc is written with totally different examples in mind - they
have to call that method and perhaps "leading_position" several times
before they can figure it out.


I won't argue further against whether the methods should be there
or not. If several mathematicians feel they are really useful, I'm sure
you're right. But then I would argue that they should be renamed into
something much more precise, or perhaps hidden behind an indirection.
Perhaps something like:

sage: M.as_finite_rank_module.leading_?

(except that this sounds like the matrix becomes a finite rank module
which is nonsense.)

Best,
Johan

-- 
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] Senseless leading_ methods introduced on all matrices

[Johan S. H. Rosenkilde]

Compared to Sage 8.0, matrices in Sage 8.1.beta1 now have a host of new
methods:

  - leading_coefficient
  - leading_item
  - leading_monomial
  - leading_support
  - leading_term

These are inherited from the category of finite dimensional modules with
basis of which matrix spaces are now members.

The semantics is that an e.g. 3x3 matrix over R is an R-module over the
basis

   [1 0 0]  [0 1 0]  [0 0 1]
   [0 0 0], [0 0 0], [0 0 0], ...
   [0 0 0]  [0 0 0]  [0 0 0]

and hence, M.leading_coefficient() on such a matrix returns M[2,2] if
this is non-zero, otherwise M[2,1] if this is non-zero, etc.

While it is arguably too rigid to say that this is "senseless" (as I
wrote in the subject), I believe that the use of these functions for
matrices is very narrow. And since matrices are an extremely central
object that beginners immediately start playing around with, it is
unfortunate that they will pollute the tab-completion to such a degree,
and with doc strings which are not very helpful to the algebraically
uninitiated.

My question here is whether it is really intended that all matrices get
stuck with these (almost) senseless methods?

(this came up during #23619 where we are introducing "leading_matrix"
and "leading_position" for matrices over a univariate polynomial ring.)

Best,
Johan

-- 
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] Two issues about the coding theory method "weight_enumerator"

[Johan S . H . Rosenkilde]

Thanks a lot for reporting! We *really* appreciate any feedback from
using Sage in classes: on bugs, designs and feature requests.

This bug is now #23433. I'll push a patch momentarily.

Best,
Johan Rosenkilde


Dima Pasechnik writes:

> On Thursday, July 13, 2017 at 11:43:18 AM UTC+1, David Joyner wrote:
>>
>> On Thu, Jul 13, 2017 at 5:59 AM, 'B. L.' via sage-devel 
>>  wrote: 
>> > Dear Sage-Developers, 
>> > 
>> > I'd like to report two issues that I came across when working with the 
>> > coding theory classes of SAGE. 
>> > 
>> > The Sage Reference Manual: Coding Theory, Release 7.6 [1] explains on p. 
>> 31: 
>> > weight_enumerator [...] This is the bivariate, homogeneous polynomial in 
>> 푥 
>> > and 푦 whose coefficient to x^iy^{n-i} is the number of codewords of 
>> > 푠푒푙푓 of Hamming weight 푖. Here, 푛 is the length of 푠푒푙푓. 
>> > Actually, Sage returns another polynomial, namely the polynomial in 푥 
>> and 
>> > 푦 whose coefficient to x^{n-i}y^i is the number of codewords of 
>> 푠푒푙푓 of 
>> > Hamming weight 푖. (So the roles of x and y are interchanged). 
>> > This can be directly with C.weight_enumerator?? in the example below 
>> [2]. 
>> > 
>> > I suggest to either change the description in the reference or to alter 
>> the 
>> > code in Sage. 
>> > 
>>
>> I'd propose just switching the x,y in the code: 
>>
>> (1) On line 3503 of linear_code.py, change "return 
>> sum(spec[i]*x**(n-i)*y**i for i in range(n+1))" to "return 
>> sum(spec[i]*x**(i)*y**(n-i) for i in range(n+1))" 
>>
>> (2) On line 3507, change "return sum(spec[i]*x**(n-i) for i in 
>> range(n+1))" to "return sum(spec[i]*x**(i) for i in range(n+1))" 
>>
>> (3) Some of the examples may change accordingly. 
>>
>> This mistake could be my fault, since I wrote the original version 
>> (long long ago). Unfortunately, I lack the git skills to submit a 
>> patch. 
>>
>> A patch can be produced by
>
> git diff > stuff.patch
>
> It would be great if you opened a ticket and posted this diff as an 
> attachment...
>  
>  
>
>>
>> > The function weight_enumerator(bivariate=False) returns the evaluation 
>> of 
>> > the the above polynomial for y=1. Should't it be (in the current 
>> version) 
>> > the evaluation with x=1? In other words: Wouldn't one expect a 
>> polynomial in 
>> > x (or y) whose coefficient to x^i (or y^i) is the number of codewords of 
>> > 푠푒푙푓 of Hamming weight 푖? 
>> > The example below [2] illustrates my point: The code has four codewords, 
>> one 
>> > of weight 0, two of weight 3, one of weiht 4. Sage gives x^5 + 2*x^2 + x 
>> as 
>> > the univariate weight enumerator. I would have expected either 1 + 2*x^3 
>> + 
>> > x^4 or 1 + 2*y^3 + y^4. 
>> > 
>> > If you agree, I suggest to alter the code accordingly. 
>> > 
>> > Kind regards 
>> > Barbara 
>> > PS: I tested the code with Sage version 7.6 on an iMac. 
>> > 
>> > 
>> > [1] http://doc.sagemath.org/pdf/en/reference/coding/coding.pdf 
>> > 
>> > [2] Sage code for  the SageMathCell 
>> > 
>> > C= LinearCode(Matrix(GF(2),2,5, [[1,1,0,1,0], [0,0,1,1,1]])) 
>> > print C.list() 
>> > print C.spectrum() 
>> > print C.weight_enumerator() 
>> > print C.weight_enumerator(bivariate=False) 
>> > C.weight_enumerator?? 
>> > 
>> > 
>> http://sagecell.sagemath.org/?z=eJxztlXwycxLTSxyzk9J1fBNLCnKrNBwd9Mw0tQx0jHVUYiONtQx1DEA4VggzwDMBMLYWE1NXq6Cosy8EgVnvZzM4hINJH5xQWpySVFpLrJYeWpmekZJfGpeaW5qUWJJfhF-yaTMssSizMSSVFu3xJziVKBaLKrs7QGIgD2K=sage
>>  
>> > 
>> > -- 
>> > 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: [ODK participants] Blog post on fast multivariate arithmetic

[Johan S . H . Rosenkilde]

> That's absolutely correct, and a point I make in my blog. One heuristic is 
> that GBs tend to have a large number of very small polynomials and so one 
> can dispatch larger arithmetic operations to a different back end safely 
> (converting to and from some other format on the fly). This is something 
> Singular already does, I believe.

I guess for a system like Sage it makes sense to use a default backend
that optimises for fast arithmetic. A GB computation is something one
expects to be long, so it seems OK to take a small amount of time
converting to a GB-optimised backend whenever a GB-computation is
called.

Best,
Johan

-- 
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] Second round poll for H2 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

+1 to "this lattice" and +1/2 to "the lattice". In either case I think
it should mention in the guideline that using ``self`` is also
acceptable if the sentence would become more clear.


Kwankyu Lee writes:

> Hi,
>
> I prepared H2 revised from G2 based on your ideas and wishes. It was hard 
> to make a compromise from your differing opinions and reach a proposal for 
> the better. So this time* if I fail to get approval from most of you, the 
> guideline will be simply discarded.*  
> **
> H2. Write
>
> if the lattice is reflexive 
>
> but do not write
>
> if ``self`` is reflexive
> 
> If you agree, flag +1; if you don't, flag -1.

-- 
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] Second round poll for H4 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

+1

-- 
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] Second round poll for H5 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

> As I mentioned on the other thread, since OUTPUT is not a list of things 
> (as opposed to INPUT), I would prefer
>
> OUTPUT: tuple of lattices

+1 on this option (and hence -1 to the thread's suggestion).

-- 
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] Second round poll for H1 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

+1

-- 
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] Secondl round poll for H6 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

> H6. Write
>
> INPUT: 
>
> - ``n`` -- integer (default: 1); the number of repetition

+1. I agree with the grammatical reasons to slightly prefer ";" over ","
(but I am not a native speaker).

-- 
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] Second round poll for H3 a specific guideline for writing docstrings

[Johan S . H . Rosenkilde]

+1

Kwankyu Lee writes:

> Hi,
>
> I prepared H3 revised from G3 based on your ideas and wishes. It was hard 
> to make a compromise from your differing opinions and reach a proposal for 
> the better. So this time* if I fail to get approval from most of you, the 
> guideline will be simply discarded.*  
> **
> H3. Write
>
> Return whether the lattice is reflexive.
>
> but do not write
>
> Return ``True`` if the lattice is reflexive and ``False`` otherwise.
>
> 
> If you agree, flag +1; if you don't, flag -1.

-- 
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] I need advice on my paper and Sage code on "Classifying bent functions by their Cayley graphs"

[Johan S . H . Rosenkilde]

Hi Paul,

>1. Is there a process to ask for a code review of this type of code 
>(i.e. code primarily written to support a paper)?

Alas, one of the weaknesses of the current research publication process...

>2. Do you have any suggestions as to how and where I could publish a 
>fully peer reviewed version of such a long (52 page draft) paper with so 
>many examples, tables and figures?

I'm not an expert on bent functions by a long shot, but I think Journal
of Designs, Codes and Cryptography would be appropriate. Otherwise, look
up recent journal papers on bent functions and see where they publish.

52 pages is quite long, though presumably a lot of this is tables and
pictures. You should be prepared that reviewers might ask you to
drastically shorten the exposition, perhaps by including fewer examples
in the main text and the rest in an online repository.

Another model is to have a shortish version - say 20-30 pages single
column - published in a journal, and then put an extended version on
arXiv.

Good luck.

Best,
Johan


Paul Leopardi writes:

> Hello all,
>
> I have just completed the first draft of a paper, "Classifying bent 
> functions by their Cayley graphs". 
> 
>  
> The computational results of the paper are fully reproducible via worksheets 
> in a SageMathCloud public folder 
> 
>  
> and Sage code in a GitHub repository 
> .
> When I developed the code I tried to follow the Sage coding conventions 
> , but my 
> primary goal up until now has been to obtain results and finish the paper 
> while keeping the code as clear and readable as I could.
>
>
> The purpose of the code is to calculate the Cayley graph classifications of 
> the extended translation classes of bent functions, and their duals. All of 
> these terms are defined in the paper, but briefly,
>
>- A* bent function* is a Boolean function on an even number of bits that 
>is as far as possible (in Hamming weight distance) from any affine Boolean 
>function; equivalently a Boolean function whose Walsh-Hadamard transform 
>has constant absolute value.
>- The dual of a bent function *f* is obtained from the Walsh-Hadamard 
>transform of *f*, and is also a bent function.
>- The *Cayley graph* of a Boolean function* f*, with *f(0)=0*, is a 
>graph whose vertices are all the bit vectors of a given dimension, with an 
>edge between vectors x and y if and only if *f(x+y)=1*. This Cayley 
>graph is *strongly regular* if *f* is bent.
>- The *extended translation class* of a bent function *f* on boolean 
>vector space* V* is the set of all functions of the form *g(x) = f(x+b) 
>+  + d*, where *b, c* are in *V* and d is 0 or 1.
>- The *Cayley graph classification* of the extended translation class of 
>a bent function* f* is the set of all isomorphism classes of Cayley 
>graphs of the functions *f(x+b) +  + f(b)*.
>
> The output of the code is displayed in the paper, and in the SageMathCloud 
> worksheets, and (with some exceptions) is also saved as objects of class 
> *BentFunctionCayleyGraphClassification* in both the public folder and the 
> GitHub repository.
>
>
> Questions:
>
>1. Is there a process to ask for a code review of this type of code 
>(i.e. code primarily written to support a paper)?
>2. Do you have any suggestions as to how and where I could publish a 
>fully peer reviewed version of such a long (52 page draft) paper with so 
>many examples, tables and figures?
>3. Is there a process to promote this code, or a part of this code to 
>Sage itself? 
>Note: if this requires a complete rewrite then this could take me some 
>time, as it is a one-person project conducted in my spare time as an 
>Honorary Fellow of the University of Melbourne.
>4. Is there any interest in my further developing this code to include a 
>database (e.g. SQL) of Cayley graph classifications?
>
> Thanks!
>
>
> Paul Leopardi  
>
>
> PS. I have presented this work in stages at the University of Queensland 
> ,
>  
> the University of Newcastle 
> ,
>  
> and RMIT University 
> ,
>  
> and will also present it at 2MCGTC in Malta next month 
> .

-- 
You received this message because you are subscribed to the Google Groups 

Re: [sage-devel] Extend crypto module

[Johan S . H . Rosenkilde]

Hi Friedrich

I totally agree with 1) and 2): that kind of implementations would be
very appropriate and valuable to have in Sage. Concerning 3), I would
initially think that doc-tests could be sufficient.

I was loosely involved in some discussions on implementing the McEliece
public-key crypto-system #21352
(https://trac.sagemath.org/ticket/21352) which has since stalled since
the author left it. From there I remember that we noticed some
crufty-ness to the code in sage/crypto. For instance, though there is a
base-class Cipher, it doesn't have abstract methods for encrypting and
decrypting; as a result, it seems that different words has been used for
this all over (at least "enciphering", "encode", "encrypt"). The
existing PublicKeyCipher in sage/crypto/cipher.py is also sort of weird:
e.g. it inherits key() from Cipher, but in the only current
implementation - Blum-Goldwasser class - there is instead public_key()
and private_key(). Perhaps some cleanup and redesign is appropriate
here.

I really don't know about 4). If researchers and teachers find that
they can use a modular, high-level implementation of certain protocols,
then why not? But as with the ciphers themselves, the aim shouldn't be a
competitive, highly optimised implementation, I think, but rather
something that eases understanding and experimentation.

Best,
Johan



Friedrich Wiemer writes:

> Today I stumbled across https://trac.sagemath.org/ticket/11565 in where the 
> design of the crypto module is briefly discussed ...
>
> 1) While RSA might be not the best cipher to point out the following, this 
> certainly holds for block ciphers or other crypto primitives. During my 
> research work I often implement some cipher scheme in python from scratch, 
> because I want to tinker with it, maybe exchange some parts of it, etc. 
> Having these things in sage with a highly modularized design would really 
> ease this kind of work.
>
> 2) Having all the heavy mathematic stuff in sage, we can easily provide 
> implementations of, say, AES that are in fact their mathematical 
> descriptions. I think Rusydi H. Makarim already started working on this. In 
> my opinion, this has at least two advantages: First it is a great 
> educational tool for students to see, how this math "works in real" and 
> helps them in getting a better understanding whats actually going on. 
> Second it would allow to have a collection of reference implementations, 
> which (because of the above modularized approach) allow to easily generate 
> also intermediate test vectors. For me, this last point is really a big 
> plus, because often you only get "coarse-grained" testvectors from cipher 
> specifications like input/output of the whole encryption (sometimes also 
> intermediate results after a single round or so) - but I have never seen a 
> specification, which also provides intermediate results after the inner 
> parts of a round function or so. If you want to implement some optimized 
> version, you might be very happy, to have such test possibilities at hand.
>
> 3) So, from the end of point 2: It would also be nice, to have a lot of 
> test vectors for crypto schemes - maybe its already enough to have these in 
> the doctests, at least this would be a nice starting point.
>
> 4) This last point is somewhat of an abstraction above point 2, combined 
> with 1. Going a level up, to the crypto-protocol level, it would be quite 
> easy to implement protocols like TLS when all the basic crypto stuff is 
> readily available. I was told that there is no free TLS implementation in 
> python available, where you are actually able to exchange parts of the 
> protocol (this again might be interesting if you are doing research on such 
> a protocol). Regarding this point, I'm not sure if sage is the right place 
> to have such a protocol level implementation, because its main aim seem to 
> be a mathematical CAS.
>
> What are your opinions regarding 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] Re: GSoC 2017 accepted SageMath

[Johan S . H . Rosenkilde]

Hi Harald,

Sorry I've been unresponsive for a while. I realise I'm not on the
mentors list to review projects - could you please add me?

Probably best to use this email address: santaph...@gmail.com

Best,
Johan Rosenkilde

Harald Schilly writes:

> Hi, a follow up for mentors: I thought mentors can ask to register,
> but no, please contact me to be invited (and if not clear, tell me
> which email address)
>
> There is also a little bit of activity here:
> https://groups.google.com/group/sage-gsoc/
>
> -- harald


-- 

-- 
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] Names of special methods like _pari_

[Johan S . H . Rosenkilde]

>
> (2) _pari(): meant for private methods. This doesn't seem correct to me, 
> because we want this method to be part of the public API.

But as Thierry says, perhaps not so public that we want it to figure in
tab-completion on all objects everywhere.

Isn't this exactly because most users would use this "convert to PARI"
method through other, more publicly visible services? In that case, it
could be seen as an implementation detail that objects have the _pari
method, and private would be apt.

I think I vote for this, though my only objection to (4) is that it
possibly goes against the Python doc.

Best,
Johan

-- 
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] GSoC 2017 accepted SageMath

[Johan S . H . Rosenkilde]

Harald Schilly writes:

> Just got word:
>
>> Congratulations! Sage Mathematical Software System has been selected as a 
>> Google Summer of Code 2017 mentor organization.

Awesome! I got a bit worried the last few days before deadline since our
GSoC page was somewhat sparse :-)

-- 
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] Experience from Sage Review Day 3: An online hacking event

[Johan S . H . Rosenkilde]

Hi sage-devel

Yesterday we held Sage Review Day 3, and it was a big success. I just
wanted to briefly share my experience with this.

Overall, 8 developers participated, most of them all day. We
communicated using Slack, Framapad and Trac. We got 14 tickets
positively reviewed, and had good progress on 3 more tickets.

Planning:
Minimal. We started as 5 developers who wished to give an extra push on
coding theory. We set a date, created a Sage wiki page, and announced on
sage-devel, as well as sending emails to participants of SD75. Just
before the event, we made sure the coding theory dev page on Trac,
https://trac.sagemath.org/wiki/SageCodingRoadMap, was updated; we
created a Slack team page; and a framapad with skeleton information.


During the day:
Communication was four-fold:

1) The coding theory dev page on trac served as a static list of tickets
needing work - everyone looked at that list for tasks.

2) Slack served as live chat and gave a nice atmosphere of working
together. Devs announced work, needs reviews, positive reviews, asked
for assistance, and made jokes. It was a huge motivator.

3) Framapad was a live reference list of what people were working on and
what had already been done.

4) Trac tickets were as always where "official" discussions were taking
place (posts/push followed by a poke on Slack usually).


Aftermath:
For me, this was a great way to set aside a well-defined amount of time
for Sage development. It was also much more efficient than usual
scattered efforts, since context switching takes a lot of time.
Interaction btw. developer and reviewer was immediate, and getting
response on a ticket 5 mins after posting the code is immensely
satisfying.

I feel that this is a fruitful, informal way to coordinate work on Sage.
There really was a mini-Sage Days feeling over it! One reason for the
big feeling of success was that coding theory had so many outstanding
tickets waiting review. Actual designing and serious implementation
would lead to much fewer tickets being finished, and perhaps less
dynamic interaction on the live chat. Perhaps this type of event is
therefore best for a "Review/Bug Day", or at least very focused type of
development.

I'm hoping that the other participants will chime in, or anyone else
with experience of similar events to share.

Best,
Johan

-- 
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: GSoC 2017 kickoff

[Johan S . H . Rosenkilde]

Hi Harald,

Thanks for yelling out. I've added the polynomial class project that
I mentioned on the list earlier. But 1 project is surely not enough...

Best,
Johan

Harald Schilly writes:

> Hello, in 3 days is the deadline regarding the project application.
> I'm working on the application itself, but a list of suggested
> projects is *vital* to getting approval. I saw a few ideas here, but
> so far not a single proposal was added to
>
> https://wiki.sagemath.org/GSoC/2017
>
> Please compare it with the 2016 page, i.e. at minimum there should be
>
> * title
> * mentor(s) (with contact info)
> * technical and theoretical scope
> * short description
>
> -- harald


-- 

-- 
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: Organisation of online : survey of developers

[Johan S . H . Rosenkilde]

> Exactly. I wouldn't like to have documentation that is *not* included in the
> SageMath sources. Currently, one can access all documentation locally, during 
> a
> SageMath session.

+1

Most of the Feature Tour pages http://www.sagemath.org/tour.html are not
in the source tree. They are also somewhat out of date, especially
Benchmarks (comparing SageMath 4.1.1 with Mathematica 7).

That page links to "A Guided tour of Sage" in the compiled doc
(http://doc.sagemath.org/html/en/tutorial/tour.html), which is something
different than "A tour of Sage"
(http://doc.sagemath.org/html/en/a_tour_of_sage/index.html). Three
different places to have a "tour" -- horrendous!

Under the Documentation main page doc.sagemath.org, the "guided tour" is
called "tutorial". And it is listed after "Thematic Tutorial" though it
should surely be visited first by a newcomer.

> On the "help/documentation" page, I'd prefer a list of the available documents
> and for each item on the list a drop-down menue for choosing one's language. 
> And
> please not a bunch of links named "Ref: Probability  Ref: Quadratic Forms etc"
> on that page. Instead, there could be a link "Chapters" that leads to a table 
> of
> contents.

+1

In general, we have so many lists of documents that you can read that
it's total information overload, and the user is confused on even where
to start. Compare e.g.

http://www.sagemath.org/help.html
http://www.sagemath.org/tour.html
http://www.sagemath.org/library.html
http://doc.sagemath.org/
http://doc.sagemath.org/html/en/

I know they're all different and serve different purposes etc., but it's
not very helpful for a new user. If the documentation is structured in a
simple, immediately logical fashion, it's easier for users to know where
to seek further help. 

And we should make absolutely guaranteed sure that every user gets to
know about tab-completion and ?-help. These two tricks make Sage so much
easier and more fun to learn!


> So, perhaps/probably it is possible to improve sagemath.org. E.g., I find the
> front page ok.

Compared with modern open source project web pages, I find it noisy and
somewhat unprofessional. There's 7-9 menus of links, depending on how
you count, with even more links scattered outside this. For instance,
the ugly "Do you want to learn how to use SageMath"-box currently
adorning the page has no place there.

It's also boring and uninspiring.

We should get a beautiful, colourful design with banner images of some
cool plots and some rendered latex equations, and with some 1-2 sentence
taglines. And then the main buttons "Try Online", "Download",
"Documentation", and "Development". At the top, a single menu with items
like our main menu now. Just thinking out loud...

Best,
Johan





Simon King writes:

> Hi!
>
> On 2017-02-06, Clemens Heuberger  wrote:
>> Am 2017-02-05 um 03:22 schrieb kcrisman:
>>> 
>>> "Tutorial", "Thematic Tutorial", "PREP Tutorial", "A Tour of Sage". and
>>> "Constructions" are mostly the same Tutorial. 
>>> 
>>> 
>>> Just for clarification, these are massively and completely different 
>>> documents.
>>>  There is also a lot of overlap, but the audiences are very different.  The
>>> challenge is getting the right people to the right tutorial/introduction, or
>>> perhaps writing new ones and making them easy to find. ...
>> one more point: as part of the sage source tree, these tutorials are tested
>> regularly and so it is guaranteed that they work with the most recent sage 
>> version.
>
> Exactly. I wouldn't like to have documentation that is *not* included in the
> SageMath sources. Currently, one can access all documentation locally, during 
> a
> SageMath session.
>
> Usually I find it very very easy to search for relevant documentation in
> SageMath - say, by search_def or search_src or by ? or ?? or tab completion.
> Actually I believe that the documentation is a strength of SageMath.
>
> However, the paragraph above indicates a problem: Before being able to enjoy 
> the
> good SageMath documentation, one needs to learn how to access stuff. For
> newbies, it might be problematic to some extent. But this problem cannot be
> solved by removing the above tools. Instead, newbies should be pointed to 
> using
> them.
>
> So, perhaps/probably it is possible to improve sagemath.org. E.g., I find the
> front page ok, but I find both the download page and the page
> "help/documentation" confusing: Both consist of very long lists of links
> (e.g., to download servers or to separate chapters of the PDF documentation or
> different languages).
>
> On the "help/documentation" page, I'd prefer a list of the available documents
> and for each item on the list a drop-down menue for choosing one's language. 
> And
> please not a bunch of links named "Ref: Probability  Ref: Quadratic Forms etc"
> on that page. Instead, there could be a link "Chapters" that leads to a table 
> of
> contents.
>
> Best regards,
> Simon


-- 

-- 
You 

[sage-devel] Re: Review Days 3: Coding Theory, an Online Event near you

[Johan S . H . Rosenkilde]

Hi everyone,

This is to remind you of the online Sage Review Days 3 on Tuesday. It
will be a nice occasion for putting in a concentrated effort on closing
tickets.

We will probably communicate using Slack and Framapad. Keep an eye on
https://wiki.sagemath.org/review3 for details.

Best,
Johan



Johan S. H. Rosenkilde writes:

> Hi Everyone,
>
> This is to announce that we are organizing Review Days 3 on Coding
> Theory. This is a one-day *online* event which will take place:
>
>February 7, 2017
>From 9-17 GMT+1, or until everyone runs out of steam
>
> See the Review Days web page: https://wiki.sagemath.org/review3.
>
> We will probably communicate using Gitter and Framapad, but details will
> follow.
>
> The motivation is the many very nice tickets on coding theory
> functionality currently needing review or a final polish, see:
>   https://trac.sagemath.org/wiki/SageCodingRoadMap
>
> That being said, everyone who is interested in an excuse for a full
> day's hacking on Sage is very welcome to join.
>
> We unfortunately do not have funding for covering consumption of cake,
> beer and pizza, but we will set up a dedicated page where participants
> can upload pictures of their workplace and its amenities, to further the
> virtual hacking ambience of the event.
>
> Best,
> Johan Rosenkilde
> on behalf of the organisers, the remaining being
> David Lucas, Julien Lavauzelle, Clément Pernet, Daniel Augot
> (because you need 5 organisers to put together an online day of hacking)


-- 

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

[Johan S . H . Rosenkilde]

Kwankyu Lee writes:
>
> I understand this as practically saying that we should avoid breaking 
> existing doctests as much as possible and try to be consistent in new 
> doctests as much as possible. 
>
> And how the new doctests would be written is determined when we actually 
> write the code. So how about opening one meta ticket and lots of individual 
> tickets for the cmp cases to tackle, and defer discussions to each ticket?
>
> Though I think, like Jeroen, setting forth some guiding principles outright 
> would be useful to start. I guess a dictator who knows very well the 
> coercion framework may do this...

To enable people knowing less about the whole cmp thing to help out, it
might make sense to maintain a wiki page about the core issues to be
aware of when porting, the main mechanisms, and perhaps links to tickets
exemplifying some typical cases.

Best,
Johan

-- 
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: Suggestion for GSoC project: Polynomials - Rewriting and relinking

[Johan S . H . Rosenkilde]

Jean-Pierre Flori writes:
>>
>> I would be very interested in working on this.

Cool :-) Let's discuss the project description off the mailing list.


Also, thanks Peter for your input. We should definitely take a closer
look at #15601.

Best,
Johan

-- 
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] Suggestion for GSoC project: Polynomials - Rewriting and relinking

[Johan S . H . Rosenkilde]

Hi sage-devel,

Our current polynomial implementation has severe issues:

- Our speed for GF(2^e)[x] is abysmal.

- For other cases we are probably not linking to the currently fastest
  libraries.

- We don't have multi-point evaluation or fast Lagrange interpolation,
  even though the libraries we link to often have this.

- Bruno Grenet remarked at SD75 that there were issues and lots of
  crufted code in the class structure handling generic/specific and
  dense/sparse/etc. polynomials.

- Jeroen Demeyer remarked that the Cython code is from the prehistoric
  era and has lots of cruft from back when Cython was a lot more
  primitive than it is now.

- add more things yourself.

Considering how central polynomial arithmetic is in many parts of
algebra, I think this is bad, and it impedes gradual improvement (e.g. I
am at a loss on how to improve the GF(2^e)[x] thing which is my personal
main itch).

I would be interested in co-mentoring such a GSoC project for improving
this. But I lack understanding of, especially Cython and linking. I
would like to know if someone else would be a co-mentor with me on this,
or technical advisor on e.g. Cython issues.

Best,
Johan



Harald Schilly writes:

> Hello, this year's Google Summer of Code 2017 just started.
>
> I assume we will try again to be part of it, and therefore I've
> started the registration process.
>
> The most important aspect is to have mentors and project proposals.
> For that, I've started this year's wiki page as a copy of last year:
>
> https://wiki.sagemath.org/GSoC/2017 (compare with 2016)
>
> The deadline for the application is Feb. 9th and I'm again working on
> this like in the past 5 years.
>
> -- Harald


-- 

-- 
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] Release note auto-generation RFC

[Johan S . H . Rosenkilde]

Volker Braun writes:

> There is a somewhat painless approach to generating human-readable release 
> notes using https://github.com/hawkowl/towncrier. As far as the ticket 
> author is concerned, if you think that your ticket #12435 is of wider 
> interest and should be announced then all you'd have to do is add a file
>
> echo "Added the last twin prime" > newsfragments/12435.feature
>
> Note that the fragment filename starts with the ticket number, so it won't 
> conflict with other news fragments. Then, when making a new release, I 
> concatenate the fragments into NEWS.rst as, for example, 
> in https://github.com/hawkowl/towncrier/blob/master/NEWS.rst

I support the idea of providing users (and developers) with a NEWS file.
My first reaction to your suggestion with towncrier is to ask why it is
necessary to manually add news for a subset of tickets, instead of
auto-generating a NEWS file from all closed tickets.

Many tickets will be bug fixes or technical stuff, not very pleasant or
relevant to a user. But what if the "types" we have on tickets were more
meaningful, perhaps these could serve to divide such a NEWS file into
headings, e.g.

== New Features ==

24454: Added the last twin prime


== Enhancements ==

28042: A faster implementation of Q[x] factorisation
...

== Bug-fixes ==

25233: Fixed a crash when plotting.
...


Best,
Johan

-- 
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] Review Days 3: Coding Theory, an Online Event near you

[Johan S . H . Rosenkilde]

Hi Everyone,

This is to announce that we are organizing Review Days 3 on Coding
Theory. This is a one-day *online* event which will take place:

   February 7, 2017
   From 9-17 GMT+1, or until everyone runs out of steam

See the Review Days web page: https://wiki.sagemath.org/review3.

We will probably communicate using Gitter and Framapad, but details will
follow.

The motivation is the many very nice tickets on coding theory
functionality currently needing review or a final polish, see:
  https://trac.sagemath.org/wiki/SageCodingRoadMap

That being said, everyone who is interested in an excuse for a full
day's hacking on Sage is very welcome to join.

We unfortunately do not have funding for covering consumption of cake,
beer and pizza, but we will set up a dedicated page where participants
can upload pictures of their workplace and its amenities, to further the
virtual hacking ambience of the event.

Best,
Johan Rosenkilde
on behalf of the organisers, the remaining being
David Lucas, Julien Lavauzelle, Clément Pernet, Daniel Augot
(because you need 5 organisers to put together an online day of hacking)

-- 
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] immutability of vectors in submodules

[Johan S . H . Rosenkilde]

I reported this bug 1,5 years ago:

https://groups.google.com/forum/#!topic/sage-devel/rvs5E6AEXVc

Not to point fingers, but you said: "The behavior is bad but I would not
call it a bug. You modified wrongly the vector." ;-)

Back then you proposed to change the semantics such that a vectors'
parent is always the ambient space, i.e. V in your example. I would
still say this is the best solution. Though David Roe disagreed on the
follow-up post:

https://groups.google.com/forum/#!topic/sage-devel/o9DNHs5zLLw

On the first post, Volker suggested your solution 2.

Best,
Johan



Vincent Delecroix writes:

> Dear all,
>
> I went into the following bug: it is possible to modify an entry of 
> vector whose parent is a submodule of R^n.
>
> sage: V = VectorSpace(QQ, 3)
> sage: M = V.subspace([(1,0,0,),(0,1,0)])
> sage: v = M()
> sage: v
> (0, 0, 0)
> sage: v[2] = 2 # bug
> sage: v
> (0, 0, 2)
> sage: v.parent() is M
> True
>
> I opened https://trac.sagemath.org/ticket/22075 but I am not sure about 
> the solution. I see at least 2
>
>   1) forbid __setitem__
>   2) check when a modification is done that the vector still belongs to 
> the given submodule (possibly together with a __enter__/__exit__ hook)
>
> 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.

Re: [sage-devel] Sage for Windows installer (take 2)

[Johan S . H . Rosenkilde]

> TL;DR: if you have a 64-bit Windows (Windows 7 and up should work)
> please demo and give me your thoughts on the new build of Sage for
> Windows using the installer at [1].

Great work, Erik!

Best,
Johan

-- 
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: Hermite normal form of matrix over polynomial ring

[Johan S . H . Rosenkilde]

> Not me -- but I did review it in 2010! -- see
> https://trac.sagemath.org/ticket/9069

Ah, I misunderstood what you had written previously :-)

-- 
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: Hermite normal form of matrix over polynomial ring

[Johan S . H . Rosenkilde]

John Cremona writes:
> That was the algorithm I implemented in Magma.  It was not very hard.

Indeed. My student made an effort of comparing C++, Cython and pure Sage
implementations, in combination with various tweaks to the algorithm.
In the end the Cython version was at best 2x faster than  my pure Sage
implementation. Which is probably not surprising to Cython veterans, but
it was to me :-)

> > I have semi-unpolished code in my public repo [2] which uses that
> > implementation for shifted Popov form, order basis, etc., allowing the
> > whole host of normal forms and K[x] equation solvers. They work and are
> > tremendously useful, and they are reasonably fast for small-medium
> > matrices. If there is interest and I can get reviewers, I can become
> > motivated to polishing them off for Sage proper.
> 
> I think there is interest.

Good to hear.

> I once used the weak Popov form in a talk with Hendrik Lenstra in the
> audience and he was quite amused since it appeared to be (and I think
> he is right) much the same as his brother Arjen had written about in
> his (earlier!) thesis.

The algorithm in [1] by Arjen Lenstra is somewhat similar to what
Mulders and Storjohann's algorithm, but it is asymptotically slower.
The one you implemented in Sage is closer to Lenstra's algorithm (and
has its complexity) than it is to the one of M-S.

Mulders and Storjohann's algorith even predates the Lenstras: it was
(very loosely) outlined in 1980 in Kailath's legendary book. Arne
Storjohann himself seems slightly embarrassed that it now carries his
name; his article was just the first to really write it properly and
analyse it, and the article's intended contents were lots of stuff it
was used for.

Best,
Johan



[1] Lenstra, A.K. 1985. “Factoring Multivariate Polynomials over Finite
Fields.” Journal of Computer and System Sciences 30 (2): 235–248.

-- 
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: Hermite normal form of matrix over polynomial ring

[Johan S . H . Rosenkilde]

> I'm sure that Sage already has code for Weak Popov Form.  I
> implemented it myself in about 2004 but from the date you can tell
> that it was not in Sage (but Magma).
>
> Indeed, search_src("popov") finds
>
> matrix/matrix_misc.py:32:def weak_popov_form(M,ascend=True):

That function doesn't compute the weak Popov form, but rather a row
reduced form (they are closely related though), see
https://trac.sagemath.org/ticket/16888.

The algorithm is also quite slow. Together with a student we implemented
Mulders and Storjohann's straightforward algorithm [1], see

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

This implementation is much faster than what is currently in Sage.
Unfortunately, the code never got polished and the student moved on to
other things, so the code is rotting now.

I have semi-unpolished code in my public repo [2] which uses that
implementation for shifted Popov form, order basis, etc., allowing the
whole host of normal forms and K[x] equation solvers. They work and are
tremendously useful, and they are reasonably fast for small-medium
matrices. If there is interest and I can get reviewers, I can become
motivated to polishing them off for Sage proper.

Unfortunately, I tried the implementation on Hermite Normal Form, and it
seems worse than the current hermite_normal_form algorithm.

In my previous mail I mention the minimal approximant basis algorithm by
Giorgi, Jeannerod and Villard. This can be used for asymptotically much
faster row reduction computation for large matrices.

[1] Mulders, T., and A. Storjohann. 2003. “On Lattice Reduction for
Polynomial Matrices.” Journal of Symbolic Computation 35 (4): 377–401.

[2] https://bitbucket.org/jsrn/codinglib

-- 
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: Hermite normal form of matrix over polynomial ring

[Johan S . H . Rosenkilde]

There's been quite a bit of work on Hermite normal form of K[x]-matrices
recently, most notably by Vincent Neiger:

http://dl.acm.org/citation.cfm?id=2930889.2930936

This algorithm gives a much faster way of computing the Hermite Normal
form of K[x] matrices. Unfortunately it relies on quite stack of
sophisticated K[x] techniques such as minimal approximant basis and
high-order lifting for system solving and some of the algorithms of
Neiger and his coauthors:

http://dl.acm.org/citation.cfm?id=2930889.2930928

An algorithm for Hermite Normal form which is fast for "random" input
matrices is much easier to make. In this case, a lot of the complexity
of the above approach trivialises. Vincent Neiger has told me that
generally a sensible implementation of his algorithms should have a fair
amount of these "if stuff is simple, just do this"-clauses to avoid
extra work. Perhaps that's yet another reason it is tricky to get.

I know that some work has been initiated in LinBox, notably computing
minimal approximant bases (also known as sigma basis or order basis)
using the algorithm PMBasis from:

Giorgi, P., C.P. Jeannerod, and G. Villard. 2003. “On the Complexity of
Polynomial Matrix Computations.” In International Symposium on Symbolic
and Algebraic Computation, 135–142.

Just having that algorithm in Sage would be a great addition: it is a
powerful hammer that can be applied to many problems, e.g. computing
reduced and normal forms as well as determinant etc. etc.

My understanding is that these implementations are still experimental
and somewhat undocumented in LinBox but Pascal Giorgi in particular is
working on it. Once that stabilises, we should get it into Sage asap.

Vincent Neiger will soon join my group for two years as a postdoc, and I
know he is interested in implementing some of these things. I hope we
can do some things here and improve Sage's capabilities in this respect.

Best,
Johan







'Bill Hart' via sage-devel writes:

> A colleague suggested to look at the Popov form. I didn't look at what Sage 
> is currently doing, so my apologies if this turns out to not be a useful 
> comment.
>
> Here is a random paper on this that I found [1].
>
> Bill.
>
> [1] http://perso.ens-lyon.fr/gilles.villard/BIBLIOGRAPHIE/PDF/issac96.pdf
>
> On Tuesday, 15 November 2016 10:01:09 UTC+1, Kwankyu Lee wrote:
>>
>> Hi,
>>
>> The current Hermite normal form algorithm in Sage for matrices over k[x] 
>> seems embarrassingly slow. It is a generic algorithm for matrices over 
>> PIDs. What would be possible ways to improve the situation? Any reference 
>> to literature or implementations or like would be welcome. Thanks.
>>
>>


-- 

-- 
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] RFC: correct way to deal with particular methods

[Johan S . H . Rosenkilde]

> Johan's suggestion is very intriguing but, unless I am completely mistaken, 
> it does not work in python. If I understand correctly if O is an instance of 
> Foo and O does not have the attribute x then python looks for Foo().x

You're right, I seem to have confused myself with deleting attributes of
subclasses.

Another possibility is to create micro-classes for each method which
only certain matrices have, and then dynamically monkey-patch each
constructed matrix to inherit from the micro-classes it should.
Unfortunately this requires assigning to o.__class__, which
doesn't seem possible when o is an instance of a Cython class.

Otherwise, the code below could work, I believe. The `extend_instance` is taken 
from
http://stackoverflow.com/questions/8544983/dynamically-mixin-a-base-class-to-an-instance-in-python.

def extend_instance(obj, cls):
"""Apply mixins to a class instance after creation"""
base_cls = obj.__class__
base_cls_name = obj.__class__.__name__
obj.__class__ = type(base_cls_name, (base_cls, cls),{})

class IntegerMatrixTwoColumn(SageObject):
def magic_method(self):
return 42

def MyMatrix(*args):
M = matrix(*args)
if M.ncols() == 2 and M.base_ring() == ZZ:
extend_instance(M, IntegerMatrixTwoColumn)


sage: M = MyMatrix(ZZ, 2, 2, [1,2,3,4])
sage: M.magic_method()
42

Best,
Johan

-- 
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] RFC: correct way to deal with particular methods

[Johan S . H . Rosenkilde]

VulK writes:
> The first question is about which is the correct way to implement methods 
> that are not always defined.

I agree with Nils that subclassing is the most OOP-clean way of
achieving this. That being said, one might argue that it is a pretty
heavy-handed solution which potentially leads to class-explosion and
mega-multiple-inheritance.

Another possibility is to do the converse of what you are doing: add the
method on the class but *delete* at construction time if it is not
appropriate. This can be done using delattr.

VulK writes:
> The second problem is a little more involved, I will try to give you a souped 
> up version here.
> ...

Did you take a look at performing the preparsing using a decorator which
properly uses @sage_wraps? It is possible to do the documentation
modification at decoration-time, and then it should properly show up in
Sphinx as well.

Best,
Johan

-- 
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: Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

> Travis wrote:
> Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) 
> as you don't need the set of all subsets to be a parent.

I see now that those functions don't support an argument for which size
subsets you need (which is critical in my application).

Best,
Johan

-- 
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: Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

Hi everyone,

OK, we can bicker about the semantic difference of the words "bug" vs
"intentional but bad design" all day, but in the end we agree it's not
great for the user. It seems the ever-vigilant Vincent discovered the
problem already a year ago and proposed a sensible fix for the problem
in #19562.

Thanks for the tip with subsets() and powersets(). Unfortunately, John's
workaround is brittle since it only supports subsets of the full GF(13).
My actual code was closer to:

ls = carefully_selected_sublist_of(GF(13).list())
for S in Subsets(ls, 5): 
if sum(S) == 1: 
   print "Monkey" 

> Travis wrote:
> Sage can't tell apart, e.g., 1 in ZZ (or the int) from 1 in GF(13) due
> to coercion when doing equality (and they have the same hash).

*Should* they have the same hash? I'm aware I'm setting my toe down in
the murky waters of coercion, equality and mathematical equivalence, but
isn't it surprising and dangerous even in Sage library code that sets,
cached_method, FiniteEnumeratedSets (before #19562), and everything else
that depends on hashing to tell objects apart, will not tell 1 in GF(2)
apart from 1 in ZZ from 1 in MatrixSpace(RR, 3, 3)? Oh no wait:

sage: hash(MatrixSpace(RR, 3, 3).one()) == hash(12)
True

That seems like an accident waiting to happen. Couldn't we just xor the
hash of the parent with the object or something (possibly specially
adjusting for parent.zero())?


Best,
Johan






Travis Scrimshaw writes:

> On Wednesday, November 2, 2016 at 7:59:42 PM UTC-5, Luca De Feo wrote:
>>
>> > It is not a bug, but a by product of wanted (with documentation) of the 
>> > UniqueRepresentation and the coercion system in Sage. More below. 
>>
>> This is a bug. 
>>
>> The fact that it is a consequence of wanted and documented behaviour 
>> just shows that the wanted behaviour was badly designed (regardless of 
>> how great and useful it is). 
>>
>> I'm getting dangerously close to the realm of bikeshedding, but bad design 
> or (very) subtle behavior is not a bug. A bug is incorrect or unintended 
> results.
>
> That being said, I'm not opposed to removing the UniqueRepresentation, but 
> I'd like to hear why this was originally put in place. In many ways, what 
> you're doing involves additional subtleties due to the coercion framework 
> being involved behind the scenes (i.e., as far as equality is concerned, 1 
> in ZZ == 1 in GF(13)).
>
> Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L)) 
> as you don't need the set of all subsets to be a parent.
>
> 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] Re: Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

Hi Travis,

>From my point of view, this can only be considered a bug: extremely
surprising behaviour leading to subtle problems in user code (my code).
Possibly, the bug is higher up than FiniteEnumeratedSets, though.

I'll explain: This came about when using Subsets. Basically, I'm doing
something like:

for S in Subsets(GF(13).list(), 5):
if sum(S) == 1:
   print "Monkey"

This code works as expected and prints monkeys galore when evaluating it
in a Sage shell. Now restart Sage and call the following line before
calling the above snippet:

a = list(Subsets(range(13), 5))

And suddenly the first code snippet will never print anything.

Tell me that's not a bug!

Best,
Johan
 
Travis Scrimshaw writes:

> Hey Johan,
>The problem is that we want finite enumerated sets to be hashable, 
> picklable, and unique as they get used as keys for CombinatorialFreeModule, 
> among other things, and it is implemented using UniqueRepresentation. The 
> problem is that 1 = 1 with the same hash value whether in ZZ or GF(97), so 
> the enumerated set is the same. However, I would not regard this as a bug, 
> but a "feature" of the unique behavior and the coercion framework.
>
>My guess is that you are treating the finite enumerated set as a tuple, 
> and so I would suggest that you just used tuples (which has far less 
> overhead).
>
> Best,
> Travis
>
>
> On Wednesday, November 2, 2016 at 12:45:21 PM UTC-5, Johan S. H. Rosenkilde 
> wrote:
>>
>> Hi all, 
>>
>> I just tracked down a nasty bug completely messing up my experiments to 
>> this internal caching mechanism. In a clean Sage type: 
>>
>> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]) 
>> sage: type(E[0]) 
>>  
>>
>> Restart Sage and type instead 
>>
>> sage: E = FiniteEnumeratedSet([1,2,3,4,5,6]) 
>> sage: type(E[0]) 
>>  
>> sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); 
>> type(E[0]) 
>>  
>>
>> Many variations of this theme seem possible. 
>>
>> This was Sage 7.5.beta0. 
>>
>> Someone knowledgeable can help find the cause and possible other places 
>> the bug could appear? 
>>
>> Best, 
>> Johan 
>>


-- 

-- 
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] Bug in caching mechanism of FiniteEnumeratedSet

[Johan S . H . Rosenkilde]

Hi all,

I just tracked down a nasty bug completely messing up my experiments to
this internal caching mechanism. In a clean Sage type:

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]])
sage: type(E[0])


Restart Sage and type instead

sage: E = FiniteEnumeratedSet([1,2,3,4,5,6])
sage: type(E[0])

sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]]); type(E[0])


Many variations of this theme seem possible.

This was Sage 7.5.beta0.

Someone knowledgeable can help find the cause and possible other places
the bug could appear?

Best,
Johan

-- 
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] sphinx, texinfo and emacs

[Johan S . H . Rosenkilde]

> Yes, but there are no links.  Or do you have them?

True, they are not links. It would be nice if they were, though
personally I like that what is printed is the actual module name that I
should type in followed by ? to see its doc. That's probably how I would
do it even if it was a link, and IMHO beats replacing the module name by
only a description text which is a link.

> (I admit, I made a mistake: the text is the same, contrary what I wrote. 
>  Although I'm not sure that showing just the docstring of the class is best 
> possible: I recently used automethod, and this documentation is not 
> shown...)

What do you mean? If you type e.g

sage: codes?

you'll get the doc for sage.coding.codes_catalog.py. The table there is
auto-generated.

Best,
Johan

'Martin R' via sage-devel writes:

> Yes, but there are no links.  Or do you have them?
>
> (I admit, I made a mistake: the text is the same, contrary what I wrote. 
>  Although I'm not sure that showing just the docstring of the class is best 
> possible: I recently used automethod, and this documentation is not 
> shown...)
>
> Martin
>
> Am Donnerstag, 20. Oktober 2016 11:55:16 UTC+2 schrieb Johan S. R. Nielsen:
>>
>> I don't understand -- aren't you getting the full documentation, as in 
>> this page: 
>>
>>
>> http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/posets/__init__.html#sage-combinat-posets
>>  
>>
>> At least, on my machine it prints the exact same information. 
>>
>> Best, 
>> Johan 
>>
>> 'Martin R' via sage-devel writes: 
>>
>> > As you may know, using https://github.com/sagemath/sage-shell-mode, 
>> working 
>> > with sage in emacs is a very enjoyable pastime. 
>> > In particular, typing at the sage prompt 
>> > 
>> > sage: sage.combinat.posets? 
>> > 
>> > opens a new frame and displays the documentation of sage.combinat.posets 
>> > there.  However, to my dismay, some of the documentation does not appear 
>> > there.  I reproduced the output for you at the end of this post.  As 
>> > stakemori told me, this is exactly what you get when using sage in the 
>> > console. 
>> > 
>> > On sphinx' homepage I see that sphinx can produce texinfo, which should 
>> be 
>> > the native document format for emacs. 
>> > 
>> > I have three questions: 
>> > 
>> > 1) what is currently used to produce the text printed when typing 
>> "object?" 
>> > 2) where would I have to add texinfo as documentation output format? 
>> > 3) (that's a question for stakemori) could you use texinfo docum emacs? 
>> > 
>> > 
>> > Martin 
>> > 
>> > Type:module 
>> > String form: > > 
>> '/home/martin/sage-patchbot/local/lib/python2.7/site-packages/sage/combinat/posets/__init__.pyc'>
>>  
>>
>> > File:   
>> > 
>>  
>> ~/sage-patchbot/local/lib/python2.7/site-packages/sage/combinat/posets/__init__.py
>>  
>>
>> > Docstring:   
>> > Posets 
>> > 
>> > Common posets can be accessed through "posets." and are listed in 
>> > the posets catalog: 
>> > 
>> > * *Catalog of posets* 
>> > 
>> > Poset-related classes: 
>> > 
>> > * *sage.combinat.posets.posets* 
>>
>>
>> -- 
>>


-- 

-- 
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] sphinx, texinfo and emacs

[Johan S . H . Rosenkilde]

I don't understand -- aren't you getting the full documentation, as in this 
page:

http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/posets/__init__.html#sage-combinat-posets

At least, on my machine it prints the exact same information.

Best,
Johan

'Martin R' via sage-devel writes:

> As you may know, using https://github.com/sagemath/sage-shell-mode, working 
> with sage in emacs is a very enjoyable pastime.
> In particular, typing at the sage prompt
>
> sage: sage.combinat.posets?
>
> opens a new frame and displays the documentation of sage.combinat.posets 
> there.  However, to my dismay, some of the documentation does not appear 
> there.  I reproduced the output for you at the end of this post.  As 
> stakemori told me, this is exactly what you get when using sage in the 
> console.
>
> On sphinx' homepage I see that sphinx can produce texinfo, which should be 
> the native document format for emacs.
>
> I have three questions:
>
> 1) what is currently used to produce the text printed when typing "object?"
> 2) where would I have to add texinfo as documentation output format?
> 3) (that's a question for stakemori) could you use texinfo docum emacs?
>
>
> Martin
>
> Type:module
> String form:  '/home/martin/sage-patchbot/local/lib/python2.7/site-packages/sage/combinat/posets/__init__.pyc'>
> File:   
>  
> ~/sage-patchbot/local/lib/python2.7/site-packages/sage/combinat/posets/__init__.py
> Docstring:  
> Posets
>
> Common posets can be accessed through "posets." and are listed in
> the posets catalog:
>
> * *Catalog of posets*
>
> Poset-related classes:
>
> * *sage.combinat.posets.posets*


-- 

-- 
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] Bug: Affecting a value to an integer

[Johan S . H . Rosenkilde]

> 0 = 42
> print 0

Hahaha, easiest way to get a contradiction and thereby prove any statement
in Sage :-D

-- 
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: cython memory leak when one's forget to cdef the for loop variable

[Johan S . H . Rosenkilde]

>> sage: a = range(10**8)  # takes a lot of memory 
>> sage: del a# free the memory 
>
> Ok, so now, I understand why it takes the memory: a list was created.

Using xrange instead of range will also avoid creating the list even
without cdef'ing a (the code is still slow of course).

But then the code will not immediately work in Python 3, I guess.

Best,
Johan

-- 
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: doc.sagemath.org gone from google

[Johan S . H . Rosenkilde]

> In case no one else has noticed, doc.sagemath.org is now showing up in 
> Google searches, including the link that initiated this thread.

Indeed I have noticed! It's really good news for us and - especially -
for new Sage users :-)

Best,
Johan

Paul Masson writes:

> In case no one else has noticed, doc.sagemath.org is now showing up in 
> Google searches, including the link that initiated this thread.
>
> Google taketh away, and Google giveth back.
>
>
> On Sunday, August 7, 2016 at 8:25:56 AM UTC-7, William wrote:
>>
>> I'm googling for links to the sage reference manual, e.g., 
>>
>>
>> https://www.google.com/search?q=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=1C5CHFA_enUS691US691=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=chrome..69i57j69i64.1153j0j7=chrome=UTF-8
>>  
>>
>> and they now **all** go to combinat.sagemath.org.I had expected to 
>> find links such as 
>>
>>   
>> http://doc.sagemath.org/html/en/reference/polynomial_rings/sage/rings/polynomial/polynomial_quotient_ring_element.html
>>  
>>
>> but nope. 
>>
>> -- 
>> William (http://wstein.org) 
>>


-- 

-- 
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] Giving Sage AI-based step-by-step equation solving abilities

[Johan S . H . Rosenkilde]

Ted Kosan writes:
> Unfortunately, what most mathematics teachers are teaching is not
> mathematics. This observation is described well by Scott Gray ...

Indeed, I'm sure there's many examples of such teaching going on, and it
is important to try to improve this.

> High school mathematics teachers are not qualified to decide how
> mathematics should be taught because they don't know enough about how
> mathematics actually works to be entrusted with this decision.

Possibly true for some math teachers. However, I'm generally in favour
of putting more trust in the teachers and let them decide how to teach.
More control, canon and centrally-chosen systems for teaching, more
tests and more admin for teachers take time and passion away from what
they should be doing.

> In the future, K-12 mathematics teachers will be replaced by AI
> mathematics tutors.

That's a bold claim.

> As Scott Gray's blog post indicates, the kind of mathematical
> intuition that most students are being taught to build up is the wrong
> kind of intuition.

The kind of mathematical intuition that Scott Gray taught was wrong. As
Dima pointed out, teaching for the test is wrong.

> The right kind of mathematical intuition consists of the techniques
> that PRESS uses.

Wow, another incredibly bold claim. And it hardly follows from Scott
Gray's experience.

> These techniques are very syntax-oriented, but they
> are so simple and straightforward that even young children should be
> able to learn them without too much difficulty.

I'll strongly contest that. The ability to crank a handle on a musical
box doesn't make you a musician.

Almost no mathematicians think in axioms and syntax. I doubt that good
mathematical insight can be grown this way -- just see the pedagogical
failure of Bourbaki and New Math in the 60s.

> Before I started testing my solver with students, I was also concerned
> that the rules it used might be too detailed for them. However, what I
> discovered is that many students found the high level of detail to be
> illuminating because for the first time in their lives they were
> seeing how mathematics actually worked with nothing being hidden from
> them.

OK. Following Scott Gray, did you test your students on their
understanding? The students' own feedback is close to worthless here, as
Scott Gray pointed out.

> Having said that, the set of rules that are shown in the demo video
> are just the set I decided to experiment with first. The software can
> be easily configured to work with other sets of rules, and it
> shouldn't take too much effort to replace the rules shown in the demo
> with fewer more abstract rules. It is going to be interesting to
> discover which sets of rules are best suited for various educational
> goals.

I really believe that a major challenge lies in striking this balance.
To me, the level of detail in the earlier demo does not seem useful for
teaching. Automated solving of certain types of equations in "the right
amount of detail", and with more explanation, I could see as useful as
*one element* of teaching *one part* of mathematics.

But it's very difficult to let students sit with an automated tool which
spews out endless similar-looking equations and *not* actually be
encouraging them to do the pattern-matching-crank-the-handle
mathematics.

I'm not shooting down your project here. But my humble guess is, that if
the current version of your PRESS gets included into Sage, it will rot
there and noone will use it. It has to be more polished, and present a
compelling use case in a realistic, contemporary teaching environment.

Best,
Johan

-- 
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] Giving Sage AI-based step-by-step equation solving abilities

[Johan S . H . Rosenkilde]

Hi Ted,

As William stated, I think any functionality improving SageMath's appeal
for, say, educating high school students would be very welcome. My main
concern is how valuable what you propose with PRESS-like printing is in
this respect.

You gave a printout of your current PRESS implementation earlier, for
solving a simple linear equation in one variable. That printout is
extremely verbose and very micro-syntactically oriented. My guess would
be that few high school teachers would wish to teach the simple isolation of a
variable technique that way. And students struggling with the technique
would mostly just become more confused ("undefine the binary '-' operator",
"change the association of +", etc.), and would fail building up
mathematical intuition but rather focus on the syntax.

You gave the following examples of more advanced problems PRESS can
solve:

> 4^(2*x+1) * 5^(x-2) = 6^(1-x)  (A.E.B. November 1971)
> cos(x) + cos(3*x) + cos(5*x) = 0  (A.E.B. June 1976)
> 3*tan(3*x) - tan(x) + 2 = 0  (Oxford Autumn 1978)
> log_2 x + 4*log_x 2 = 5  (London January 1978)
> 3*sech^2(x) + 4*tanh(x) + 1 = 0  (A.E.B. June 1971)
> log_e(x+1) + log_e(x-1) = 3
> e^(3*x) - 4*e^x + 3*e^(-x) = 0  (London June 1977)
> cosh(x) - 3*sinh(y) = O & 2*sinh(x) + 6*cosh(y) = 5  (A.E.B. June 1973)"

In Denmark - and my impression is that the same goes for other countries
as well - high school curriculum has largely moved away from solving of
such equations using identities and "tricks". The cos(x+y) identities
etc. and similar are not even taught anymore. In algebra, students
mostly solve linear equations with 1 or 2 unknowns and second-degree
equations. Simple isolation involving logs and exponentials, and there's
also some simplification and/or factoring of e.g. polynomial fractions
involved in function analysis.

Best,
Johan

-- 
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] Should __hash__ be constant across Sage invocations?

[Johan S . H . Rosenkilde]

I've created #21661 reporting that @func_persist is currently broken for
this reason.

Best,
Johan

-- 
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] Should __hash__ be constant across Sage invocations?

[Johan S . H . Rosenkilde]

Jeroen Demeyer writes:
> $ python3 -c "print(hash('hello'))"
> -74281615791272169
> $ python3 -c "print(hash('hello'))"
> 447613799834866972
> $ python3 -c "print(hash('hello'))"
> 5466708731786648082
>
> I think the only logical conclusion is that you should *not* rely on 
> comparing hashes across Python sessions.

Indeed - that's a devastating example.

Best,
Johan

-- 
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] Should __hash__ be constant across Sage invocations?

[Johan S . H . Rosenkilde]

> On 2016-10-07 13:35, Johan S. H. Rosenkilde wrote:
>> Should __hash__ be constant across Sage invocations?
>
> No. I see no reason why it should be.

I presume there's nothing in the Python spec that says so, since
object() doesn't satisfy this. Is that what you mean?

To me it seems obviously useful that this was satisfied across all
mathematical objects. The decorator @func_persist -- which is totally
broken right now because of this btw -- is an example of it.

Also, I found this behaviour very surprising, and my guess is that
others would as well - except the pure Python geeks perhaps.

Would it be extremely difficult to attempt to satisfy this?

Best,
Johan

-- 
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] Should __hash__ be constant across Sage invocations?

[Johan S . H . Rosenkilde]

I just got bit by the following behaviour, which is surprising to me:

sage: hash(GF(17))
-9223363248217694901



sage: hash(GF(17))
-9223363251803121333

So the hash of the very-much-the-same-every-time object GF(17) is not
constant across invocations of Sage. Is this expected behaviour? Is this
pervasive across UniqueRepresentation classes in Sage?

The implementation of __hash__ on finite fields claims to be the same as
for 'object'.

Context: I was using the hashes of objects as keys for a storage of some
experimental results. Sort of like the decorator @func_persist. This
clearly doesn't work currently.

Best,
Johan

-- 
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: Sage's references: new policy?

[Johan S . H . Rosenkilde]

>>> As discussed in another thread [1]_ on sage-devel recently, I propose 
>>> changing our policy toward references:
>>>
>>> - all references should be put into a master bibliography file
>>>
>>
>> There is one significant drawback to this: it will mean that a lot of 
>> ticket branches will be modifying this file, so merge conflicts between 
>> tickets may become more prevalent. If we can do something to ensure that 
>> resolving these merge conflicts is likely to fall within what standard 
>> merge strategies can do automatically we should probably do that.

Will it really be that bad? The proposed master bibliography is sorted
alphabetically by first author, so conflicts should only occur when two
tickets insert/modify citations right next to each other (or with
perhaps 1 citation between them). With >1000 references right now,
that's not going to cause too many extra conflicts, I think:

If there's 1000 "equidistant" references and a single release has
tickets that create 10 new random references (this is high, I think),
then there's roughly 20% chance that 1 pair of these references will be
within 1 of each other in the existing reference list.

Dima Pasechnik writes:
> I agree - however, perhaps it's better to think of using several bibtex 
> files (which is perfectly possible in LaTeX); e.g. one for number theory, 
> one for group theory, one for the commutative algebra, etc.

Hmm, that seems complicated: Wouldn't many references naturally fall
into multiple such categories, so every time you want to add a reference
you would have to grep for it across all files.

Best,
Johan

-- 
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: National Science Foundation support for Sage

[Johan S . H . Rosenkilde]

Super exciting - Congratulations! And please keep us updated when the
web page comes up.

Best,
Johan

-- 
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: Sage's references: new policy?

[Johan S . H . Rosenkilde]

> Having said this, I again would argue for an option to have aliases.
>
> E.g. say there is a popular Arxiv preprint cited 10 times in the source, 
> which then becomes
> a publication. It is really unnecessary to change all these 10 citations?

That's a good point. But does Sphinx support such aliasing out of the
box, or would we have to patch it on ourselves? If the latter is the
case, perhaps it's not *that* important?

Best,
Johan

-- 
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: Sage's references: new policy?

[Johan S . H . Rosenkilde]

With MR numbers, do you mean a link of the type [MR3352496]?

> well, for preprints clearly there is of course the arXiv number and for 
> sciences without a good database, there is doi.

Neither arXiv nor DOI completely catalogues all publications. I don't
know how many such cases appear in Sage's bibliography of course.

> concerning readability, there is a well known justification for using 
> sequential numbers

Can you clarify? How would sequential numbers work? The documentation of
Sage is never read in sequence but more like random access.

A reference like [Tho2000] is to me much more recognisable than
[MR1794692]. Having two or three of the latter kind of references in a
text, it takes brain-effort simply to distinguish if they are different
or not.

In articles and books, [Tho2000] is a much more popular format, and I
guess for exactly this reason. Of course in such publication sizes the
scalability problems don't show well, which could be the case for
Sage.

I just don't think so: in the current master bibliography, there's 1130
references. There's *2* collisions with the current naming scheme
(broken by appending 'a', 'b', etc.)!

> I'm not making this up, I used this to organise the references for 
> www.findstat.org, and I'm very happy with the result.

Can you elaborate? When I look at e.g.

http://www.findstat.org/GelfandTsetlinPatterns?action=diff=66=65

then the references are [KTT04], [Lo04] and [Sta99].

Best,
Johan



'Martin R' via sage-devel writes:

> well, for preprints clearly there is of course the arXiv number and for 
> sciences without a good database, there is doi.
>
> concerning readability, there is a well known justification for using 
> sequential numbers
>
> I'm not making this up, I used this to organise the references for 
> www.findstat.org, and I'm very happy with the result.
>
> Martin
>
> Am Mittwoch, 21. September 2016 11:10:00 UTC+2 schrieb Dima Pasechnik:
>>
>>
>>
>> On Wednesday, September 21, 2016 at 8:46:13 AM UTC, David Roe wrote:
>>>
>>> Preprints won't have MR numbers.  I also find MR numbers less readable.
>>>
>> and not all the CS-related publications make it into MR database, either.
>>  
>>
>>>
>>> We could just append letters ("a" then "b," etc) if there are collisions.
>>>
>>
>> I wonder whether it is possible to create aliases for references, i.e. 
>> make [Bla]_ and [Foo]_ both refer to [Foo].
>> This would allow less changes in the source.
>>
>>
>>  
>>
>>> David
>>>
>>> On Wed, Sep 21, 2016 at 4:38 AM, 'Martin R' via sage-devel <
>>> sage-...@googlegroups.com> wrote:
>>>
 Why not use the MR number as reference format?

 Martin


 Am Mittwoch, 21. September 2016 01:03:27 UTC+2 schrieb John H Palmieri:
>
> As discussed in another thread [1]_ on sage-devel recently, I propose 
> changing our policy toward references:
>
> - all references should be put into a master bibliography file, and
> - all references should be, insofar as possible, in a standard form: 
> for a work by a single author "Author" published in YEAR: [AutYEAR]. For 
> a 
> work published by "Author" and "Coauthor" in YEAR: [ACYEAR]. The year 
> should be four digits.
>
> The main point is the first item is to avoid conflicting 
> cross-references, and it also seems to make sense to list all references 
> in 
> one place. (The goal behind the second item is just consistency.)
>
> This is implemented at https://trac.sagemath.org/ticket/21454.
>
> Any comments?
>
> -- 
> John
>
> REFERENCES:
>
> .. [1] 
> https://groups.google.com/d/msg/sage-devel/-_kszKLhICw/SjLMs4rXCAAJ
>
> -- 
 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+...@googlegroups.com.
 To post to this group, send email to sage-...@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: sage -br rebuilds things that were not changed

[Johan S . H . Rosenkilde]

leif writes:
> Well, probably it's just me, but I always (also) review tickets on trac
> (i.e., via what git-o-lite gives); the whole branch, but also each
> individual commit.  You just need a browser to do so.

I use git-o-lite a lot too, but often switch back to my Emacs and git
log using Magit :-P

> Having a Sage installation at hand, it's even more tedious to do so on
> the command line when the relevant commits are "out-of-order" / mixed
> with unrelated commits.

I mostly take the commit id from trac. But yes, without git-o-lite it
can get difficult to find the commits you need. I'm sure there are "git
log" flags for it, but I'm not an expert. It just hasn't come up enough
for me to really try and find a solution.

>> "whatever head" is always develop, so I'm always pulling into the newest
>> beta release.
>
> Well, that doesn't make much of a difference, unless the ticket is
> incidentally based on the same (which is rarely the case, since most
> tickets live longer than a single beta-release cycle).

I just wanted to stress that it's not a random choice. Indeed, barring
the "history becomes difficult to read", I don't see any argument
against all devs always working on latest beta, in which case it would
always make sense to update all tickets to that. We could even
automatically upgrade all tickets to latest beta on releases. Though
based on this discussion, I'd guess many of you would get angry due to
"history becomes more difficult to read".

> For trivial changes, you can also put inline patches onto trac the owner
> of the ticket / branch can easily apply, and for more complex changes,
> you can always create a new branch on trac *without* changing the
> ticket's branch to that.  Then the owner of the original branch can
> cherry-pick from your branch, if it's based on something else.

This is a good idea that would allow me to continue using my current
workflow, without annoying other devs.

> (With different Sage installations, you could do similar locally of
> course, i.e., "backport" the changes you made on top of your develop to
> master+fetched original branch, say, and push the resulting branch.  I
> personally often first make changes in some random Sage installation,
> then moving them around, later pushing to trac from a "suited" one.)

Aha, sort of like what Daniel wrote, except that fetching the branch
into  "random Sage installation" means you don't get the low compilation
time benefits.

>> I don't see why all developers shouldn't always be on the latest beta.
>
> Time?  Resources?
>
> Note that many, I guess, have Sage installations here and there, and
> most likely don't or cannot keep each of them always what you'd call
> "up-to-date", but rather at one of the previous "stable" releases, or
> something inbetween.


What time? What resources? My dev model needs only a single Sage
installation and no extra software to achieve overall very low
compilation time. The other suggestions I've heard need multiple Sages,
extra software and/or does not minimise compilation time. Checking out a
ticket takes a whopping extra 3 seconds (if it takes longer it's because
of merge errors which I would have to fix anyway).

Note I have one extra Sage tree to ensure that I have a working Sage at
any time. It's on latest stable and I never develop on it.

> [Random insertion:  Wasn't it you who [had to] upgrade[d] to Ubuntu
> 16.04 just to get the next version of Emacs? ;-) ]

Hmm, no. I've used Arch linux for 3 years now because Ubuntu has too old
software. But I've twice had major compilation issues due to Arch
upgrading to a new release of some dependency (e.g. ranlib or gcc) long
before any other distro.


> Obviously, there are more "recent" beta releases than stable ones.  And
> as mentioned, tickets and their branches age.
>
> So you'll never have all tickets (not even a large percentage) based on
> the latest beta.
>
> It's easier if you keep one Sage installation at master, and another at
> some later beta.  The problem (if tickets are based on the latest beta)
> IMHO is that one is too often forced to "upgrade" for no reason, at
> least if one forgets to first check what release a branch was based on.
> If people keep pushing back "rebased" branches, the situation just worsens.

OK, but I just still don't really see the problem of being "forced to
upgrade". I don't see how it hurts me that I'm always working on the
latest beta - my patch has to work with that anyway. Except for the
"history is more difficult to understand" argument. But is that really
enough of an argument to jump through hoops and rings for achieving low
compilation time in another way?


> More seriously, different Sage installations, trying to pick the most
> suited when going to actually build a fetched branch.  But sometimes at
> least, you also want to test on a specific machine (hardware, OS/distro,
> compiler, whatever).

OK, thanks for describing your workflow.

Best,
Johan

-- 
You received this message 

Re: [sage-devel] Re: sage -br rebuilds things that were not changed

[Johan S . H . Rosenkilde]

Jeroen Demeyer writes:
>> https://ccache.samba.org/
>
> And I forgot to mention that I have 2 complete Sage installation trees 
> so I can let one compile while I use the other.

Thanks, that's useful. Do you need any special setup or care for making
it work in the complicated Sage compilation system, or do you just
override gcc as suggested in the manual? How much does it speed up
compilation?

It would seem to me you could often come in the case that *both*
copies are/needs compiling: You want to work on ticket A and so checkout
that on Sage1. While it's doing a 1h compilation due to jumping between
releases, you checkout ticket B on Sage2. But that's also a release
jump, so compilation ensues. Perhaps ccache makes this moot?

Does it ever get clumsy wrt. tracking which tree is in which version and
has which ticket checked out?

I also have two Sage installations, but it's a stable one I use for
work, and a devel one. That way, if devel screws up for whatever reason,
I can still always continue working. I also use it for checking Sage
behaviour without my ticket or if devel is compiling.

Daniel Krenn writes:
> Having a version of each stable/rc/beta SageMath in a separate
> directory. Every now and then I delete an old rc/beta. For working on a
> ticket I use exactly the version of the branch of this ticket.
> Recompiliation time is very low in this way (usually).
>
> I have one additional directory "merge", which is only the git
> repository without anything created for
> - looking at tickets if I am in doubt about the current version (git
> describe) and
> - for merging in a newer stable/rc/beta into a branch.

Thanks.
Do you feel this can get clumsy?
Like, how do you find which release have which ticket checked out?
When you merge in a new release into a branch you will have high
compilation time - but perhaps you don't do this too often?



I seriously think a lot of beginners are struggling with compilation
time when working with Sage, inadvertently jumping a lot between
releases. Apparently, my workflow is not popular, but could we still
add something to the Development manual to help people?

Best,
Johan

-- 
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: sage -br rebuilds things that were not changed

[Johan S . H . Rosenkilde]

leif writes:
>> But if you want to actually make changes then this creates a new merge 
>> commit which furthermore is against the conventional order (where the 
>> feature branch is the first parent). So it makes the commit history harder 
>> to understand.
>
> I'd rather say "impossible", or more precisely, to later review exactly
> the commits that belong to the ticket in question.

I'd say that's a Git tools question. Without flags, git log will show
the individual commits in chronological order, but you can ask to do
topsort or something. Personally, it seldom comes up for me, and when it
has, I've been able to get by using the commit numbers given by Trac or
searching through the log. Sure, I probably have not been involved in
the most complicated tickets Sage has ever seen, though.

>> I've heard arguments against "gratuitously" merging the ticket to
>> newest release when e.g. just fixing a typo. But that seems to me to be
>> a rather theoretical complaint, since the ticket will be merged later on
>> anyway.
>
> Absolutely not, unless you're /creating/ a new / "the" branch on the
> ticket.  If you're taking an already existing branch from a ticket and
> make changes to be pushed back later, you should *always* fetch, not
> pull into whatever head you currently have locally.
>
> But maybe I just misunderstood you.

"whatever head" is always develop, so I'm always pulling into the newest
beta release.

> For new branches, I think it's best to base them on the last *stable*
> release (i.e., check out master before creating the new branch), unless
> you really need fixes from later betas, or it's clear (or likely) that
> you'd get merge conflicts with later betas if you base your branch on
> master.  (But you'd notice that sooner or later when looking at the
> colour of the branch on the trac ticket -- unfortunately nobody ever
> gets notified when the colour changes after trac's develop has been
> updated to the next beta, something either trac or a patchbot could
> implement.)
>
> If you always base your branches on the latest *beta*, others will just
> get forced to pull and build the latter (with typically loads of
> completely unrelated changes), no matter whether they fetch or pull your
> branch.  So in other words, you're (at least potentially) moving rebuild
> load to others.

I don't see why all developers shouldn't always be on the latest beta.

It's also the only version that would make sense to base *all* future
tickets on, though - as you say - many tickets might not care about the
diff between master and develop. So in the interest of minimising
compilation time for developers overall, I think we should base all
tickets on the latest beta. Otherwise, when you jump between
small-ticket-A and small-ticket-B, you might suddenly trigger a huge
recompile since B happened to need one of the 100 tickets between master
and develop, while A didn't.

Without this or a similar schema, working on multiple tickets becomes
absolutely unbearable for me due to compilation time. How do you guys
cope with that?

Best,
Johan

-- 
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] sage -br rebuilds things that were not changed

[Johan S . H . Rosenkilde]

Volker Braun writes:

> Thats ok for reviewing tickets, and implemented as "git trac try 
> ". 

OK. I had a chat with Thierry Monteil and we agreed there were some
subtle differences I don't remember - but I'll take a look at "git trac
try".

> But if you want to actually make changes then this creates a new merge 
> commit which furthermore is against the conventional order (where the 
> feature branch is the first parent). So it makes the commit history harder 
> to understand.

I've heard arguments against "gratuitously" merging the ticket to
newest release when e.g. just fixing a typo. But that seems to me to be
a rather theoretical complaint, since the ticket will be merged later on
anyway.

I agree with the problem with the merge order which can be annoying. I
don't know if there is an obscure Git command for changing that. But if
the alternative is to spend tons of time recompiling every time I'm
checking out a ticket, I'm not sure I'll do the trade ;-)

Best,
Johan

-- 
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] sage -br rebuilds things that were not changed

[Johan S . H . Rosenkilde]

Jeroen Demeyer writes:
> On 2016-09-10 00:03, Paul Masson wrote:
>> Why would recythonizing be necessary when only changing the same file on
>> the same branch?
>
> You are not changing just one file. When you checkout a new branch, a 
> lot of files get changed. When you checkout the old branch again, a lot 
> of files get changed again. The fact that they are changed to have the 
> same content that they originally had, is irrelevant. As far as the 
> filesystem is concerned, those files are changed.

Yes, and even fixing Cythonizing to using file hashes is only a partial
solution, right: Make would still cause huge recompilations all over the
place, AFAIK.

I've completely stopped jumping directly between tickets, and always use
the following schema for checking out a ticket:

$ git checkout develop
$ git trac pull develop
$ Run "make" if develop was not up to date
$ git checkout -b _
$ git trac pull 

If I already had a branch checking out #ticketno, then I'll delete it
first. This way, you'll never inadvertently check out an old releases of
Sage. I'm sure many developers are using variations of this schema.

IMHO, this or a similar way of checking out should be the recommended
one in the Sage Developer's manual. It would save a lot of people a lot
of compilation time.

Best,
Johan

-- 
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: ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

> Regarding speed, there are two issues:
>
> 1. Building the documentation from scratch. I don't  know if we can expect 
> this to go any faster. The PDF version of the documentation is 3,474 pages 
> long. No, wait, that's just the contribution from references/combinat: the 
> whole reference manual is 18,442 pages long. I can build this on my machine 
> in about 8 minutes, and this does not seem unreasonable. Am I wrong about 
> this? (It could be sped up a bit for parallel builds if the largest pieces, 
> e.g., reference/combinat, were broken into smaller pieces, but I don't know 
> how much speed increase we can hope for.)

OK, this is good to know. It takes considerably longer on my machine, so
there is something I'm really not doing right (possibly not having
parallel build enabled). I'll experiment with this.

8 minutes from a clean build is not impressive IMHO, but perhaps it's
then not the most important piece of the compilation process to improve.

Best,
Johan

-- 
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: ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

> In any large document, such as the sage manuals, there are bound to be 
> uniqueness issues with the choice of labels for references. The best way to 
> resolve this is for us to start using a specified format for the 
> references. Currently we do not even have guidelines for this so it is not 
> surprising that different people do different things.

Agreed. The Developer's Manual could be improved in this respect.

> It would also help to have the references appearing in one file, as William 
> suggests, so that people can find them easily and check that the label does 
> not already exist. A reference file would also help ensure that people use 
> whatever format is agreed upon for the references.

+1

Best,
Johan

-- 
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: ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

leif writes:
>> ... [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting
>>Codes, Cambridge Univ. Press, 2003.
>
> Well, first of all it is stupid to use such a short abbreviation, even
> without a year.  Presumably it was introduced when references were
> local, so we may create a (meta-)ticket to change all of such occurrences.

Agreed. The inspiration for new developers in the Sage Development
manual uses the citation label "[SC]":

http://doc.sagemath.org/html/en/developer/coding_basics.html#documentation-strings


>> Is this sort of mess the reason Sphinx is so terribly slow, I wonder...
>
> Well, not that long ago, docbuilding in parallel wasn't even possible
> (h/t mostly John Palmieri IIRC, with a few others); before, the whole
> reference manual had been one monolithic block.
>
> Of course the documentation keeps growing (and hence also Sphinx' memory
> footprint and runtime), but it was IMHO always double dog-slow.  But
> especially building plot* gets slower and slower because people keep
> adding more and more "nice" things I guess.
>
> To me the most annoying thing is that "make doc" (which ptestlong for
> example for no reason depends on) meanwhile even takes ages when Sphinx
> does nothing, or almost nothing, because nothing changed.  (My recent
> impression is though that some files accidentally get touched somehow,
> such that they to Sphinx look modified.  I can't give any concrete
> example, just noticed.)

Yes, doing `make doc` goes through every chapter of the manual, very
carefully determining that nothing changed. I often use "./sage
-docbuild reference/ html" instead, but that seems even more
fragile than regular doc-building.

Jeroen Demeyer writes:
> General comment to all people complaining about Sphinx: reviewing 
> existing Sphinx-related tickets such as #20577 will show that you 
> actually care and will encourage other Sage developers to continue 
> working on Sphinx.

Thanks for your work! Are there tickets (or upstream-not-merged-changes)
which would make Sphinx faster or have better, less fragile incremental
building?

Best,
Johan

-- 
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: ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

Dima Pasechnik writes:
> only a small minority of Sage users actually use terminal.

How do you know that? Seriously, I'd like to know how our users
distributed across interfaces. It's my impression that quite a lot of
casual users of Sage begin with terminal use and never leave it.

> And in any event, demanding a bibliography reference in terminal is
> a bit over the top (even people who live in terminal, like me, would use a 
> web browser to
> look at references, and thus use HTML documentation).

Why? The documentation could automatically create a REFERENCE block at
the end of any method/function/etc. with the bibliographic information
of works cited in that doc string.

> I also totally don't see a value of having a reference to the same thing in 
> every file. You can use grep if you must not leave the terminal.
> Also, in Sage, you can use search_src("\[HP\]\ " to find a place [HP] is 
> defined:

The value is that, as a user, when I press "myfunc?" I can *see*
what the reference means without having to spend time and mental effort
grep'ing or search_src'ing. Ask a user what he prefers.

> please don't... this breaks HTML docs badly.

How? I might be wrong (I clearly don't understand Sphinx well), but it
seems that all it breaks is that no hyperlink appears -- but I don't
need that since the bib-information is *right there*.

What worries me most is that it leads to possibly mutually
inconsistent versions of the same bib-information spread all over the
place.

> you are welcome - it's indeed sometimes not easy to find these errors.
> But do feel free to ask pointed questions if you get stuck.

Thanks. I've been working on #20908 and it seems that modifying
an index.rst file leads more often to corruption (and hence `make
doc-build && make`) than most other modifications. That or I am just
unlucky...

> I agree that speeding up this is very important for smoother development.
> Only it seems that our options are not very broad here, unless we get 
> involved in speeding it up ourselves

My conclusion too, after browsing the competition. What I don't
understand is that "Sphinx bad performance" reveals almost no useful
discussions on Google. I would think Sphinx was used on all large Python
projects. Could it be that the way we are calling Sphinx leads to bad
performance?

Travis Scrimshaw writes:
> I don't think so. How else could you resolve a reference in a separate 
> file? It would likely lead to a lot of duplication of reference information 
> because of this.
> ...
> It depends on what you want to achieve. We currently do all 3 in Sage and 
> none of them doesn't cause any problems.

Agreed, unique bib-information is Good(tm); that's why many of us use
BibTeX and possibly Zotero or similar tools. It's just that Sphinx's
incarnation of this is not very smart: the bibliographic information
ends up in a random source file. As a user, I would be confused by
clicking in the doc of module A on some citation, and ending up in the
doc of mostly unrelated module B.

> It depends on what you want to achieve. We currently do all 3 in Sage and 
> none of them doesn't cause any problems.

Is the extra negation intentional? What we currently do in Sage is
inconsistent, has lots of duplication of reference information, is not
user-friendly in the way I just described *and* is badly documented. Is
this not a problem?

Best,
Johan

-- 
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: ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

I should perhaps clarify my main question:

Isn't the unique citation as used in Sphinx a Bad Idea for Sage?

Most source files in Sage are not ordered, and if we refer to document
[X] in two different source files, we currently have three options:

1) Arbitrarily define [X] in one file and refer to it in the other.
2) Define [X1] in one file and [X2] in the other.
3) Use non-ReST syntax for references (i.e. no underscore in links and
   " - " instead of ".. " in definitions) and define [X] in both files.

All three are bad solutions in my opinion, and all three are in active
use in Sage (perhaps 2. inadvertently rather than intentionally).

Note that with 1., in the HTML-documentation of the second file, a user
will be taken to the doc of the first file when clicking the link. In
the Sage terminal, users will not see the def of [X] (and can't find it
since it's in a completely different file).

Personally, I'd rather go with 3. than 1. even though it means giving
the same bibliographic information in every source file it is used.

My unclear post had two other, vaguely related points:

A) I'm currently fighting with Sphinx over a bug/userbug in citations in
   sage.coding. Thanks for #21418, Dima.

B) A general rant that Sphinx compilation is much, much slower than what
   it accomplishes gives it any right to be. It also horribly breaks
   much more often than any other part of the compilation chain (for me,
   at least), forcing me to do `make doc-clean && make` basically every
   time I want to inspect HTML documentation. Apparently the project's
   name comes from the riddle of its ineptitude...

Best,
Johan




Dima Pasechnik writes:

> I've opened #21418 to deal with refs mess in coding/
> Should be ready for review soon (there are duplicate references, missed _ 
> in []_, wrong tabulation in docstrings, etc
>
>
> On Monday, September 5, 2016 at 9:59:36 AM UTC, Dima Pasechnik wrote:
>>
>>
>>
>> On Monday, September 5, 2016 at 9:46:22 AM UTC, Johan S. R. Nielsen wrote:
>>>
>>> I just ran into a doc issue that has been bothering me for years: global 
>>> uniqueness of reference labels in Sphinx. For instance, in 
>>> sage.coding.code_construction, we have: 
>>>
>>>
>>> .. [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting 
>>>Codes, Cambridge Univ. Press, 2003. 
>>>
>>> This means I cannot use [HP] as a reference label in another file, say 
>>> sage.coding.hamming_code. Writing "[HP]_" in doc-string globally in Sage 
>>> *should* generate a link to sage.coding.code_construction. It does in 
>>> fact give me a compilation error :-S 
>>>
>>
>> hmm, I think it should work. E.g. [BH12]_, defined in 
>> combinat/matrices/hadamard_matrix.py, does work:
>>
>> $ grep -R BH12 .
>> ./coding/linear_code.py:[BH12]).
>> ./graphs/generators/families.py:Seidel switching class of the latter 
>> graph (see [BH12]_) coincides with the set
>> ./graphs/generators/classical_geometries.py:For more information, see 
>> Sect. 9.9 of [BH12]_ and [BvL84]_. Note that the `page of
>> ./graphs/generators/classical_geometries.py:For more information, see 
>> Sect. 9.9 of [BH12]_ and series C14 in [Hu75]_.
>> ./graphs/strongly_regular_db.pyx:strongly regular graph. See [BH12]_ 
>> and [BI84]_ for details.
>> ./graphs/strongly_regular_db.pyx:Return g and n, if they exist. See 
>> Sect. 9.1 of [BH12]_ for details.
>> ./graphs/strongly_regular_db.pyx:Sect.9.8.3 of [BH12]_.
>> ./combinat/matrices/hadamard_matrix.py:[BH12]_. For the case `n=324`, 
>> see :func:`RSHCD_324` and [CP16]_.
>> ./combinat/matrices/hadamard_matrix.py:.. [BH12] \A. Brouwer and W. 
>> Haemers,
>> ./combinat/matrices/hadamard_matrix.py:   
>>  `(n-1,(n-2)/2,(n-6)/4,(n-2)/4)`, see Sec.10.4 of [BH12]_. Thus we build `C`
>> ./combinat/designs/twographs.py:things such as constructing the complement 
>> two-graph, cf. [BH12]_.
>> ./combinat/designs/incidence_structures.py:An incidence structure 
>> is a generalized quadrangle iff (see [BH12]_,
>>
>> (besides the missing _ in linear_code, there are more _ missing there :-))
>>
>> Dima
>>
>>  
>>
>>>
>>> This seems to be the recommended way of doing it in Sphinx. Am I the 
>>> only one who thinks this is crazy? Can/should we do something about 
>>> this? 
>>>
>>> On a related note, the Developer's manual doesn't mention this problem, 
>>> or the fact that people should use ReST references (i.e. remember the 
>>> underscore), and that REFERENCES blocks should be at the top of the 
>>> module (and not in individual methods/functions). A quick grep showed 
>>> lots of recent code violating this convention. 
>>>
>>> Is this sort of mess the reason Sphinx is so terribly slow, I wonder... 
>>>
>>> Best, 
>>> Johan 
>>>
>>


-- 

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

[sage-devel] ReST References in Sphinx and uniqueness

[Johan S . H . Rosenkilde]

I just ran into a doc issue that has been bothering me for years: global
uniqueness of reference labels in Sphinx. For instance, in
sage.coding.code_construction, we have:


.. [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting
   Codes, Cambridge Univ. Press, 2003.

This means I cannot use [HP] as a reference label in another file, say
sage.coding.hamming_code. Writing "[HP]_" in doc-string globally in Sage
*should* generate a link to sage.coding.code_construction. It does in
fact give me a compilation error :-S

This seems to be the recommended way of doing it in Sphinx. Am I the
only one who thinks this is crazy? Can/should we do something about
this?

On a related note, the Developer's manual doesn't mention this problem,
or the fact that people should use ReST references (i.e. remember the
underscore), and that REFERENCES blocks should be at the top of the
module (and not in individual methods/functions). A quick grep showed
lots of recent code violating this convention.

Is this sort of mess the reason Sphinx is so terribly slow, I wonder...

Best,
Johan

-- 
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: Categories catalog?

[Johan S . H . Rosenkilde]

> ... while you don't need a catalog to create such an alias.

But then we would have even more stuff in the global namespace.

> Still, having a catalog wouldn't be bad.

+1 to having the catalogue. +1 to allowing aliases in that catalogue.

+1 to removing not-very-common categories from global namespace as well.

Best,
Johan

-- 
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: The Sage Wiki

[Johan S . H . Rosenkilde]

> +1.  If anything wiki.sagemath.org should redirect to
> trac.sagemath.org/wiki since Trac already provides a (generally nicer,
> more powerful) wiki that integrates better with development ;)

+1 to merging wiki.sagemath.org into trac.sagemath.org/wiki.

Right now there's tendency for duplicated information, and the current
way wiki.sagemath.org is used, it's almost exclusively for developers
anyway. Something integrated with trac would do that much better, and it
would be exactly the same syntax as trac comments.

Best,
Johan

-- 
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: The Sage Wiki

[Johan S . H . Rosenkilde]

>> What do the Sage developers even want to use the wiki for? Apart from
>> SageDays organisation.
>
> - listing sage days
> - there's a nice list of interact examples: https://wiki.sagemath.org/interact
>
> Look at https://wiki.sagemath.org/RecentChanges to see what people
> *do* use the wiki for.  E.g., there's been a lot of activity on a page
> "Coding Theory in Sage: A collection of ideas and long-term goals for
> Coding Theory in Sage, and the people interested." today by several
> people.

Yes, I just wrote that page and some participants on SD75 added some
stuff.

Apart from this, and the Debate/Collective Infrastructure Management
page, changes are +1 year old, and growing rapidly older.

>> At SageDays75, we just created (or rewrote)
>> https://wiki.sagemath.org/Coding_Theory sub-page and propose it to be a
>> place to discuss long-term goals for coding theory in Sage. Let's see
>> how it works out.
>
> That's definitely a very good use of this wiki (or any other sage one).

Indeed, I hope people will be interested in keeping it alive.

Best,
Johan

-- 
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: The Sage Wiki

[Johan S . H . Rosenkilde]

> Would you have any interest in moving the wiki 
> to https://github.com/sagemath/sage/wiki ? 

What would be the advantage of doing so?

What do the Sage developers even want to use the wiki for? Apart from
SageDays organisation.

At SageDays75, we just created (or rewrote)
https://wiki.sagemath.org/Coding_Theory sub-page and propose it to be a
place to discuss long-term goals for coding theory in Sage. Let's see
how it works out.

Best,
Johan


help writes:

> Would you have any interest in moving the wiki 
> to https://github.com/sagemath/sage/wiki ? 
>
> On Friday, August 26, 2016 at 9:12:01 AM UTC-7, Johan S. R. Nielsen wrote:
>>
>> Hi everyone, 
>>
>> I just edited the front page of http://wiki.sagemath.com so that it 
>> appears less embarrassingly out of date. I restructured it so that it is 
>> more clear that it is a place for certain developer organization (mostly 
>> SageDays), so that it now less pretends to be a very lively place with 
>> frequent updates everywhere (or rather, so that it is honest about where 
>> it is out-of-date). 
>>
>> I stuffed links to lots of sub-pages under headlines marked out-of-date. 
>> If you disagree or update one of those sub-pages, please just put the 
>> link under some appropriate headline not marked out-of-date :-) 
>>
>> Best, 
>> Johan 
>>


-- 

-- 
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] The Sage Wiki

[Johan S . H . Rosenkilde]

Thierry Dumont writes:

> Certainly, it is http://wiki.sagemath.org

Haha, yes of course it is :-)

-- 
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] The Sage Wiki

[Johan S . H . Rosenkilde]

Hi everyone,

I just edited the front page of http://wiki.sagemath.com so that it
appears less embarrassingly out of date. I restructured it so that it is
more clear that it is a place for certain developer organization (mostly
SageDays), so that it now less pretends to be a very lively place with
frequent updates everywhere (or rather, so that it is honest about where
it is out-of-date).

I stuffed links to lots of sub-pages under headlines marked out-of-date.
If you disagree or update one of those sub-pages, please just put the
link under some appropriate headline not marked out-of-date :-)

Best,
Johan

-- 
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] mailing list administration

[Johan S . H . Rosenkilde]

The mails seems to have been correctly sent out to subscribers (of
sage-devel). At least a few of us here at SD75 got it. I can't explain
why it's not showing up on the google groups web site.

Best,
Johan

-- 
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: Problem retrieving a (positively reviewed) ticket

[Johan S . H . Rosenkilde]

I confirm the problem, even with develop:

$ git fetch trac develop
fatal: Couldn't find remote ref develop

Best,
Johan

-- 
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: Should @experimental be used on a completely new module in Sage

[Johan S . H . Rosenkilde]

William Stein writes:
> Good point.  Also, I'm for making the user type
>
>import something.or.other
>
> **explicitly**, rather than having it pre-imported on startup.  Of
> course, the import command will be documented.

I see your point. But is

   "You need an explicit import, and a warning is possibly written at
   this time"

so different for the user than

   "Automatic pre-import, write a warning when used"?

Best,
Johan

-- 
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: Should @experimental be used on a completely new module in Sage

[Johan S . H . Rosenkilde]

> That thread doesn't mention @experimental or decorators explicitly.

Well, you're replying to Daniel Krenn's comment: he points at a public
branch, explicitly mentioning that it introduces
sage.misc.superseded.experimental which "acts like a deprecation, but
giving a FutureWarning stating that the code/module is experimental". He
is clearly indicating that the warning will be emitted when the code is
called/constructed, and a decorator is simply a convenient way to
achieve that.

> For what it is worth, I was trying to be **sarcastic** above, not
> condescending.  It's originally my fault sage is such a monolith
> instead of divided into meaningful modules.

OK, fair enough. Tone of voice is easily misunderstood in emails .

> I stand by my statement that you quoted that it should be possible to
> include code that unstable.  I'm not sure that this @experimental
> decorator is the way to go.  It would be more standard to have an
> explicit library import, which  -- on import -- would print out
> something about it being experimental and unstable.  (This is not so
> unusual in the world of software.)

I agree. But printing a warning on use is a not-too-distant
approximation considering the current monolithic nature of Sage. I think
the @experimental warning is as good as it gets, for now.

Correct me if I'm wrong, but it then seems to me that you generally
agree that it makes sense to accept a module into Sage which is somehow
marked as (temporarily) unstable? My disagreement with Travis seems to
stem from our different views on this.

Best,
Johan

-- 
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: Should @experimental be used on a completely new module in Sage

[Johan S . H . Rosenkilde]

> Regarding this whole @experimental discussion (I never heard of
> @experimental until just now), it seems like yet another case of
> trying to use some awkward mechanism to get around ignorance of Python
> packaging and modules.  Python has this amazing thing called
> "Python libraries" and a "packaging system" (pip) that makes it
> possible to write and share code with other people.People should
> check it out...

On the thread
https://groups.google.com/forum/#!topic/sage-devel/LXWs6KOw0Lk, William
Stein wrote:
---
I think this is a really good idea.  I'm surprised we didn't
explicitly think about it when deciding on our deprecation policy in
the first place.

I'm definitely for there being a way to include code in Sage that is
very explicitly marked as unstable for which the usual deprecation
policy doesn't apply.   (I'm against such code not having 100% doctest
coverage.)
---

Following the very positive response Thierry's suggestion got, the
@experimental decorator was created.

Please don't be condescending while contradicting yourself.

Best,
Johan

-- 
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: Should @experimental be used on a completely new module in Sage

[Johan S . H . Rosenkilde]

> leif wrote:
> Well, depends on /what/ you write there...
>
> At least mentioning the different notions of skew polynomial evaluation
> (and that currently only one, and which, is implemented) shouldn't hurt.
>
> And you could clearly state what aspects of the interface are probably
> subject to change, and also which aren't.
>
> (You both still have to agree on the latter though, but my impression is
> this isn't really the point where your opinions completely diverge.)

I agree with Travis that such a warning is not fundamentally different
from using @experimental. Also, casual users will probably miss it; if
behaviour then later changes without them seeing a deprecation, that's
annoying. Deprecation warnings are for both library developers and for
users.

My point is that I don't know what might change in the near-future.
Though I could assign vague probabilities, I'd rather just say "feel
free to use this but be prepared for some changes". "some changes" would
cover name changes, changes in order of arguments, and in less common
cases, behavioural changes (e.g. possibly to __call__). But overall, a
user can count on the module to keep on existing and broadly providing
at least the same set of functionality.

I have a hard time seeing when @experimental could *ever* be used, if it
is not applicable in this scenario. And back when @experimental was
suggested, it was broadly received as a good idea
(​https://groups.google.com/forum/#!topic/sage-devel/LXWs6KOw0Lk).

> Travis Scrimshaw wrote:
> As Johan stated, my viewpoint is because you are not promising a stable 
> API with the @experimental, anyone who wants to develop code based upon 
> @experimental code either are requiring you, who put in the @experimental. 
> to also fix their code should the API change or have their code be silently 
> broken (say, for lack of a specific doctest). So by marking everything as 
> experimental, you're effectively saying you should not build upon this.

If a Sage developer builds module B on an @experimental module A, it
puts no further burden on a developer who wants to later modify A: s/he
will in either case need to fix B. @experimental modules are often
introduced, as is the case in #13215, by developers who wish to use it
themselves. In this case, A and B are developed by the same people.
After a short while, say a year, the @experimental warning can be
removed.

Best,
Johan

-- 
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] sage_mode for emacs has display problem in sage 7.4 beta0

[Johan S . H . Rosenkilde]

Hi,

On my machine, Ivan's workaround also does not help: I get exactly the
same behaviour as Martin R. I run Emacs 24.5.1 on Arch Linux 4.6.3-1,
x86_64.

See also this depressing post on Emacs Stack Exchange:
http://emacs.stackexchange.com/questions/24453/weird-shell-output-when-using-ipython-5

I don't know how serious this can turn out to be for sage-mode. But it
seems dire...

Best,
Johan

-- 
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] Should @experimental be used on a completely new module in Sage

[Johan S . H . Rosenkilde]

Hi sage-devel,

As a huge part of Arpit Merchant's GSoC project on Gabidulin codes,
we've been working on Xavier Caruso's old patch implementing skew
polynomial rings, #13215.

While everyone involved has considered the code and math carefully, it
is my opinion that the design could still be subject to (mild) changes
in the near future, so I suggested that the code be merged but with
the @experimental warning on. This arose in part because I very recently
was made aware that there are multiple conflicting notions of evaluation
of skew polynomials, and the current patch supports only one. I imagine
that other, similar things could crop up.

One reviewer is strongly opposed to adding @experimental to the module.
He would accept adding it on __call__ due to the aforementioned example,
but not to simply constructing the skew polynomial ring. It seems we
fundamentally disagree on what valid use-cases are for @experimental.

So we bring it to sage-devel for arbitration. Essentially, my point of
view is that when a new structure is added to Sage, and one has mild
doubts that certain details could change, then the @experimental
decorator can/should be added. But the code can still be merged, even if
the addition of @experimental reveals less than fool-hardy conviction in
the design. The reviewer argues against this because the code is useless
for building upon if one cannot trust the API.

(Perhaps the reviewer would like to argue his stance more clearly than I
can.)

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> 2) When I do git-blame, or other similar commands, I can easily get a
> commit message or commit hash, but I can't get a ticket number. Which is
> usually what I want (to look up e.g. why a change had been done). That's
> user-unfriendly.

I should have added that I don't think we can do much about this, and
that the thing with "meta-squashing" is not Sage territory, nor do I
suggest building elaborate Sage-specific tools to work around it.

Really, I just suggest the diff-button thing, and I think its very
doable.

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> Because there is no ticket-DAG and there is no immutable history of 
> tickets.

I don't see why there couldn't be. Once a ticket is closed, it is
immutable. While a ticket is open, its position in the DAG is mutable:
it will always depend on the tip of develop, as well as tickets that it
explicitly depends on.

> Ticket dependencies are informational but don't change what code 
> is being added. Which is precisely why they can be mutable.

I'm suggesting modifying a tool that makes it more clear to reviewers
what the logical diff of a given ticket it. Not the diff off the ticket
plus its dependencies, which is usually not what a reviewer is
interested in. This is a user-thing, not a backend-thing.

Say someone is working on ticket A. A is huge so I suggest breaking off
a part of it into its own ticket B. As a reviewer, I'll naturally be
looking at the diff of both A and of B, even if I'm formally beginning
my review at A. When I'm asking trac to show me the diff of B, it's
unhelpful that it shows me the diff of A+B.

Do you disagree that this is unhelpful? Or do you believe it's (close
to) impossible to make Git show me the information I really want, in
(almost) all instances? Or am I not understanding your objection to my
suggestion at all?

> If it 
>> wasn't for the stupid git-behaviour of throwing-away-single-commits-info 
>> when you do commit-squasing, I would suggest squashing all commits to 
>> single tickets upon merging.
>
>
> It seems that you want to erase history yet have it, too. 

In a sense. I think Git should have a possibility of "meta-squashing"
commits so that, in most commands it would treat a group of commits as
one commit. But it is possible to "open it" and get the detailed commit
history, if I needed it. I think this would be useful outside of Sage.
And I don't see a technical reason that this shouldn't be possible in
exactly the same set of cases that squashing is currently possible.


> You basically want a pre-commit review workflow, whereas we currently do 
> post-commit review. Both are feasible but developers definitely need more 
> experience with git in the former.

I'm not sure what you mean. But I don't want to change the review
workflow at all. I've raised two points so far:

1) it would be nice if the diff button showed me only the diff of the
current ticket. Currently I get ticket + deps which is user-unfriendly.

2) When I do git-blame, or other similar commands, I can easily get a
commit message or commit hash, but I can't get a ticket number. Which is
usually what I want (to look up e.g. why a change had been done). That's
user-unfriendly.

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> You are trying to build a DAG of tickets that is a coarser version of the 
> git DAG. You'd need 
>
> * Tools to make sure that the two different graphs stay alined.
> * UI to visualize the two different graphs, and to report conflicts
> * Documentation

We are informally and without tools abiding by the ticket-DAG. If it
wasn't for the stupid git-behaviour of throwing-away-single-commits-info
when you do commit-squasing, I would suggest squashing all commits to
single tickets upon merging. That would make the history and git-blame
work much nicer.

I would only wish for best-effort tools that would

  * work as expected in the expected case.
  * possibly report on the ticket-DAG vs. git-DAG violations.

In the current discussion, the best-effort tool I'm talking about is
pretty simple (if e.g. there was a single dependency, you would just
report "git diff ")

> All that for the (at best minor, possibly questionable) advantage of 
> reviewing tickets whose base is not yet reviewed. Why don't you just review 
> tickets in order?

Of course I do this. But I also review tickets in parallel. Have you not
ever worked on a ticket that depended on another ticket not yet merged?!

> Do you want your reviews being thrown away because the base changed?

Of course!

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> Changing the branch on A doesn't change the branch on B. 
>
> E.g. assume A, B started on the develop branch. Then commit on A, merge A 
> in B, commit on B. 
>
> Now A contains one commits, and B contains two commits.
>
> Then reset A back to develop. B still contains two commits.

Yes, that's the way Git works. But should it really be the way our
ticket system should work?

If A is reset back to develop, the changes there were thrown away for
some reason. So the same change-set should be somehow flagged as invalid
in B.

> Reviewing B always means that two commits are being merged, regardless of 
> the current state of A. You can only ever review B-A once A is irrevocably 
> frozen, that is, merged into develop.

If B depends on A, so I have merged A into B, and A then changes in any way,
then B should not be allowed positive review before those changes are
brought into B as well.

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> No, because dependencies are not static. You can e.g. delete the branch 
> from a dependency after the dependent ticket has been reviewed...

I don't think I understand what you mean. If that happens, then surely
some action should be taken on the dependent ticket?

Say #B is dependent on #A. If #A changes so #B no longer applies on top
of #A, then #B should be flagged with "merge problems". The dependency
might not be static, but if it changes in ways that break #B, such as
being deleted, then that's a problem with #B.

I don't see why we the diff couldn't give me the actual information I
want (the diff of #B itself) in all the usual cases, and in the rare
case that some dependency changes in weird ways, flag #B as broken.

Best,
Johan

-- 
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: trac "diff" button

[Johan S . H . Rosenkilde]

> Though really you want to know "what would be added if the ticket were 
> merged right now" which is, in general, not a single git query (for 
> starters merge can fail but git can diff anything). This is what clicking 
> on the branch in trac does.

This shows the diff of the current ticket + plus all its dependencies.
It would be really useful if the dependencies were filtered out as well.

Best,
Johan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] fplll 5.0 in sage

[Johan S . H . Rosenkilde]

Sounds pretty great!

> [X] Yes
> [ ] No
> [ ] Maybe

Best,
Johan

-- 
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] behavior of (multivariate) polynomial division

[Johan S . H . Rosenkilde]

Hi,

>   1- is it desirable for quo_remo and _floordiv_ to be equivalent for 
> all of R1, R2, R3 and R4?
>   2- what is the most reasonable behavior?

I wouldn't expect those rings to behave the same. Defining the
multivariate ring in steps indirectly gives a position-over-term
ordering in the quo_rem operations.

For instance, the following behaviour, currently in Sage, is exactly as
I would expect:

sage: A1 = QQ['a']['b']
sage: a = A1.base_ring().gen(); b = A1.gen()
sage: ( (a+1)*b ).quo_rem(a*b)

...
ArithmeticError: Division non exact (consider coercing to polynomials over the 
fraction field)

sage: ( (a+1)*b ).quo_rem(a)
...
ArithmeticError: Division non exact (consider coercing to polynomials over the 
fraction field)

sage: A2 = QQ['a','b']
sage: A2( (a+1) * b ).quo_rem(A2(a*b))
(1, b)
sage: A2( (a+1) * b ).quo_rem(A2(a))
(b, b)
sage: B1 = QQ('a')['b']
sage: B1( (a+1)*b ).quo_rem(B1(a*b))
((a+1)/a, 0)



>   3- Are there operations where it is desirable to go to R1 instead?

When you're really considering univariate polynomials in one variable
'c' over whatever ring:

sage: R1 = QQ['a']['b']['c']
sage: R4 = QQ['a','b','c']
sage: c = R1.gen()
sage: # Make a big element of R1
sage: R11 = R1.base_ring()
sage: R111 = R11.base_ring()
sage: p1 = R1([ R11([ R111.random_element(degree=50) for i in range(50) ]) for 
j in range(50) ])
sage: %timeit p1(c=1)
sage: 
sage: p4 = R4(str(p1))
sage: c4 = R4(c)
sage: %timeit p4(c=1)


Best,
Johan

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

Hi,

Sorry for not getting pack to this thread before. I'm still having this
issue that newly compiled Sage is missing many packages.

Overnight I did `make distclean && make --trace --debug=bvjm` on Sage
7.3.beta7 with #20926 applied (gcc6.1 C++ workarounds). I had downgraded
my Make to version 4.1.

The result is the same: Building the docs crashed due to uninstalled
jmol. Other packages are also missing: palp, sympy,
database_cremona_ellcurve, etc.

The missing packages are listed in the beginning of the build:

Makefile:24: update target 'build/make/Makefile' due to: 

They are also mentioned a few pages below:

...
checking for sqrt in -lm... yes
checking multiprecision library... MPIR
checking BLAS library... atlas
checking package versions... 
4ti2-1.6.7
alabaster-0.7.8
... 


However, none of the not-installed packages are mentioned again in the
logs! Those that are installed are of course in the log, a few examples:

...
[arb-2.8.1.p0] Finished installing arb-2.8.1.p0.spkg
Successfully remade target file 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/arb-2.8.1.p0'.
File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/atlas-3.10.2.p2'
 does not exist.
File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/python2-2.7.10.p2'
 does not exist.
File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/readline-6.3.008'
 does not exist.
File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/ncurses-5.9.20131221'
 does not exist.
Must remake target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/ncurses-5.9.20131221'.
Makefile:2142: target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/ncurses-5.9.20131221'
 does not exist
sage-logger -p 'sage-spkg ncurses-5.9.20131221' 
'/home/jsrn/mat/sage_coding_project/logs/pkgs/ncurses-5.9.20131221.log'
...
[ipython_genutils-0.1.0] Finished installing ipython_genutils-0.1.0.spkg
Successfully remade target file 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/ipython_genutils-0.1.0'.
File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/decorator-4.0.6'
 does not exist.
Must remake target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/decorator-4.0.6'.
Makefile:1436: update target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/decorator-4.0.6'
 due to: 
/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/setuptools-21.0.0
sage-logger -p 'sage-spkg decorator-4.0.6' 
'/home/jsrn/mat/sage_coding_project/logs/pkgs/decorator-4.0.6.log'
[decorator-4.0.6] Found local metadata for decorator-4.0.6
...
[sphinx-1.4.1.p1] Finished installing sphinx-1.4.1.p1.spkg
Successfully remade target file 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/sphinx-1.4.1.p1'.
 File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/sagenb-0.13' 
does not exist.
   File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/flask-0.10.1' 
does not exist.
 File 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/werkzeug-0.11.9'
 does not exist.
Must remake target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/werkzeug-0.11.9'.
Makefile:2804: update target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/werkzeug-0.11.9'
 due to: 
/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/python2-2.7.10.p2
sage-logger -p 'sage-spkg werkzeug-0.11.9' 
'/home/jsrn/mat/sage_coding_project/logs/pkgs/werkzeug-0.11.9.log'
...
Makefile:2828: target 
'/home/jsrn/mat/sage_coding_project/local/var/lib/sage/installed/zlib-1.2.8.p0' 
does not exist
sage-logger -p 'sage-spkg zlib-1.2.8.p0' 
'/home/jsrn/mat/sage_coding_project/logs/pkgs/zlib-1.2.8.p0.log'



It looks to me like some explicit dependencies to the not-installed
packages, as has been discussed with Jmol recently, must have been
removed or altered, and that's why Make is not picking up those targets.

Any thoughts?

Best,
Johan




leif writes:

> Johan S. H. Rosenkilde wrote:
>>> Except for the Sage library (and probably docbuilding, not sure), yes.
>>> If you explicitly use 'make -j1', then also the Sage library will be
>>> built sequentially, still using Python's multi-processing though, as
>>> does docbuilding.
>> 
>> I've done `make distclean && make -j1`. Let's see how that one goes...
>
> If that still omitted standard packages, I'd suggest to experiment with
> GNU make's debug options (you can also add '-n' aka '--dry-run').
>
> '-d' (='--debug=a') is far too verbose, but e.g. '--debug=bvjm',
> probably also with '--trac

Re: [sage-devel] Doc does not compile before jmol package

[Johan S . H . Rosenkilde]

Hi Jori,

Are you missing other standard spkgs? Such as database_cremona_ellcurve,
palp, sympy?

I never resolved my problem regarding missing packages: 
https://groups.google.com/forum/#!searchin/sage-devel/johan|sort:date/sage-devel/WERLdTKfAho/OoKt3Z2YBgAJ

Best,
Johan


Jori Mäntysalo writes:

> From-scratch devel version, i.e. the one got by git clone & checkout 
> develop & pull does not fully compile. It stops at
>
> [dochtml] [geometry ] File "sage/plot/plot3d/base.pyx", line 269, in 
> sage.plot.plot3d.base.Graphics3d._rich_repr_jmol 
> (/home/jm58660/sage/src/build/cythonized/sage/plot/plot3d/base.c:6520)
> [dochtml] [geometry ] jdata.export_image(targetfile=preview_png, 
> datafile=script,
> [dochtml] [geometry ] File 
> "/home/jm58660/sage/local/lib/python2.7/site-packages/sage/interfaces/jmoldata.py",
>  line 181, in export_image
> [dochtml] [geometry ] raise RuntimeError("Jmol failed to create file %s, see 
> %s for details"%(repr(targetfile), repr(scratchout)))
> [dochtml] [geometry ] RuntimeError: Jmol failed to create file 
> '/home/jm58660/.sage/temp/j-op7010/14652/dir_cThIMM/preview.png', see 
> '/home/jm58660/.sage/temp/j-op7010/14652/tmp_NDOxBA.txt' for details
>
> where /home/jm58660/.sage/temp/j-op7010/14652/tmp_NDOxBA.txt contains
>
> Error: Unable to access jarfile 
> /home/jm58660/sage/local/share/jmol/JmolData.jar
>
> After ./sage -i jmol I was able to compile documentation. I guess this 
> should be flagged as a bug. Anyways, I don't open ticket as this might be 
> something in my setup.


-- 

-- 
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: classifying trac tickets as silently incorrect results

[Johan S . H . Rosenkilde]

> well, we already have this: https://trac.sagemath.org/report/79
> IMHO it's a great idea to have all such places explicitly marked.

+1. I think it's great to have such a list which contains both the ones
for which we wish to add a stopgap, as well as those we don't/haven't
yet.

If the stopgap field should be used for something else, we should make a
keyword and make an "official" page with the trac search for open
tickets with that keyword.

Best,
Johan

-- 
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: Errors in an old, massive patch for Skew Polynomials in Sage

[Johan S . H . Rosenkilde]

Hi Arpit,

Did you try doctesting other parts of Sage to see whether your
segfaults are related to the ticket or not? It could be related to your
system setup.

If this is not the case, you should, as Travis asked you on an earlier
question, try to find a minimal example which causes the bug from the
Sage shell.

The the signalling behaviour of Cython code changed quite a lot during
the last few years, with ao. cysignals becoming a stand-alone package.
Perhaps the skew polynomial ticket doesn't use sig_on and sig_off
correctly.

Best,
Johan

Arpit Merchant writes:

> Hello,
>
> My apologies for not being able to get back sooner. I was working on a 
> separate ticket this week. And there were some compile errors after Sage 
> upgraded to 7.3beta6. I've fixed those and pushed the changes. Sage now 
> builds and running Sage allows access to the functionalities in the 
> original patch that were already working/fixed. However, before I can move 
> on to fixing the pending ones from last week, I am suddenly getting weird 
> segfault errors while running doctests. i.e. when I do ``./sage -t 
> src/sage/rings/polynomial/skew_polynomial_element.pyx``, I get the 
> following output. What changed in the latest update that has caused this 
> and how can I fix it?
>
> too few successful tests, not using stored timings
>> Running doctests with ID 2016-07-07-14-07-44-39349bdf.
>> Git branch: fix_skew_polynomials_patch
>> Using --optional=mpir,python2,sage
>> Doctesting 1 file.
>> sage -t src/sage/rings/polynomial/skew_polynomial_element.pyx
>> **
>> File "src/sage/rings/polynomial/skew_polynomial_element.pyx", line 100, in 
>> sage.rings.polynomial.skew_polynomial_element
>> Failed example:
>> q,r = c.quo_rem(b,side=Left)
>> Expected:
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> Got:
>> 
>> Traceback (most recent call last):
>>   File 
>> "/home/arpit/Documents/GSOC_16/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>>  
>> line 498, in _run
>> self.compile_and_execute(example, compiler, test.globs)
>>   File 
>> "/home/arpit/Documents/GSOC_16/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py",
>>  
>> line 861, in compile_and_execute
>> exec(compiled, globs)
>>   File "", 
>> line 1, in 
>> q,r = c.quo_rem(b,side=Left)
>>   File "sage/rings/polynomial/skew_polynomial_element.pyx", line 1232, 
>> in sage.rings.polynomial.skew_polynomial_element.SkewPolynomial.quo_rem 
>> (/home/arpit/Documents/GSOC_16/sage/src/build/cythonized/sage/rings/polynomial/skew_polynomial_element.c:11397)
>> return self.lquo_rem(other)
>>   File "sage/rings/polynomial/skew_polynomial_element.pyx", line 1092, 
>> in sage.rings.polynomial.skew_polynomial_element.SkewPolynomial.lquo_rem 
>> (/home/arpit/Documents/GSOC_16/sage/src/build/cythonized/sage/rings/polynomial/skew_polynomial_element.c:10375)
>> c = parent.twist_map(-db)(inv*a[i+db])
>>   File 
>> "/home/arpit/Documents/GSOC_16/sage/local/lib/python2.7/site-packages/sage/rings/polynomial/skew_polynomial_ring.py",
>>  
>> line 607, in twist_map
>> map = self._map**n
>>   File "sage/categories/map.pyx", line 1264, in 
>> sage.categories.map.Map.__pow__ 
>> (/home/arpit/Documents/GSOC_16/sage/src/build/cythonized/sage/categories/map.c:9103)
>> return generic_power(self, n)
>>   File "sage/structure/element.pyx", line 3496, in 
>> sage.structure.element.generic_power 
>> (/home/arpit/Documents/GSOC_16/sage/src/build/cythonized/sage/structure/element.c:27116)
>> return generic_power_c(a,n,one)
>>   File "sage/structure/element.pyx", line 3529, in 
>> sage.structure.element.generic_power_c 
>> (/home/arpit/Documents/GSOC_16/sage/src/build/cythonized/sage/structure/element.c:27789)
>> a = ~a
>> TypeError: bad operand type for unary ~: 
>> 'sage.rings.morphism.RingHomomorphism_im_gens'
>> Killed due to segmentation fault
>> **
>> Tests run before process (pid=13179) failed:
>> sage: R. = ZZ[] ## line 19 ##
>> sage: sigma = R.hom([t+1]) ## line 20 ##
>> sage: S. = R['x',sigma]; S ## line 21 ##
>> Skew Polynomial Ring in x over Univariate Polynomial Ring in t over 
>> Integer Ring twisted by t |--> t + 1
>> sage: a = t + x + 1; a ## line 26 ##
>> x + t + 1
>> sage: b = S([t^2,t+1,1]); b ## line 28 ##
>> x^2 + (t + 1)*x + t^2
>> sage: c = S.random_element(degree=3,monic=True); c ## line 30 ##
>> x^3 + (-95*t^2 + t + 2)*x^2 + (-t^2 + t)*x + 2*t - 8
>> sage: a + b ## line 35 ##
>> x^2 + (t + 2)*x + t^2 + t + 1
>> sage: a - b ## line 37 ##
>> -x^2 - t*x - t^2 + t + 1
>> sage: a * b ## line 40 ##
>> x^3 + (2*t + 3)*x^2 + (2*t^2 + 4*t + 2)*x + t^3 + t^2
>> sage: b * a ## line 42 ##
>> x^3 + (2*t + 4)*x^2 + (2*t^2 + 3*t + 2)*x + t^3 + t^2
>> sage: a * b == b * a ## line 44 ##
>> 

Re: [sage-devel] Method trait_names removed from units??

[Johan S . H . Rosenkilde]

Hi Stan,

It seems that trait_names() was originally added as part of a mechanism
for giving tab-completion to certain objects in IPython and the
Notebook, and this mechanism changed. Hence what used to be
trait_names() is now called _tab_completion() -- at least
units.energy._tab_completion() does exactly what
units.energy.trait_names() used to do, after #20410. You should be able
to change your existing code to use that instead.

But since trait_names() was a public API method, there should have
definitely been added a deprecation warning in #20410 instead of just
simply removing trait_names. Also, it seems the function is useful from
some user-perspectives, such as your own, so perhaps there should be a
publicly accessible version of _tab_completion() as well?

Best,
Johan


Stan writes:

> Dear all,
>
> After upgrading to 7.2, I found out that things such as 
> units.energy.trait_names() do not work any more. I used this extensively to 
> loop through the different unit names and create variable names out of 
> them. Why was this removed, and is there another way of doing this? I want 
> to be able to write e.g. 'joule' instead of 'units.energy.joule'. I found a 
> couple of tickets that may have led to the removal of trait_names for units 
> (see below), but I don't understand why, and how I can make my old 
> worksheets compatible with sage 7.2!
>
> https://trac.sagemath.org/ticket/20410
> https://trac.sagemath.org/ticket/19951
>
> Thanks already for your help. 
>
> Cheers
> Stan


-- 

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

Hi,

I just noticed, in the very beginning when doing "make" after distclean,
the build process prints a list of packages:

checking package versions... 
4ti2-1.6.7
alabaster-0.7.8
arb-2.8.1.p0
...

This list *does* contain the uninstalled packages:

database_cremona_ellcurve-20160211
jmol-14.2.11_2015.01.20
palp-2.1.p1
sympy-1.0.p0
...


This list is not piped out to install.log.

Best,
Johan

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

> Except for the Sage library (and probably docbuilding, not sure), yes.
> If you explicitly use 'make -j1', then also the Sage library will be
> built sequentially, still using Python's multi-processing though, as
> does docbuilding.

I've done `make distclean && make -j1`. Let's see how that one goes...

> Forgot to ask:
>
> How does at all local/var/lib/sage/installed/ look like?

See below. It doesn't contain the packages I know are missing. I don't
know if other packages are also missing.

alabaster-0.7.8
arb-2.8.1.p0
atlas-3.10.2.p2
babel-2.3.4
backports_abc-0.4
backports_shutil_get_terminal_size-1.0.0.p0
backports_ssl_match_hostname-3.5.0.1
boost_cropped-1.58.0
brial-0.8.4.3
bzip2-1.0.6-20150304
cephes-2.8.p1
certifi-2016.2.28
cliquer-1.21.p3
conway_polynomials-0.4.p0
cycler-0.10.0
cysignals-1.1.1
cython-0.24.p0
dateutil-2.2
decorator-4.0.6
docutils-0.12
ecl-16.1.2.p0
eclib-20150827
ecm-6.4.4
fflas_ffpack-1.6.0.p2
flask-0.10.1
flask_autoindex-0.6
flask_babel-0.9
flask_oldsessions-0.10
flask_openid-1.2.5
flask_silk-0.2
flint-2.5.2.p0
freetype-2.6.3
future-0.15.2
gap-4.8.3
gc-7.2f.p0
gf2x-1.1.p1
givaro-3.7.1
glpk-4.55.p1
gsl-2.1
iconv-1.14
imagesize-0.7.1
iml-1.0.4p1.p1
ipykernel-4.3.1
ipython-4.2.0
ipython_genutils-0.1.0
itsdangerous-0.24
jinja2-2.8
jupyter_client-4.2.2
jupyter_core-4.1.0
lcalc-1.23.p14
libfplll-20160331
libgap-4.8.3
libgd-2.1.1.1.p0
libpng-1.2.51.p0
linbox-1.3.2.p1
lrcalc-1.2.p0
m4ri-20140914
m4rie-20150908
markupsafe-0.23
mathjax-2.5
matplotlib-1.5.1
maxima-5.35.1.p2
mpc-1.0.3.p0
mpfi-1.5.1
mpfr-3.1.4
mpir-2.7.2
mpmath-0.19
ncurses-5.9.20131221
networkx-1.11
ntl-9.8.1.p0
numpy-1.11.0.p0
pari-2.8-2771-gb70b447.p0
pari_galdata-20080411
pari_seadata_small-20090618
patch-2.7.5
pathlib2-2.1.0
pathpy-7.1
pexpect-4.0.1.p1
pickleshare-0.7.2
pillow-3.2.0
pip-8.1.2
pkgconf-0.9.7
pkgconfig-1.1.0
planarity-2.2.0
ppl-1.1
ptyprocess-0.5.1
pygments-2.1.3
pynac-0.6.7
pyparsing-2.1.4
python2-2.7.10.p2
python_openid-2.2.5
pytz-2016.4
pyzmq-15.2.0
ratpoints-2.1.3.p3
readline-6.3.008
rw-0.7
sagenb-0.13
scipy-0.17.1
setuptools-21.0.0
setuptools_scm-1.11.0
simplegeneric-0.8.1
singledispatch-3.4.0.3
singular-3.1.7p1.p1
six-1.10.0
snowballstemmer-1.2.1
speaklater-1.3
sphinx-1.4.1.p1
sqlite-autoconf-313
symmetrica-2.0.p9
tachyon-0.98.9.p5
tornado-4.3
traitlets-4.2.1
twisted-16.2.0
werkzeug-0.11.9
zeromq-4.0.5
zlib-1.2.8.p0
zn_poly-0.9.p11
zope_interface-4.1.3


Best,
Johan


leif writes:

> Johan S. H. Rosenkilde wrote:
>>> $ make --version
>> GNU Make 4.2.1
>> Built for x86_64-pc-linux-gnu
>> 
>>> Did you build in parallel, and if so, does probably building
>>> sequentially fix the problem (such that the missing packages then get
>>> built)?
>> 
>> I just did "make"; the default is still sequential build, right? I have
>> no suspect environment variables.
>
> Except for the Sage library (and probably docbuilding, not sure), yes.
> If you explicitly use 'make -j1', then also the Sage library will be
> built sequentially, still using Python's multi-processing though, as
> does docbuilding.
>
>
> Forgot to ask:
>
> How does at all local/var/lib/sage/installed/ look like?
>
>
> -leif


-- 

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

> $ make --version
GNU Make 4.2.1
Built for x86_64-pc-linux-gnu

> Did you build in parallel, and if so, does probably building
> sequentially fix the problem (such that the missing packages then get
> built)?

I just did "make"; the default is still sequential build, right? I have
no suspect environment variables.

Best,
Johan

-- 
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: sage fails to build on (fresh install of) debian linux 8.4 (64 bit)...

[Johan S . H . Rosenkilde]

Are you having the same problem as me:

https://groups.google.com/forum/#!topic/sage-devel/WERLdTKfAho

For instance, do you have sympy installed? (if you don't, "./sage -t
src/sage/arith.py" will fail immediately due to uninstalled sympy).

Do you have Cremona's mini-database installed? Test by running 

   sage: db = CremonaDatabase()
   
   ValueError: Desired database (='cremona mini') does not exist

I'm missing many other vital packages on a fresh install, for some
reason, including Jmol.

Best,
Johan
 


Joseph Hundley writes:

> Installing on yet another computer today.  Same basic deal: everything 
> builds except dochtml. This time I did check the logs before running ./sage 
> -i jmol, and can confirm that no file with a name of the form 
> $SAGE_ROOT/logs/pkgs/jmol-*.log  
> was written on the initial build.
>
> On Sunday, June 26, 2016 at 3:05:36 PM UTC-4, Joseph Hundley wrote:
>>
>> Ah. Then I think we can say with reasonable certainty that there was 
>> nothing in  
>> $SAGE_ROOT/logs/pkgs/jmol-*.log  
>> before today, because when I looked the first time today, there was only 
>>
>>
>> Found local metadata for jmol-14.2.11_2015.01.20
>>
>> Attempting to download package jmol-14.2.11_2015.01.20.tar.bz2 from mirrors
>>
>> Downloading the Sage mirror list
>>
>> Searching fastest mirror
>>
>>   227ms: http://echidna.maths.usyd.edu.au/sage/
>>
>>  
>>
>>   178ms: http://www.mirrorservice.org/sites/www.sagemath.org/
>>
>> Fastest mirror: http://ftp.ntua.gr/pub/sagemath/
>>
>>
>> http://ftp.ntua.gr/pub/sagemath/spkg/upstream/jmol/jmol-14.2.11_2015.01.20.tar.$
>>
>> [
>>
>>
>> On Sunday, June 26, 2016 at 2:13:53 PM UTC-4, leif wrote:
>>>
>>> Joseph Hundley wrote: 
>>> > Running ./sage -i jmol fixes the problem of "point3d((0,0,0))" 
>>> producing 
>>> > a message about a Jmol viewer being launched but no actual Jmol 
>>> > viewer.  And fixing jmol fixes the problem with building dochtml. 
>>> > 
>>> > Thanks! 
>>> > 
>>> > I went to check $SAGE_ROOT/logs/pkgs/jmol-*.log  after issuing the 
>>> > ./sage -i jmol command, unfortunately. So, all I found there was the 
>>> log 
>>> > file being written 
>>> > at that time. 
>>>
>>> Sage doesn't overwrite existing logs, so the log should contain the 
>>> output from both attempts. 
>>>
>>>
>>> -leif 
>>>
>>> > Interestingly enough, my first run of "make" on my other machine 
>>> > (running elementary OS) produced a nearly identical dochtml problem. I 
>>> > presumed I'd have to fix jmol on that one too. But A second run of 
>>> > "make" just now failed to replicated the problem and Jmol works over 
>>> there. 
>>> > 
>>> > Sorry for not better documenting the bug. 
>>> > 
>>> > Best, 
>>> > 
>>> > JH 
>>> > 
>>> > On Sunday, June 26, 2016 at 3:30:09 AM UTC-4, Dima Pasechnik wrote: 
>>> > 
>>> > 
>>> > 
>>> > On Sunday, June 26, 2016 at 8:21:16 AM UTC+1, Dima Pasechnik wrote: 
>>> > 
>>> > 
>>> > 
>>> > On Sunday, June 26, 2016 at 2:48:26 AM UTC+1, Joseph Hundley 
>>> wrote: 
>>> > 
>>> > Was this ever resolved? 
>>> > I seem to be having the same problem trying to build on 
>>> both 
>>> > a Mac and a recent install of elementary OS.   
>>> > 
>>> > Certainly there is recent Java on this machine. Other Java 
>>> > programs run fine. 
>>> > 
>>> > The error message appears to say that sage (or Jmol called 
>>> > by sage?) is looking for JmolData.jar in 
>>> > local/share/jmol/. 
>>> > 
>>> > 
>>> > local/share/jmol/ is meant to be $SAGE_ROOT/local/share/jmol/ 
>>> > and these files are meant to be installed there during Sage 
>>> > installation. 
>>> > 
>>> > What do you see in 
>>> > $SAGE_ROOT/logs/pkgs/jmol-14.2.11_2015.01.20.log ? 
>>> > (or perhaps in $SAGE_ROOT/logs/pkgs/jmol-.log) 
>>> > 
>>> > 
>>> >   
>>> > 
>>> > I decided to try downloading Jmol 
>>> > from 
>>> https://sourceforge.net/projects/jmol/?source=typ_redirect 
>>> >  
>>>
>>> > One of the files is indeed JmolData.jar. Instead of moving 
>>> > just that file into a directory called /local/share/jmol 
>>> > what I did is move/rename the whole folder it is in into 
>>> > local/share/jmol. This had an interesting effect. 
>>> > The first time I tried point3d((0,0,0)) in sage after 
>>> making 
>>> > these changes I got a new, pretty long error message 
>>> > which I regrettably neglected to save. The second time 
>>> > (different Sage session) I got "Launched jmol viewer 
>>> > for Graphics3d Object." 
>>> > 
>>> > 
>>> > anyhow, you should reinstall jmol package, by doing 
>>> > ./sage -i jmol 
>>> > (or ./sage -f jmol) 
>>> > 
>>> >   
>>> > 
>>> > 
>>> > 
>>> > Best, 
>>> >   

Re: [sage-devel] Re: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

Hi leif,

> Well, it's apparently just that your toolchain isn't using binutils
> consistently; usually LLVM's tools get installed as 'llvm-ar' and
> 'llvm-ranlib', or they don't get installed into the default PATH.

I don't have llvm-ar or llvm-ranlib installed AFAIK (they're in the
package llvm which I don't have. I have llvm-libs, lib32-llvm-libs and
clang, though. Also locate shows up nothing.).

> You may try to reinstall binutils or create appropriate symlinks along
> PATH (such that 'ar' and 'ranlib' originate from them), but I have no
> idea whether that's at all related to your main problem.

"pacman -Qo `which ar`" tells me binutils already owns the main ar (and
ranlib).

> P.S.:  Downgrading GCC of course (in this case at least) also downgrades
> libstdc++ (to 6.0.21), so programs and libraries built against the newer
> one are borked.  If the newer libstdc++ didn't get removed, it's
> probably just a matter of symlinking libstdc++.so.6 back to the more
> recent one, presumably libstdc++.so.6.0.22 (from GCC 6.1).

Oh yeah, that probably explains why llvm expects a GLIBCXX which is not
in my current /usr/lib/libstdc++.so.6. I've downgraded llvm and trying a
"make distclean && make" again.

Best,
Johan

-- 
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: Deprecation warnings are no longer printed?!

[Johan S . H . Rosenkilde]

Hi,

> sage:   sage: f1(x) = -1
> sage:   sage: f2(x) = 2
> sage:   sage: f = Piecewise([[(0,pi/2),f1],[(pi/2,pi),f2]])
> /home/novoselt/sage/src/bin/sage-ipython:1: DeprecationWarning: use 
> lower-case piecewise instead
> See http://trac.sagemath.org/14801 for details.
>   #!/usr/bin/env python

Indeed that also works for me, and many other deprecation warnings. I
should have tried that yesterday.

I should explain that I'm working on a deprecation warning for the
Matrix.I property. I'm baffled because the warning that I added seems to
print sometimes and not other times. Consider for instance, the
following code run in the Sage shell, after applying #20904:

sage: identity_matrix(ZZ, 2).I


sage: def a():
sage: return identity_matrix(ZZ, 2).I
sage: a()


This is the behaviour in the Sage shell and in Jupyter, while the Sage
notebook prints a warning both times!

I tried writing a small class with a property and deprecating that, but
that works correctly for whatever reason. So I don't know if it could
have anything to do with the matrix class being Cython or some other
feature of it...

Any work-around would be appreciated.

Best,
Johan

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

>> ar: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required 
>> by /usr/lib/libLLVM-3.8.so) 
>
>
> Are you using llvm? As far as I know that doesnt' work, though I haven't 
> tried it myself. 

I was baffled about that too. I haven't consciously done anything that
would use llvm. I'm using a fully updated Arch linux, but with gcc
rolled back to 5.3. Then I just cloned the git repo and did 'make'. I
don't seem have any environment variables pointing to llvm either.

Best,
Johan

-- 
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: spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

> sounds like the first "make" failed...

That's not clear to me. The compile of Sage itself seemed to work but
then make failed during doc-building. This has happened so often during
the years I've worked with Sage, however, that I've learned to ignore
it. Inspecting the error now, I see that this time it has to do with the
missing jmol-package.

Inspecting install.log, I it seems that everything before seems to have
compiled. jmol, sympy, etc. are never mentioned once in the install.log.

A disturbing thing though is that the following line appears a lot:

ar: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by 
/usr/lib/libLLVM-3.8.so)

as well as:

ranlib: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required 
by /usr/lib/libLLVM-3.8.so)

However, the packages being compiled report that everything went alright
afterwards. I don't know what the errors mean. I have the Arch linux package
gcc-libs 5.3.0-5 installed.

The install.log is huge and I don't know what might be relevant. I've
put the whole thing here:

http://atuin.dk/install.log.zip

Best,
Johan

-- 
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] spkgs assumed for doctesting but not default installed

[Johan S . H . Rosenkilde]

Hi sage-devel

Today I made a fresh clone of the develop branch, ran "make", and then
tried to run "./sage -t". To my surprise, this didn't work at all!

First off, the doctest framework wouldn't even run, since sympy wasn't
installed. After doing "./sage -pip install sympy", I could now actually
perform doctests.

But I then get thousands of failures all around Sage's library, due to
other uninstalled spkgs: jmol, palp, Cremona's mini database, and
others.

Am I doing something wrong? Or do we currently have a problem with
default spkgs not being installed as they should?

Best,
Johan

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