[sage-devel] Re: `ModuleElement` is forced though `Element` should be enough by the category framework

[Kwankyu Lee]

>
>
> In particular, Jeroen, concerning the strange rule that _lmul_ not being 
> implemented means that it returns None: I seem to recall (but I am not 
> 100% sure) that P._get_action_(Q) (or some other method name, I don't 
> recall) could test what happens if P.zero()._lmul_(Q.zero()) or similar 
> things are doing, and depending on the result would conclude that an 
> action does not exist or does exist, for general elements of P and Q. 
>

You seem to refer to this part of the code of `detect_element_action(...)`: 

cdef Element x
if X_el is None or (parent(X_el) is not X):
x = an_element(X)
else:
x = X_el
if x is None:
raise RuntimeError("an_element() for %s returned None" % X)
if Y_el is None or (parent(Y_el) is not Y):
y = an_element(Y)
else:
y = Y_el
if y is None:
if isinstance(Y, Parent):
raise RuntimeError("an_element() for %s returned None" % Y)
else:
return # don't know how to make elements of this type...
if isinstance(x, ModuleElement) and isinstance(y, Element):
# Elements defining _lmul_ and _rmul_
try:
return (RightModuleAction if X_on_left else LeftModuleAction)(Y, 
X, y, x)
except CoercionException as msg:
_record_exception()   


>

-- 
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: .an_element() != 0?

[Kwankyu Lee]

On Wednesday, February 27, 2019 at 11:25:38 PM UTC+9, Daniel Krenn wrote:
>
> Can I savely assume that S.an_element() of something S (within SageMath) 
> returns an element different from S.zero() if possible (meaning if there 
> are nonzero elements in S)? 
>

The purpose of S.an_element() is to get an element whose parent is S -- 
zero is completely legitimate.  

-- 
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] Right idiom to define a map

[Kwankyu Lee]

Hi,

I thought the idiom to define a map is:

from sage.categories.map import Map
from sage.categories.homset import Hom
from sage.categories.fields import Fields

class Derivation(Map):
def __init__(self, field):
Map.__init__(self, Hom(field, field, Fields()))

But then the last two tests fail:

d = Derivation(GF(2))
d._test_category()
d._test_pickling()

What did I do wrong? Or what should I do more? 

Thank you for attention in advance.




-- 
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: Right idiom to define a map

[Kwankyu Lee]

>
>  The _test_category issue is something that shows up with every map (and I 
> think homset). This is because the parent (i.e., the homset) does not 
> (usually) have a single Element class, but the _test_category is checking 
> that the map is a subclass of the element_class that is dynamically created 
> by the category framework. The standard idiom is just to skip these tests 
> in the TestSuite() call.
>

If the issue is with every map, then a proper cure would be to fix the 
category framework itself not to test _test_category or possibly by 
dynamically creating a parent class whose element_class is the class of the 
map. The standard idiom seems a bandage...

For pickling, you probably just need to implement a __reduce__ method for 
> the map.
>

Why not the category framework provide a default? This also seems to me a 
defect of the category framework.


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

[sage-devel] Re: Right idiom to define a map

[Kwankyu Lee]

>
> What did I do wrong? Or what should I do more?

 
To pass _test_pickling, it is enough to implement __eq__ method. This is 
reasonable!

-- 
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: Right idiom to define a map

[Kwankyu Lee]

On Wednesday, March 13, 2019 at 9:04:32 PM UTC+9, Simon King wrote:
>
> PS: 
>
> On 2019-03-13, Simon King > wrote: 
> > There are of course cases in which a default pickling mechanism makes 
> > sense (think of UniqueRepresentation). However, I think that Map is 
> > not such a case. 
> > 
> > Namely, a map is given by a domain, a codomain, and defining data. There 
> > could of course be a default implementation of pickling, namely: Provide 
> > a slot for the data (the domain and codomain are referenced anyway, 
> > although some of the references are weak references). 
>
> To be clearer: I do think that a default implementation (of course not 
> in the category framework but in the base class) is *possible*. But I 
> also think that it would not be reasonable. 
>

Travis pointed out that for my case a default implementation of pickling is 
defined in the base class of Map. I agree that implementation of pickling 
is not a business of the category framework. 

_test_pickling tests if loads(dumps(obj)) == obj. It is defined for all 
sage object, and I guess any sage object is expected to pass the test. In 
my original post, the code did not implement __eq__, and hence the 
_test_pickling fails. I am perfectly fine with this. There is no problem 
here.

-- 
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: Computing determinants of obviously singular matrices

[Kwankyu Lee]

Hi,

If the determinant is obviously zero, then you don't need to run the 
computation. If a preprocessing to check zero rows or columns is added, 
then the determinant computation would become slower for usual nontrivial 
cases.


Cheers. 

On Saturday, March 16, 2019 at 2:15:06 AM UTC+9, Maximilian Jaroschek wrote:
>
> Hello, 
>
> I'm using the current developer version of sage and noticed that when 
> computing determinants of matrices over polynomial rings and rational 
> functions, cases where the determinant is easily seen to be zero due to 
> zero rows or columns can take an unreasonable long time to compute. I 
> compared the timings with the same computation over other domains.
>
> sage: L.=PolynomialRing(QQ)
> sage: MS=MatrixSpace(L,100)
> sage: time _=MS.zero().determinant()
> CPU times: user 13.4 s, sys: 19.6 ms, total: 13.5 s
> Wall time: 13.5 s
> sage: MS=MatrixSpace(L.fraction_field(),100)
> sage: time _=MS.zero().determinant()
> CPU times: user 200 ms, sys: 0 ns, total: 200 ms
> Wall time: 200 ms
> sage: MS=MatrixSpace(ZZ,100)
> sage: time _=MS.zero().determinant()
> CPU times: user 563 µs, sys: 5 µs, total: 568 µs
> Wall time: 573 µs
> sage: MS=MatrixSpace(L,40)
> sage: M=MS.random_element(3)
> sage: M=M.with_rescaled_row(0,0)
> sage: M.rows()[0]==0
> True
> sage: time _=M.determinant()
> CPU times: user 35.2 s, sys: 8.06 ms, total: 35.2 s
> Wall time: 35.2 s
> sage: MS=MatrixSpace(L.fraction_field(),10)
> sage: M=MS.random_element(3)
> sage: M=M.with_rescaled_row(0,0)
> sage: M.rows()[0]==0
> True
> sage: time _=M.determinant()
> CPU times: user 1min 56s, sys: 300 ms, total: 1min 56s
> Wall time: 1min 56s
> sage: MS=MatrixSpace(ZZ,500)
> sage: M=MS.random_element(2^40)
> sage: M=M.with_rescaled_row(0,0)
> sage: M.rows()[0]==0
> True
> sage: time _=M.determinant()
> CPU times: user 67.6 ms, sys: 0 ns, total: 67.6 ms
> Wall time: 67.9 ms
> sage: 
>
> Probably a preprocessing step could help that looks for zero rows or 
> columns before running the actual algorithm.
>
>
> Best,
> Maximilian
>

-- 
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: [sage-cell] Re: Is sagecell python3-ready?

[Kwankyu Lee]

On Friday, March 22, 2019 at 12:56:58 AM UTC+9, Andrey Novoseltsev wrote:
>
> "languages" for SageMathCell are very different from kernels for Jupyter. 
> SageMathCell keeps a bunch of preforked kernels (all are the same)
>

And a new kernel is created for each interact cell. Right? This seems to me 
a very bad architectural weakness of SageMathCell.  

-- 
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: [sage-cell] Re: Is sagecell python3-ready?

[Kwankyu Lee]

>
> On Friday, March 22, 2019 at 12:56:58 AM UTC+9, Andrey Novoseltsev wrote:
>>>
>>> "languages" for SageMathCell are very different from kernels for 
>>> Jupyter. SageMathCell keeps a bunch of preforked kernels (all are the same)
>>>
>>
>> And a new kernel is created for each interact cell. Right? This seems to 
>> me a very bad architectural weakness of SageMathCell.  
>>
>
> Right. Feel free to fix it ;-) 
>

Someday... 
 

> Do you want to have the same process serving multiple clients 
> simultaneously? With each client allowed to execute arbitrary code, in 
> particular crashing that kernel?
>

I would expect one process runs all interact cells from one client (if this 
makes sense).   

I have a webpage that contains many interact cells that run on my own 
sagecell server. The webpage stops working if many of the interact cells go 
active. 

-- 
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: [sage-cell] Re: Is sagecell python3-ready?

[Kwankyu Lee]

On Sunday, March 24, 2019 at 4:43:47 AM UTC+9, Andrey Novoseltsev wrote:
>
> On Saturday, 23 March 2019 00:25:10 UTC-6, Kwankyu Lee wrote:
>>
>> I would expect one process runs all interact cells from one client (if 
>> this makes sense).   
>>
>> I have a webpage that contains many interact cells that run on my own 
>> sagecell server. The webpage stops working if many of the interact cells go 
>> active. 
>>
>
> How exactly multiple interacts are supposed to share resources of this 
> single process? (What happens actually if you link them together now?) And 
> what do you expect to gain? More efficient RAM usage? Note that if a single 
> interact crashes, you will crash all of them. And things like CPU time 
> limits would count cumulatively, so you may use up your allotment faster 
> (which is not necessarily a bad thing, just something to keep in mind).
>

I guess interacts in a jupyter notebook share resources in a single 
process. Right? No?  
 

> Have you determined what exactly goes wrong when your webpage stops 
> working?
>

No. First it seemed a problem of linked cells. Somehow a failure of a cell 
affected the other cells. So I tried unlinked cells. Then running many 
(actually not so many, perhaps twenty or thirty of) active cells stops all 
cells from working. If that happens, I just wait and then after some time 
all is functioning normally. I didn't investigate deep. I still don't know 
what is really happening.
 

-- 
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] Report on global function fields in Sage

[Kwankyu Lee]

Dear Sage developer community,

As of Sage 8.8.beta4, the global function field code of the ticket #22982 
has finally landed all in Sage. Following the tradition of giving a report 
when a major piece of new functionality is added to Sage, I will now 
briefly recall what we achieved and thank the people who contributed to it.

During my sabbatical year spanning from 2016 to 2017, I wrote the initial 
code for computations with global function fields. This was what I had 
wanted to do all the time since I realized Magma is not a suitable platform 
for distributing my research work in algorithmic coding theory. So I 
decided to devote the sabbatical year for the mission. I thank Maria 
Bras-Amoros for hosting me during the year and for putting up with me, as a 
side effect,  neglecting the duty of collaborating with her for 
mathematical research.   

In 2017, I created the ticket #22982 and pushed the whole code. The code 
was just sitting there for long time waiting for a reviewer, until Johan 
came up and gave advices on what I should do if I wanted the monstrously 
big code ever get reviewed. I thank Johan for the valuable advices.

Following Johan's advice, I split the code into pieces and created several 
child tickets. Then finally a little more than a year ago, Travis showed up 
and started reviewing the tickets. During this process, he gave lots of 
useful comments on the code and elevated the quality of the code 
substantially. He is a great reviewer. I thank him very much!

And now here is the global function field machinery in your Sage. What is 
to do with it?

1. It is very, but not terribly, slow compared with Magma. One may want to 
improve the speed.

2. One may want to extend the code for function fields over other fields 
than finite fields. I myself do not have a plan to do this.

3. I am writing code for computations with integral curves over finite 
fields using the global function field machinery.

4. I wrote code (this is what I dreamed of since I first heard of Sage in 
2006)  for my decoding algorithm for AG codes using the global function 
field machinery. I am supposed to give a short talk on this topic at SIAM 
2019 in July.

This is it. Thank you for your attention!


Kwankyu


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2e56fa30-007b-4750-9b89-6a666dba6377%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Report on global function fields in Sage

[Kwankyu Lee]

On Friday, May 10, 2019 at 4:04:15 PM UTC+9, Simon King wrote:
>
>
> On 2019-05-10, Kwankyu Lee > wrote: 
> > 1. It is very, but not terribly, slow compared with Magma. One may want 
> to 
> > improve the speed. 
>
> Is there a ticket for it, which also points out what examples are slow and 
> how it compares with Magma? I cannot give a promise at this point, but 
> generally I like to try and tweak code. 
>

Hi Simon, 

I meant the general performance. So any computation is slower than with 
Magma :-) For example, on my desktop,
-
sage: k. = GF(16)
sage: K. = FunctionField(k); _. = K[]
sage: L. = K.extension(Y^4 + Y - x^5)
sage: time L.genus() 
CPU times: user 1.33 s, sys: 79 ms, total: 1.41 s
Wall time: 1.35 s
6
-
versus
-
> K := FunctionField(GF(16));
> R := PolynomialRing(K);
> L := ext;
> time Genus(L);
6
Time: 0.010
-

There is no ticket. It seems bad to create a ticket before you have a 
specific goal and a means to achieve it. 

I suspect that the overall poor performance is mainly due to slow linear 
algebra over polynomial rings (over finite fields). For example, I observed 
determinant computation is generally slow and for some cases terribly slow. 
At the base, there is hermite normal form computation. Any speed increase 
in the computation would improve the overall performance of the global 
function field machinery.

One may target specific methods. Of course, I did try to optimize each 
method as much as I could. But others may come up with better idea or even 
faster algorithm.


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d00193f4-6ea0-4971-aa95-88cca5dffa39%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] A bug due to copying a cython object.

[Kwankyu Lee]

Hi,

I observed

sage: F = GF(2)
sage: E = GF(4)
sage: phi = E.coerce_map_from(F); phi
Ring morphism:
  From: Finite Field of size 2
  To:   Finite Field in z2 of size 2^2
  Defn: 1 |--> 1
sage: phi.section()
---
TypeError Traceback (most recent call last)
...
TypeError: 'NoneType' object is not callable

and on the other hand,

sage: psi = E._internal_coerce_map_from(F)
sage: psi.section()
Section of (map internal to coercion system -- copy before use)
Ring morphism:
  From: Finite Field of size 2
  To:   Finite Field in z2 of size 2^2

If you look into coerce_map_from() method, essentially phi = copy(psi), but 
while copying the cython object, the information about the section map of 
psi is lost, and thus the error above.

What is the proper way to copy a cython object with all its attributes?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c8d673a8-dabb-44bd-87f0-634ebb42b078%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] A bug due to copying a cython object.

[Kwankyu Lee]

This is now

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

which needs review.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3bfa8aeb-e6db-4188-aff5-39215107c0c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] show() method for all sage objects

[Kwankyu Lee]

Hi,

How about adding show() method to the class of sage objects, so that we can 
do

mat.transpose().show()

instead of

show(mat.transpose())

which is cumbersome to add to and remove from mat.transpose()? This is 
useful in Jupyter notebook.


Kwankyu

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8626bc01-4503-4524-95f2-fb1468d6834b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Printing a matrix of large size

[Kwankyu Lee]

Hi,

If mat is a matrix of large size, it is displayed in a short form:

sage: mat
22 x 32 dense matrix over Finite Field of size 2 (use the '.str()' method 
to see the entries)


Then if I follow the recommendation,  

sage: mat.str()
'[1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 1 1 0]\n[0 1 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1 0 0 0]\n[0 0 1 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1]\n[0 0 0 1 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0]\n[0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 1 1 0 0 1 1 0 1 0 0]\n[0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 1 1 0 1 1 0 0 1 1]\n[0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 1 1 1 1 0 0 1 0]\n[0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 
1 1 1 0 1]\n[0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 
1]\n[0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 1 0 1]\n[0 0 
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 1 1 1]\n[0 0 0 0 0 0 
0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 0 1 0]\n[0 0 0 0 0 0 0 0 0 0 
0 0 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 1 1 0 0 0]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 1 
0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 0 1 1]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 
0 0 0 0 0 0 0 1 1 1 0 1 0 0]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 
0 1 0 0 0 1 0 1 1 1]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 1 0 0 
1 1 1 1 1 1]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 1 
0 0]\n[0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 1 0 0 1]\n[0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 1 1 0 0 0 0 1]\n[0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 1 1 1 1 0]\n[0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 1 1 1 1 0 0 1]'


At this point, I feel offended. Why do we have this useless behavior for 
matrices? Why not just print the whole matrix even if it is huge? I guess 
no user prints a matrix just to know the size or the base ring. 

How about printing a matrix in the short form only if the matrix is sparse?


Kwankyu

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/303291c3-c578-448a-a4f6-d843f0cb732a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Printing a matrix of large size

[Kwankyu Lee]

On Sunday, May 19, 2019 at 1:42:02 PM UTC+9, John H Palmieri wrote:
>
> Did you try "print(mat.str())"?
>

No I didn't. Thanks for the tip.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0178dc01-e3a4-4798-8337-1630ddc0eb2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: show() method for all sage objects

[Kwankyu Lee]

On Sunday, May 19, 2019 at 5:48:23 PM UTC+9, Volker Braun wrote:
>
> If you find yourself typing show() all the time you probably want to 
> change the displayhook to typeset stuff, i.e.  you want "%display typeset" 
> in the notebook or on the command line:
>
> sage: m = random_matrix(ZZ, 3)
> sage: m
> [12 -5  6]
> [ 1 -1  1]
> [-1  2  1]
> sage: %display unicode_art
> sage: m
> ⎛12 -5  6⎞
> ⎜ 1 -1  1⎟
> ⎝-1  2  1⎠
>

I had thought of even proposing show_unicode_art() method for sage objects 
:-)
 

> In general, I would lean more on the side of reasonable defaults (e.g. why 
> is %display typeset not the default in the notebook, its easier for power 
> users to turn it off than for novices to turn it on) than a proliferation 
> of more display-related methods.
>

I would prefer the current default %display plain in the notebook though I 
am a novice in this regard.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fbc754af-a4a9-43b9-8bc3-776bf3dcce24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: show() method for all sage objects

[Kwankyu Lee]

On Sunday, May 19, 2019 at 9:50:22 PM UTC+9, Eric Gourgoulhon wrote:
>
> LaTeX is arguably the best way to display mathematics
>

I agree with this, but sage objects are not mathematics.
 

> If one would like the plain text view of an object X instead, one can use 
> print(X).
> So, in the Jupyter notebook, instead of having
>
> X.show() --> LaTeX typeset
> X  --> plain text
>
 
+1 as default.
 

> X  --> LaTeX typeset
> print(X)  --> plain text
>

-1 as default. Moreover many sage objects currently are displayed broken if 
typeset. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/64bfc494-537d-4fbb-9149-00477ba27129%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] New code for integral curves over finite fields

[Kwankyu Lee]

Hi,

I pushed the code for integral curves over finite fields to ticket #27873:

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

for those who want to experiment with it. Thank you.


Kwankyu

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3dcc648b-dc9f-43b2-bf09-e090f8de33c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Why _r_action_ and _l_action_ methods still in the reference manual?

[Kwankyu Lee]

Hi

I noticed that the coercion section of the sage reference manual mentions 
_r_action_ and _l_action methods instead of _act_on_ and _acted_upon_ 
methods, while it seems that the former methods were replaced with the 
latter methods 10 years ago in #5597!

Am I right? Then this is quite surprising.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/66a6a4c4-df4f-4cd4-9856-c582719c993d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Why _r_action_ and _l_action_ methods still in the reference manual?

[Kwankyu Lee]

On Friday, June 14, 2019 at 8:16:58 PM UTC+9, Dima Pasechnik wrote:
>
> On Fri, Jun 14, 2019 at 12:04 PM Kwankyu Lee  > wrote: 
> > 
> > Hi 
> > 
> > I noticed that the coercion section of the sage reference manual 
> mentions _r_action_ and _l_action methods instead of _act_on_ and 
> _acted_upon_ methods, while it seems that the former methods were replaced 
> with the latter methods 10 years ago in #5597! 
> > 
> > Am I right? Then this is quite surprising. 
>
> quick grepping through src/sage/ shows that  _r_action_ is never 
> defined/used (only mentioned in commented out code 
> or in messages), and  _l_action is defined exactly once, in 
> src/sage/rings/multi_power_series_ring_element.py 
> and only used there, once. 
>
> So none of this is understood by any coersion/etc frameworks. 
>
> A documentation bug, I suppose (and probably a bug in 
> src/sage/rings/multi_power_series_ring_element.py, which uses 
> wrongly named stuff...) 
>

I agree.
 

> I've opened https://trac.sagemath.org/ticket/27989 to deal with it. 
>

Thank you.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ed711c48-2402-438c-aa38-c8259ef884fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] A question on pickling cached methods

[Kwankyu Lee]

Hi,

Suppose I have an object X. I computed X.genus(), which took a long time. 
The method genus() is a cached method. So it gives the result quickly next 
time. Then I saved the object X. After loading X in a new session, I want 
X.genus() to give the cached result rather than computing it again.

Is it possible to implement genus() to behave in such a way? Is there some 
option to @cached_method decorator for that purpose?

I am reading the code for cached methods, but you answer will help me. 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/933290b2-697e-4766-9f28-d0486a585107%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] A question on pickling cached methods

[Kwankyu Lee]

On Thursday, June 27, 2019 at 4:41:30 PM UTC+9, John Cremona wrote:
>
> I think this is one disadvantage of using the cached_method decorator, 
> instead of the clumsier way of actually storing the result in the object, 
> eg. by setting X._genus.  In your example I cannot think of a reason why we 
> would not want to store the genus as an attribute after computing it.
>

I thought the same. I expected the cached_method decorator could make a 
(pseudo) attribute attached to the object magically somehow if I cast the 
right spell...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3615ea68-ee95-4ce2-8a2d-434c186be948%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Kwankyu Lee]

On Thursday, June 27, 2019 at 9:45:42 PM UTC+9, Simon King wrote:
>
> Hi! 
>
> Is it a Python object? 
>

Yes.
 

> A cached method (if that hasn't changed since I last looked at the code) 
> stores the cached values in some dict stored as an attribute, and when 
> you pickle the object (at least when no __reduce__ method interferes), 
> it should automatically store that attribute. 
>
> But you say that the method is called "genus". So, probably it has not 
> function arguments, right? It could be that the cache is stored 
> differently in that case. 
>
> I think if pickling doesn't preserve the content of the cached method 
> then it is a bug. 
>

>From the code, I learned that there is "do_pickle" option. With 
"do_pickle=True", the content of the cached method is indeed preserved with 
an experimental class. I will check again with my production code.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5ac2b641-f212-42d4-b15a-061083463fcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Kwankyu Lee]

On Thursday, June 27, 2019 at 10:20:55 PM UTC+9, Volker Braun wrote:
>
> There is the do_pickle argument, e.g. from TFM:
>
> sage: class C:
> : @cached_method(do_pickle=True)
> : def __hash__(self):
> : return id(self)
>
>
> Note that it can cause the following problem: Not every circularly 
> dependent collection of cython objects can be pickled. Cached values can 
> make the difference between what can and cannot be pickled. So whether or 
> not pickling works can't reliably be tested in that case. 
>

I see. Thanks. 

I would wish "do_pickle=True" is the default. But I guess this would 
degrade the performance...

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b69edb56-9bc9-4c28-b110-ba307af98e94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Kwankyu Lee]

>
> From the code, I learned that there is "do_pickle" option. With 
> "do_pickle=True", the content of the cached method is indeed preserved with 
> an experimental class. I will check again with my production code.
>

I applied "do_pickle=True" option to F.weierstrass_points() with global 
function field F. It doesn't work. 

I think pickling should always work with objects with cached methods; 
otherwise saving objects makes little sense.

Anyway, thanks for all comments.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3ee90675-9244-4c25-8ead-5698c3cc9557%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A question on pickling cached methods

[Kwankyu Lee]

On Thursday, June 27, 2019 at 9:45:42 PM UTC+9, Simon King wrote:
>
>
> I think if pickling doesn't preserve the content of the cached method 
> then it is a bug. 
>

UniqueRepresentation objects do not preserve the content of the cached 
method with do_pickle=True.

This problem is solved in https://trac.sagemath.org/ticket/28096 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e7dc1423-609c-4007-bd7c-9b6ca1359974%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: signature missing in introspection some of the time

[Kwankyu Lee]

There is already a ticket for that:

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

but no one is working on it.

On Sunday, July 21, 2019 at 1:32:24 AM UTC+9, John H Palmieri wrote:
>
> See 
> https://ask.sagemath.org/question/47214/help-doesnt-show-function-call/. 
> Some of the time when you evaluate
>
>blah?
>
> the signature is not present. Is this a bug or is it intended?
>
> I like this behavior:
>
> sage: A = SteenrodAlgebra()
> sage: A.antipode?
> Signature:  B.antipode(self, *args)
> Call signature: B.antipode(*args)
> Type:   ModuleMorphismByLinearity_with_category
> String form:Generic endomorphism of mod 2 Steenrod algebra, milnor 
> basis
> File:   ~/Desktop/Sage_stuff/git/sage/local/lib/python2.7/site-
> packages/sage/modules/with_basis/morphism.py
> Docstring: 
>
>...
>
> but not this:
>
> sage: mat = random_matrix(ZZ, 3, 3)
> sage: mat.add_multiple_of_row?
> Docstring: 
>...
>
>
>
> -- 
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d5b7005b-8600-4620-bf67-e36ec0d48156%40googlegroups.com.

[sage-devel] Re: signature missing in introspection some of the time

[Kwankyu Lee]

Now there is a one-line patch at

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

to fix the problem.

I wish that cython experts check that out. I am concerned whether the patch 
has any unexpected side effect that I cannot foresee.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/51e9724d-e1ca-4307-b882-cf3f1c60182e%40googlegroups.com.

[sage-devel] Request for review: #28096

[Kwankyu Lee]

Hi,

The ticket at

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

makes cached methods with do_pickle=True work (get the content pickled) for 
UniqueRepresentation objects. This is not an issue at an obscure corner of 
Sage, but would affect most users when saving objects to disk.

Note that most parents in Sage are UniqueRepresentation objects. If you ran 
cached methods (coded with do_pickle=True) of a parent, then when you save 
the parent object, the computed contents of the methods would get pickled 
along with it. I guess this would be very convenient feature for most 
cases. 

Actually we should have had this already, but did not because of a bug in 
UniqueRepresentation class, which the ticket solves.

Thank you for attention.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d214ca9c-0681-4c05-a198-e1aed38812e1%40googlegroups.com.

[sage-devel] Please check unhealthy patchbots

[Kwankyu Lee]

Hi,

It seems to me that currently only two patchbots are reliably testing 
patches. One of them is "hades" that I am running temporarily. Owners of 
patchbots should check if his or her patchbot is polluting trac with wrong 
results rather than helping reviewers. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/518c3ae7-390e-4044-9e82-e1a933d30654%40googlegroups.com.

Re: [sage-devel] Resolution of singularities

[Kwankyu Lee]

>
> IIRC, singular returns the output of the resolution in a complicated way 
> (defining several rings, and some ideals inside them). Maybe it would make 
> sense to use the Sage schemes infrastructure to wrap that in a more 
> user-friendly way (although the schemes code itself could use some work 
> too).
>
>
I think this ticket

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

could be an initial step toward that direction. That is needed to develop 
sage schemes with Singular background.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f58dcacb-0561-469b-a0f4-b823a83e395e%40googlegroups.com.

[sage-devel] Re: divisor_of_function(r)

[Kwankyu Lee]

The situation will be improved after

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

for curves over finite fields.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/104d1eb0-316f-469b-b233-6acf02424b97%40googlegroups.com.

[sage-devel] Re: How to recover from total git screwup?

[Kwankyu Lee]

On Saturday, September 28, 2019 at 3:17:55 AM UTC+9, Simon King wrote:
>
> Hi! 
>
> At some point I was advised to use "git worktree" to have one py2 and 
> one py3 installation sharing the same git repository. Till one hour ago, 
> it worked fine. 
>
> Now, if I understand correctly, in my py2 worktree, I was on the develop 
> branch. There was one branch "foobar" (not its real name) that meanwhile 
> is fully merged, so that I thought it was safe to do "git branch -d 
> foobar". 
> However, it seems that my py3 worktree was on that now deleted branch. 
>
> I am not totally sure if that's what was happening. Would git really 
> allow the "git branch -d" operation when another worktree is on that 
> branch? 
>

If you were at foobar in py3 worktree and at develop in py2 worktree, no.
 

> In any case, my bash history shows that at some point I did 
> "git branch -d foobar", and when I am in the py3 worktree, I now get 
>   $ git log 
>   fatal: your current branch 'foobar' does not have any commits yet 
>
> Indeed, all files in the Sage tree are untracked, in the py3 worktree. 
> And that's why "git checkout develop" won't work (it tells me to commit 
> are stash first). 
>
> Can you please tell me how to recover from that mess? 


Why not just add a new shiny py3 worktree and move your untracked files 
from the old py3 worktree to the new one?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/502164bf-f987-487a-b649-e1355144347d%40googlegroups.com.

[sage-devel] Re: How to recover from total git screwup?

[Kwankyu Lee]

>
> However, someone who knows about git (i.e., not I) should report the bug 
> that git allows deletion of a branch that is checked out in another 
> worktree. 
>

I don't see that bug. This is what happens when I try that:  (* denotes the 
branch on the worktree I am currently on; + denotes branch checked out on 
other worktrees)

Hera:sage-dev$ g branch 
  ...  
  develop
  master
* picklable-trac28096
  ...
+ research-base
  ..
+ temp
  trace-trac9704
Hera:sage-dev$ g branch -d temp
error: Cannot delete branch 'temp' checked out at 
'/Users/kwankyu/GitHub/temp'
Hera:sage-dev$ g branch -d research-base 
error: Cannot delete branch 'research-base' checked out at 
'/Users/kwankyu/GitHub/sage'
Hera:sage-dev$ g version
git version 2.23.0 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d4c9ada2-8524-418d-8c26-995c13424a05%40googlegroups.com.

[sage-devel] Re: Can Sage compute the Groebner basis of a module?

[Kwankyu Lee]

On Friday, October 18, 2019 at 4:43:53 PM UTC+9, Mao Zeng wrote:
>
> As I understand, groebner_basis() in Sage uses Singular as a backend to 
> compute the groebner basis of ideals in polynomial rings. However, Singular 
> can also compute the groebner basis of modules. Is this functionality 
> available in Sage? Similarly, in Singular the "syz" function can compute 
> the syzygy module of either an ideal or a module, but the syzygy_module() 
> function in Sage seems to work for ideals only. I would like to use Sage 
> instead of using Singular directly. Is there an easy workaround?
>

You may be interested in this ticket

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

where computing with Singular modules via Sage is facilitated. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4a7a9c7d-229b-404f-9511-fb2d5809b01a%40googlegroups.com.

Re: [sage-devel] Re: mad patchbot?

[Kwankyu Lee]

On Saturday, December 7, 2019 at 7:21:44 PM UTC+9, Frédéric Chapoton wrote:
>
> The patchbot named "sage4" has been banned from posting its reports. It 
> will be unbanned when Jeroen tells us that he is taking care.
>

Thank God! 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/21ed1968-b113-4def-a009-f431aad77e95%40googlegroups.com.

[sage-devel] No transformation matrix returns from m.echelon_form(transformation=True)

[Kwankyu Lee]

Hi,

It surprised me to find that my expectation fails:

sage: m = matrix(GF(5), 3, [1,2,3,4,5,6,7,8,9])
sage: m
[1 2 3]
[4 0 1]
[2 3 4]
sage: m.echelon_form(transformation=True)
[1 0 4]
[0 1 2]
[0 0 0]
sage: m = matrix(QQ, 3, [1,2,3,4,5,6,7,8,9])
sage: m.echelon_form(transformation=True)
[ 1  0 -1]
[ 0  1  2]
[ 0  0  0]

No transformation matrix is returned. The docstring of echelon_form() says

   * "transformation" -- boolean. Whether to also return the
 transformation matrix. Some matrix backends do not provide this
 information, in which case this option is ignored.

So the chosen algorithm by default does not produce a transformation 
matrix! Then how can I get one?

On the other hand, I get, as expected

sage: m = matrix(GF(5), 3, [1,2,3,4,5,6,7,8,9])
sage: m
[1 2 3]
[4 0 1]
[2 3 4]
sage: m.hermite_form(transformation=True)
(
[1 2 3]  [1 0 0]
[0 2 4]  [1 1 0]
[0 0 0], [1 3 1]
)

I think the correct behavior of echelon_form(transformation=True) is to 
choose a backend algorithm that actually produce a transformation matrix 
and provide one, instead of ignoring the user's expectation. Right?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cede1732-863d-4add-a044-a18c663f66a6%40googlegroups.com.

[sage-devel] Re: No transformation matrix returns from m.echelon_form(transformation=True)

[Kwankyu Lee]

I solved the first question:

sage: me = m.extended_echelon_form()
sage: p = me.submatrix(0,3)
sage: p * m
[1 0 4]
[0 1 2]
[0 0 0]


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e2abe8b0-7c1a-4e88-be99-1413d6969579%40googlegroups.com.

Re: [sage-devel] No transformation matrix returns from m.echelon_form(transformation=True)

[Kwankyu Lee]

On Sunday, February 9, 2020 at 3:18:05 PM UTC+9, vdelecroix wrote:
>
> Le 06/02/2020 à 06:29, Kwankyu Lee a écrit : 
> > I think the correct behavior of echelon_form(transformation=True) is to 
> > choose a backend algorithm that actually produce a transformation matrix 
> > and provide one, instead of ignoring the user's expectation. Right? 
>
> I completely agree. The specification of the "transformation" keyword 
> is extremely bad. 
>
> And if a user chooses a wrong combination of "backend" and 
> "transformation" an error should be raised. 
>

This is now

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

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/764a56fd-b2cb-451b-a83c-966b40154def%40googlegroups.com.

[sage-devel] Re: Consistent naming for factory methods

[Kwankyu Lee]

On Friday, February 14, 2020 at 11:01:05 PM UTC+9, Michael Orlitzky wrote:
>
> Should it apply to *methods* that also act like constructors, even 
> though visually, something like cones.Foo() doesn't look like a 
> constructor (it looks like a method)?

 
I would think

conesas a module or a package,
cones.Foo()  as a constructor (class or factory that mimic 
class),
cones.do_something()  as a function.

Perhaps we also need an official name for things like "cones". A 
constructor group?

Can we pick one style and write it down to avoid this problem in the 
> future? 
>

+1 

FWIW, I think cones.trivial() looks better than cones.Trivial(), but for 
> no good reason. 
>

+1 to cones.trivial()

reason: there is no Trivial class or factory. 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b4bb1a64-4f5d-47c3-8d5f-1f58fbfde668%40googlegroups.com.

Re: [sage-devel] Re: Consistent naming for factory methods

[Kwankyu Lee]

On Sunday, February 16, 2020 at 10:10:11 AM UTC+9, Michael Orlitzky wrote:
>
> On 2/14/20 7:55 PM, Michael Orlitzky wrote: 
> > 
> > But... is that the distinction that we want to make? I'm skeptical that 
> > the person who wrote that paragraph in the developer's guide had the 
> > 1995 definition of "factory" in mind. I actually like this convention, 
> > but it's a bit subtle. 
> > 
>
> ...and confusing as hell to users, since it's based on an implementation 
> detail. I tried to write up a paragraph of documentation for this 
> convention and that was enough to convince me it's a bad idea. 


It would also be mildly confusing to allow both of these

from sage.coding.punctured_code import PuncturedCode
PuncturedCode(...)

and 

codes.punctured_code(...)

So your suggestion would imply that we should discourage users from using 
the former style. Then that we don't have

R. = rings.polynomial_ring(QQ)

but only

R. = PolynomialRing(QQ)

would confuse some users.

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/edd95a3d-5064-4963-a71d-f047326867d4%40googlegroups.com.

[sage-devel] Re: How to deal with cross-references to Sphinx documentation of other projects

[Kwankyu Lee]

>
>  At the same time, Sage is trying to move away from Sage-the-distribution, 
> so that packaging third-party inventory files for offline use in Sage is 
> undesirable as well, not to mention the maintenance overhead this would 
> entail.
>

3. Ask by default before downloading missing inventory files including 
python3.inv and adding a docbuild option `--yes-download` to prevent 
asking. 


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/35dacff1-b715-445f-ae89-6aa4da22c212%40googlegroups.com.

Re: [sage-devel] How to deal with cross-references to Sphinx documentation of other projects

[Kwankyu Lee]

On Friday, February 28, 2020 at 3:37:52 AM UTC+9, Markus Wageringel wrote:
>
> This is an interesting suggestion. How would this work with 
> non-interactive builds like on the patchbots or in CI? 
>

So add a docbuild option `--yes-download` to prevent asking. And 
`--no-download` might be useful too...
 

> Would the user be asked right before downloading, perhaps when running 
> configure, so it can fail early?
>

I imagined asking download permission from the user at one time both for 
packages and inventory files at start of making. If no download is needed 
because they were already downloaded, no asking happens.

I am not sure if this can happen at configure time.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4893ebce-0c82-4045-ab1c-081c0219e3d6%40googlegroups.com.

[sage-devel] Re: Table of contents of the Sage reference manual

[Kwankyu Lee]

No more comments? Then would someone review that?

-- 
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] A question about sage reference manual building

[Kwankyu Lee]

Hi,

If I switch the current git branch to another in the sage repository and 
build sage, then sage copies and compiles only updated files. I expected 
the same happens when I build the sage reference manual. That is, among all 
rst files under the directories en/reference/*/sage, exactly those 
corresponding to the files updated in the sage library are regenerated as 
well, and after this is done, actual building of the sage manual get 
started. But now it seems that I am wrong, but that this actually does not 
happen, and so I get errors and warnings about missing files when I try to 
build the document after changing the git branch. So I am forced to do make 
doc-clean, which of course removes all files in en/reference/*/sage. Thus 
it takes a lot of time to rebuild the manual after git branch change.

Am I understanding the situation right? If so, then this is something to be 
fixed, and would you give some pointers to where I should look?

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

Re: [sage-devel] A question about sage reference manual building

[Kwankyu Lee]

On Friday, March 10, 2017 at 9:31:38 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2017-03-10 00:11, Kwankyu Lee wrote: 
> > Am I understanding the situation right? 
>
> Mostly. I think the problem is that the .rst files for removed Sage 
> library files are not removed. 


I investigated this problem, and now can confirm that you are right. I 
wrote a patch to fix the problem. 

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

Thank you.

-- 
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: Table of contents of the Sage reference manual

[Kwankyu Lee]

Really no more comments? 

Then please review: 

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

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

[Kwankyu Lee]

This is close to the second point against (4) but to state clearly:

(4) is against Python documentation, even though no one would chase us if 
we do 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: Names of special methods like _pari_

[Kwankyu Lee]

The following statement from PEP8 is quite definitive:

__double_leading_and_trailing_underscore__ : "magic" objects or attributes 
that live in user-controlled namespaces. E.g. __init__ , __import__ or 
__file__ . Never invent such names; only use them as documented.


One minor "harm" that I can think of is that an uninitiated person may 
misunderstand __pari__ as a new python magic attribute and look for it in 
python manual :-)

-- 
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] A bug at a corner case in hermite_form

[Kwankyu Lee]

Hi,

{{{
sage: m=matrix(2,[0,0,0,0])
sage: m.hermite_form()
[0 0]
[0 0]
sage: m.hermite_form(include_zero_rows=False)
[]
sage: _.parent()
Full MatrixSpace of 0 by 2 dense matrices over Integer Ring
sage: m2=matrix(GF(2),2,[0,0,0,0])
sage: m2.hermite_form(include_zero_rows=False)
...
IndexError: row index out of range
}}}

The latter shows a bug.

-- 
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: A bug at a corner case in hermite_form

[Kwankyu Lee]

Hmm. You will argue that it is my fault to apply "hermite_form" to a matrix 
over a field instead of "echelon_form"... I agree :-)

By the way, "echelon_form" does not admit "include_zero_rows=False".

-- 
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] Let "make doc" always work.

[Kwankyu Lee]

Hi,

If you are a developer and not aware of this, check this:

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

-- 
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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

Hi,

As of Sage 8.0.beta, the location of lcm has changed from "sage.arith.misc" 
to "sage.arith.functions", and the deprecation warning warns that I should 
import lcm directly from "sage.arith.functions".

But the close friend gcd is still in "sage.arith.misc" and an ordinary user 
like me would expect  gcd and lcm found in the same package. I know that I 
can still import both from "sage.arith.all". But I think the deprecation 
warning is not very thoughtful, and gives many an annoying experience...

-- 
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: As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

By the way, I thank the author of the faster lcm very much!  

-- 
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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

On Friday, April 7, 2017 at 10:08:23 AM UTC+2, vdelecroix wrote:
>
> From the user point of view, everything should be 
> imported as 
>
> from sage.arith.all import gcd, lcm 
>

I agree. So the warning message should guide a user to import lcm from 
sage.arith.all.

-- 
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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

Done.

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

-- 
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: Report on WomenInSage

[Kwankyu Lee]

Gorgeous!

-- 
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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

On Friday, April 7, 2017 at 6:18:47 PM UTC+2, Travis Scrimshaw wrote:
>
> From a user point of view, they are already imported so you shouldn't have 
> to do anything.
>

A user of Sage also writes scripts where he or she often imports lcm or 
gcd. 

I also prefer the specific module in general, but in the present case I 
don't want to remember that lcm is from this module and gcd is from that 
module...
 

-- 
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] As of Sage 8.0, lcm is from sage.arith.functions but gcd is not

[Kwankyu Lee]

On Friday, April 7, 2017 at 7:23:59 PM UTC+2, Kwankyu Lee wrote:
>
> On Friday, April 7, 2017 at 6:18:47 PM UTC+2, Travis Scrimshaw wrote:
>>
>> From a user point of view, they are already imported so you shouldn't 
>> have to do anything.
>>
>
> A user of Sage also writes scripts where he or she often imports lcm or 
> gcd. 
>

 I withdraw this argument. You were right. 

-- 
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] How about moving the AUTHORS section to the last?

[Kwankyu Lee]

Hi all,

In the ticket  

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

I introduced a change that could be controversial. I propose to move the 
AUTHORS section to the last of the heading:

r"""

EXAMPLES::

AUTHORS:
- YOUR NAME (2005-01-03): initial version
- person (date in ISO year-month-day format): short desc
"""


As far as I know, some authors already follow this style in practice but I 
think this should be official. So I seek your consensus.



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

Re: [sage-devel] Re: How about moving the AUTHORS section to the last?

[Kwankyu Lee]

>
> > Question: Do you suggest to *manually* move the AUTHORS: section of 
> > *all* affected docstrings? Or do you merely suggest to modify Sage's 
> > doc builder


I merely suggest the official location of the AUTHORS section, as done in 
the ticket.
 

> Having more structured docstring would of course be a good thing. Then we 
> could, as an example, hide the AUTHORS-section if wanted etc. 


Or put it all the way back to the end of the html page, behind the list of 
classes and methods :-)

Besides I want to put a separator just before the list of classes and 
methods.

But making all these things automatic requires Sphinx wizardry, which is 
out of my ability. Sigh...
 

-- 
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: How about moving the AUTHORS section to the last?

[Kwankyu Lee]

Hi,

No one objected to this proposal by now, and one person is positively for 
it. Then would someone review the ticket:

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


This would be a very easy review.


Kwankyu

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

[Kwankyu Lee]

Hi,

For the remote origin, the usual configuration is 

[remote "origin"]
url = git://github.com/sagemath/sage.git
fetch = +refs/heads/*:refs/remotes/origin/* 

If the same fetch setting is used for the remote trac, then the git client 
would try to download all heads from the trac. 

I confess that I mistakenly committed this "crime" recently :-( and fixed 
it as soon as I recognized it.

Might this be a cause of the recent trac slowdown? By the way, I did not 
experience it myself... I am not sure if this is related and/or makes 
sense...


On Friday, April 28, 2017 at 12:20:06 PM UTC+2, Erik Bray wrote:
>
> Did it ever starting working for you again, Anne?  I'm not seeing any 
> problems here. 
>
> For what it's worth, before anyone else asks, the original problem 
> that this thread was about had to do with a badly behaving web scraper 
> that was causing a DOS on the Trac website itself--this would not 
> impact git access over SSH since that doesn't involve the web server. 
>
> (Also, unrelated, but consider using git.sagemath.org for accessing 
> the git repository, as opposed to trac.sagemath.org.  While both 
> addresses currently point to the same server, that may not always be 
> the case.) 
>
> On Fri, Apr 28, 2017 at 5:59 AM, Anne Schilling 
> > wrote: 
> > I just tried 
> > 
> > git fetch origin 
> > fatal: unable to connect to trac.sagemath.org: 
> > trac.sagemath.org[0: 104.197.143.230]: errno=Operation timed out 
> > 
> > Is this related? 
> > 
> > Anne 
> > 
> > 
> > On Saturday, April 22, 2017 at 12:21:29 PM UTC-7, Michael Orlitzky 
> wrote: 
> >> 
> >> On 04/21/2017 05:30 AM, Erik Bray wrote: 
> >> >> 
> >> >> Does this mean that we need some robots.txt somewhere, perhaps after 
> >> >> some 
> >> >> restructuring, 
> >> >> which would protect expensive resources from this sort of overload? 
> >> > 
> >> > There already is a robots.txt and this host was not respecting it. 
> >> > 
> >> 
> >> If this becomes a bigger problem, one solution is to make sure the main 
> >> anonymous trac pages are cached plain HTML files, and to severely limit 
> >> e.g. the search function (with a CAPTCHA, rate limit, etc.) 
> >> 
> >> One motivated person can still slow you down, but they'll have to at 
> >> least try -- I think most of these bot attacks are only accidentally a 
> >> denial of service. 
> >> 
> > -- 
> > 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] Sage policy question: require docstrings and doctests?

[Kwankyu Lee]

I agree with Erik.
 

> This distinction between docstrings vs. comments has never been the Sage 
> practice: Sage practice and official policy has always been to use 
> docstrings. Part of the point is that Sage has intentionally tried to blur 
> the line between user and developer, so any documentation should be made as 
> widely available, and as easily available, as possible.
>

Perhaps this was a practice and reality when Sage was not mature. But for 
future and for better software, the right direction should be to make the 
line clear.  I (We are) am not a user and a developer at the same time: 
When I am a user, I would see docstrings and help on a terminal or in a web 
browser. When I am a developer, I would read the comments in the file as 
well as the docstrings. When I am a user, I hate to see irrelevant 
implementation or development details.

For original post and that particular example, I would add docstrings for 
all the four functions.

-- 
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: Unifying "test::" and "tests::"

[Kwankyu Lee]

>
> The impetus for posting here was that it may make some examples 
> grammatically incorrect, since there would only be one test ... but if no 
> one cares, then we should go with Jori's idea and make it easier to parse.
>

As far as I remember, we adopted the same policy for EXAMPLES:: against 
EXAMPLE:: So Jori's idea is consistent.
 

>  However, this should also include notices to all developers that this is 
> the policy, AND some change to developer guide to make sure it sticks. 
>

I agree. Some part of the developer manual still contains "TEST::". 

In general, my opinion is that the guideline for style in the developer 
manual should be specific in details such that the whole documentation is 
in consistent style. One example is to double-quote or not to double-quote 
True, False, and None. I am for not to. 

-- 
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: Unifying "test::" and "tests::"

[Kwankyu Lee]

>
> I am for writing double-quotes ``True``, ``False``, ``None``, as this is 
> the  "offical" representation of these objects and therefore is printed 
> as output. Thus a typewriter-font is appropriate. 
>

In what sense, is it official? In Python or in Sage?

Two reasons why I am against it:

1. Objects in Sage are written in plain English. Thus a method returns, 
say, an integer not an "Integer" or an element not an "Element". We can 
regard True, False, and None as just proper names of Python objects. The 
docstrings should be written in plain English as much as possible. 
Double-quotes are redundant.

2. True, False, None are very frequent in docstrings as arguments and 
return values. They look better without double-quotes if you see them via 
help(...) or ? in terminal or in jupyter. We should consider how a 
docstring look in terminal, jupyter, as pdf, and as a webpage, and we 
should make a balance. 

I think, to make a docstring less cluttered, double quotes should be used 
only to refer to arguments as in "INPUT: - ``algorithm`` -- ..." and 
obviously code fragments. This convention also would make easier to discern 
arguments in docstrings.

-- 
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 policy question: require docstrings and doctests?

[Kwankyu Lee]

>
> For functions which are meant to be called directly by end users, 
> doctests are essential because they should show examples of how the 
> function should actually be used.


For the case that a function is meant to be internal but can be accessed by 
an end user via say tab completion (which I thought is the case for the 
original example), it should carry a docstring to guide the user away. 

If the name of the function starts with an underline, this should be enough 
to frighten away the user. 

-- 
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: Unifying "test::" and "tests::"

[Kwankyu Lee]

On Wednesday, May 17, 2017 at 11:56:28 AM UTC+2, Jori Mäntysalo wrote:
>
> On Wed, 17 May 2017, Kwankyu Lee wrote: 
>
> >> I am for writing double-quotes ``True``, ``False``, ``None`` 
> > 
> > Two reasons why I am against it: 
>
> Some example functions with different formats of docstrings? Would be 
> easier to compare then. 
>

If you search for True in the following, you can find instances in 
different formats. 

http://doc.sagemath.org/html/en/reference/discrete_geometry/sage/geometry/toric_lattice.html


-- 
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: Unifying "test::" and "tests::"

[Kwankyu Lee]

I am simply asking why we aren't writing a docstring as

"Return True if "

instead of 

"Return ``True`` if ..."

just like

"Return an integer ..."

instead of

"Return an ``Integer``"

-- 
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: Unifying "test::" and "tests::"

[Kwankyu Lee]

>
> I agree; in the formatteed text, there should not be quotes,


In terminal and jupyter, ``True`` is rendered "True". I think this is ugly. 
It should be rendered True
 

> but it should also not be formatted as plain text. 


Why not?  Why do we treat them differently from other Sage objects? Look at 
this

https://docs.python.org/3/library/functions.html?highlight=isinstance#isinstance

They even write it as 

true

 

-- 
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] Several choises for docstring

[Kwankyu Lee]

Now we have a ticket for this

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

Please add your issues to the ticket, following its explicit style :-)

-- 
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] Poll for issue G1 a specific guideline for writing docstrings

[Kwankyu Lee]

We do a poll for adopting an official guideline for docstrings 
(see https://trac.sagemath.org/ticket/23017)

G1. Write 
 
Return True if something is true.

but do not write 

Return ``True`` if something is true.

The same applies to `False` and `None`

If you agree, flag +1; if you disagree and want it reversed, flag -1; if 
you think we do not need this guideline, flag X. 

-- 
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] Poll for issue G2 a specific guideline for writing docstrings

[Kwankyu Lee]

We do a poll for adopting an official guideline for docstrings (see 
https://trac.sagemath.org/ticket/23017)

G2. Write

if the lattice is reflexive ...

but don't write

if ``self`` is reflexive ...


If you agree, flag +1; if you disagree and want it reversed, flag -1; if 
you think we do not need this guideline, flag X.

-- 
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] Poll for issue G3 a specific guideline for writing docstrings

[Kwankyu Lee]

We do a poll for adopting an official guideline for docstrings (see 
https://trac.sagemath.org/ticket/23017)

G3. Write (1) 

Return True if the lattice is reflexive.

but do not write (2)

Return True if the lattice is reflexive and False otherwise.

nor (3)

Return whether the lattice is reflexive.

nor (4)

Test if the lattice is reflexive.

}}}

If you agree, flag +1; if you disagree and have other preferences, flag -1 
and let us know your preferences; if you think we do not need this 
guideline, flag X.

-- 
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] Poll for issue G4 a specific guideline for writing docstrings

[Kwankyu Lee]

We do a poll for adopting an official guideline for docstrings (see 
https://trac.sagemath.org/ticket/23017)

G4. OUTPUT block is optional

The developer manual says OUTPUT block is not optional. But I think the 
first statement of the docstring "Return an object ..." already describes 
what is output. Hence usually the OUTPUT block is redundant and is needed 
only when more explanation about the returned object is necessary.

If you agree, flag +1; if you disagree, flag -1; if you want to leave it as 
it is, flag X.

-- 
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] Poll for issue G5 a specific guideline for writing docstrings

[Kwankyu Lee]

We do a poll for adopting an official guideline for docstrings (see 
https://trac.sagemath.org/ticket/23017)

G5. Write

OUTPUT:

- lattice


but do not write

OUTPUT:

lattice


The development manual says a hyphen is optional. But  for consistency, we 
need to settle down on either style.

If you agree, flag +1; if you disagree and want it reversed, flag -1; if 
you think we do not need this guideline, flag X. 

-- 
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] Poll for issue G5 a specific guideline for writing docstrings

[Kwankyu Lee]

> OUTPUT: a tuple ``(a,b)`` with 
>
> - ``a`` a foo 
>
> - ``b`` a bar 
>

How about this? We can avoid making up variables.

 (1)

OUTPUT: tuple of

- foo; friend of bar

- bar; friend of foo

or simply
 (2)
OUTPUT:

- foo; friend of bar

- bar; friend of foo
-
 

-- 
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] Poll for issue G1 a specific guideline for writing docstrings

[Kwankyu Lee]

>
> -1 
>
> See the first few lines of [1] where an equivalent of our ``True`` is 
> used (and therefore written in typewriter font)
>

(This is perhaps my last resistance; please bear with me :-) 

A technical question: is it possible to set our Sphinx so that we write in 
a docstring

Return True if something is False.

but the True and False are rendered in tt font (or even as links as you 
suggested). Then we could avoid cluttering files with lots of double quotes 
for True, False, and None, and use them mostly for arguments.
 

-- 
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: About oneliners in TOC vs. docstring

[Kwankyu Lee]

>
>
> However, in the index I use 
>
> is_sectionally_complemented() | Return True if every interval from the 
> bottom is complemented. 
>

I would write:

is_sectionally_complemented() | Test if every interval from the bottom is 
complemented. 

-- 
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: About oneliners in TOC vs. docstring

[Kwankyu Lee]

On Thursday, May 18, 2017 at 10:59:35 AM UTC+2, vdelecroix wrote:
>
> On 18/05/2017 10:33, Jori Mäntysalo wrote: 
> > On Thu, 18 May 2017, Kwankyu Lee wrote: 
> > 
> >>   is_sectionally_complemented() | Return True if every interval 
> >>   from the bottom is complemented. 
> >> 
> >> I would write: 
> >> 
> >> is_sectionally_complemented() | Test if every interval from the bottom 
> is 
> >> complemented. 
> > 
> > Yep, seems to be nicer. But maybe we should first see if we want to have 
> > "test if..." -structure in function docstrings. 
>
> How is this different from the poll G3 where everybody seems to agree 
> that we should use 
>Return whether every interval from the bottom is complemented 
>
> ?! 
>

My suggestion was to his "index", which I thought a somewhat informal list 
of functions and descriptions about them. This is not my opinion about G3, 
and I respect the result of the poll G3.
 
 

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

[Kwankyu Lee]

Hi,

I prepared H1 revised from G1 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.*  
**
H1. Write 

``True``, ``False``, ``None``

but do not write 

True, False, None

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.

[sage-devel] Second round poll for H2 a specific guideline for writing docstrings

[Kwankyu Lee]

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.

[sage-devel] Second round poll for H3 a specific guideline for writing docstrings

[Kwankyu Lee]

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.

[sage-devel] Second round poll for H4 a specific guideline for writing docstrings

[Kwankyu Lee]

Hi,

I prepared H4 revised from G4 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.*  
**
H4. OUTPUT block is optional but recommended unless it is clear from the 
one-line 
explanation.

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.

[sage-devel] Second round poll for H5 a specific guideline for writing docstrings

[Kwankyu Lee]

Hi,

I prepared H5 revised from G5 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.*  
**
H5. Write

OUTPUT: 

- tuple of lattices

Note the leading hyphen and no period at the end. If the output consists of 
several items, add each starting with a hyphen.

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.

[sage-devel] Secondl round poll for H6 a specific guideline for writing docstrings

[Kwankyu Lee]

Hi,

I prepared H6 from your comments on the style of INPUT block. 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.*  
**
H6. Write

INPUT: 

- ``n`` -- integer (default: 1); the number of repetition


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.

[sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

[Kwankyu Lee]

As some of you worry, I do not attempt to put some strict rules into the 
developer manual so that forbid your own style in writing docstrings. These 
are intended just as guidelines; these will guide him or her when a 
developer is in doubt in styling the docstrings. On the other hand, if you 
have a strong reason to write in a different style, these guidelines should 
not forbid you.

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

[Kwankyu Lee]

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

[sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

[Kwankyu Lee]

+1

The point is that "the lattice" (or a slight variant "this lattice") is 
officially recommended than "``self``".

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

[Kwankyu Lee]

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

[sage-devel] Re: Second round poll for H4 a specific guideline for writing docstrings

[Kwankyu Lee]

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

[sage-devel] Re: Secondl round poll for H6 a specific guideline for writing docstrings

[Kwankyu Lee]

+1

In English, I understand that "foo; bar" is used if "bar" gives additional 
information about "foo" while "foo, bar"is used to list "foo" and "bar" on 
equal level. 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 H2 a specific guideline for writing docstrings

[Kwankyu Lee]

>
> Here is my opinion. But a metaquestion: Why can't someone (like Kwankyu) 
> just got direct emails and make a summary? 
>

Hmm. Just to make the result of the voting transparent to everyone.

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

[Kwankyu Lee]

+1

H5 is intended to be conforming with "INPUT:" block. 

The above example is somewhat misleading. If the output is just a "tuple of 
lattices" (without long additional explanation), then the entire OUTPUT 
block can be omitted since the one-liner can be "Return a tuple of lattices 
that ". 

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

[Kwankyu Lee]

This is my last attempt to save the guideline.

A Sage user has an integer X. He hit the tab key and get "X.is_prime", and 
then ask what this method does by entering "X.is_prime?". Imagine that he 
reads

(1) Return whether the integer is prime.

(2) Return whether this integer is prime.

(3) Return whether ``self`` is prime.

Which one of these is most friendly plain English answer to his question?

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

[Kwankyu Lee]

On Monday, May 22, 2017 at 10:24:32 AM UTC+2, Jeroen Demeyer wrote:
>
> I very much object to this: 
>
> > If the output consists 
> > of several items, add each starting with a hyphen. 
>
> If the output consists of several items, the OUTPUT string should 
> clearly mention that fact (and it should mention whether the output is a 
> tuple or list or some other structure with several items). 
>

To be clear, I meant the case that the output is by

 Return a, b, c

My opinion is that the phrase "a tuple `(a,b,c)` where ..." is just 
redundant. Anyway I guess that different people have different opinions 
about this as well. 
 

> So something like: 
>
> OUTPUT: 
>
> - a tuple `(a,b,c)` where 
>
>- ``a`` is ... 
>
>- ``b`` is ... 
>
>- ``c`` is ... 
>

This is ugly. By your previous opinion, wouldn't you prefer this?

OUTPUT: a tuple of ``(a,b,c)`` where

- ``a`` is ...

- ``b`` is ...

- ``c`` is ...

I think that the guideline of this thread combined with your one-liner 
style for OUTPUT allows 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] Second round poll for H5 a specific guideline for writing docstrings

[Kwankyu Lee]

On Monday, May 22, 2017 at 12:08:35 PM UTC+2, Jeroen Demeyer wrote:
>
> On 2017-05-22 12:05, Kwankyu Lee wrote: 
> > My opinion is that the phrase "a tuple `(a,b,c)` where ..." is just 
> > redundant. 
>
> I think that "a tuple" is important non-redundant information. 
>

The non-redundant information will be implied by the list of hyphened 
items, if we stick to the convention. 

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

[Kwankyu Lee]

It seems that some misunderstanding is going on here.

If a method returns an integer and a matrix by "Return n, m". I am saying 
that the output block can be simply

OUTPUT:

- integer ...

- matrix ...

instead of

OUTPUT: a tuple of ``(n,m)`` where

- ``n`` is a integer ...

- ``m`` is a matrix ...

You may prefer the second style, but does the first style miss an essential 
information?

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