As I mentioned on the other thread, since OUTPUT is not a list of things
(as opposed to INPUT), I would prefer
OUTPUT: tuple of lattices
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails fro
A method like `Graph().is_bipartite(certificate=False)` returns either
``True``or ``False`` when ``certificate==False``, or a tuple `(bool, dict)`
when ``certificate==True``. What would be the recommended writing style for
the output block ?
--
You received this message because you are subscr
Almost +1
Actually I thought this guideline has already been used, with
a minute difference:
- ``n`` -- integer (default 1), the number of repetitions
(so, "default" instead of "default:" and ")," instead of ");",
since "path connected" punctuation marks are better than disconnected
ones.
Act
X
I still cannot give a clear +1 or -1 to the current suggestion, as
it goes into the right direction but isn't flexible enough.
I'd rather suggest:
H2.
Write "if the lattice is reflexive" unless a technical expression
such as "if ``self`` is reflexive" is more easy to understand.
It reall
+1
On 2017-05-18, Kwankyu Lee wrote:
> 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
PS, to the +1 given earlier: I suggest that one should also write `f(x)`
instead of f(x).
On 2017-05-18, Kwankyu Lee wrote:
> 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 bett
+1
On 2017-05-18, Kwankyu Lee wrote:
> 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
-1, and very strongly -1.
Reason:
On 2017-05-17, Kwankyu Lee wrote:
> G3. Write (1)
>
> Return True if the lattice is reflexive.
This leaves open what the function returns if it is not reflexive.
None? False? A certificate that proves that it isn't reflexive?
> but do not write (2)
>
> Return
X
In some context, the technical term ``self`` might be easier to
understand (for someone who knows python...) than natural language,
in other context it may be the other way around
Maybe +1 as a rule of thumb, but -1 as a strict rule.
On 2017-05-17, Kwankyu Lee wrote:
> We do a poll for adopt
-1, for reasons that have already been explained by others. Generally,
any reference to a programmatical object should be typographically
distinguished from normal text. Hence, it should be
"Let `f(x)` be the function that returns ``True`` if `x>0` and
``False`` otherwise."
but not
"L
On Thu, 18 May 2017, Kwankyu Lee wrote:
So this time if I fail to get approval from most of you, the guideline
will be simply discarded.
I am strongly against discarding the guideline(s). If we have no common
view, I suggest that we make a poll (LimeSurvey or similar) and tell it
sage-supp
On Thu, 18 May 2017, John H Palmieri wrote:
.. INPUT::
We would need to add "INPUT", "OUTPUT", etc. as Sphinx directives. Then we
would have control over the format for the
output.
Sounds good, BUT what about substructures? Can we have, for example, NOTE
inside INPUT? In some more compl
As I mentioned about, I suspect what is happening is each process runs its
own copy of normaliz, which in turn, uses all CPU cores with its parallel
computations. This would cause either a lot of thrashing or waiting for
locks to free up. Thus, we don't run into this when running Sage directly
Strong -1 (still)
On Thursday, May 18, 2017 at 5:46:35 PM UTC-5, Kwankyu Lee wrote:
>
> 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 o
+1 (this is also my preferred format)
On Thursday, May 18, 2017 at 5:28:54 PM UTC-5, Kwankyu Lee wrote:
>
> 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* i
+1 (it is also currently used in practice).
On Thursday, May 18, 2017 at 5:24:12 PM UTC-5, Kwankyu Lee wrote:
>
> 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 t
+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
Hello,
This year I will be working on the matroid and graph theory packages for
Google Summer of Code. My project will focus on expanding the list of
matroid classes available in sage, with methods to do convenient or more
efficient computations specific to the class. In particular, I'll make a
I think it is really an upstream problem with normaliz. We could try
to work around it in our normaliz interface (not just the doctest)
because it may also affect computation time in general on some
hardware. (I never ran into trouble with it on my machine.)
On Wed, May 17, 2017 at 5:24 PM, Travis
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
hav
Regarding the current polling for docstring guidelines and standards,
perhaps it would be better to write docstrings in a form like
def f(...):
"""
one line description, as we currently have
.. INPUT::
input block, maybe an itemized list
.. OUTPUT::
output bloc
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:
-
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:
-
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 op
+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.
Visi
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 whet
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 latt
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``,
+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
+1
Le mercredi 17 mai 2017 16:24:47 UTC+2, Kwankyu Lee a écrit :
>
> 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 t
On 2017-05-18 14:36, Erik Bray wrote:
I don't think you could write something that is intelligent enough to
distinguish the literals ``True``, ``False``, or ``None`` with the
word itself (which would be capitalized if beginning a sentence--not
common, but not impossible either).
Reasonable exam
On Thu, May 18, 2017 at 9:19 AM, Kwankyu Lee wrote:
>> -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 se
On Wed, May 17, 2017 at 1:53 PM, Jeroen Demeyer wrote:
> On 2017-05-17 12:19, Vincent Delecroix wrote:
>>
>> 1) Each code path (including errors) must be tested".
>
>
> You can easily translate this requirement as "require 100% *line* coverage"
> instead of *function* coverage which is what is c
Kwankyu Lee wrote:
> G2. Write
>
> if the lattice is reflexive ...
>
> but don't write
>
> if ``self`` is reflexive ...
X
--
Marc
--
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 i
Kwankyu Lee wrote:
> G5. Write
>
> OUTPUT:
>
> - lattice
>
>
> but do not write
>
> OUTPUT:
>
> lattice
X
--
Marc
--
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 em
Kwankyu Lee wrote:
> 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.
X
--
Marc
-
Kwankyu Lee wrote:
> G4. OUTPUT block is optional
+1
--
Marc
--
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
Kwankyu Lee wrote:
> 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`
X
--
Marc
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
On Thu, 18 May 2017, Vincent Delecroix wrote:
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 - -
I think that the poll is still open.
--
Jori Mänty
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 w
> On 18/05/2017, at 21:37, Jeroen Demeyer wrote:
>
> On 2017-05-18 11:25, Francois Bissey wrote:
>> Puzzled me for a while too. It doesn’t.
>
> So you are saying that BRiAl consists of two *independent* parts which don't
> interact at all? That by itself would increase the reasons for splittin
On 2017-05-18 11:25, Francois Bissey wrote:
Puzzled me for a while too. It doesn’t.
So you are saying that BRiAl consists of two *independent* parts which
don't interact at all? That by itself would increase the reasons for
splitting. Does Sage actually require both parts?
--
You received t
On 18/05/2017, at 21:24, Jeroen Demeyer wrote:
>
> On 2017-05-18 01:09, François Bissey wrote:
>> And I have a pure
>> python pybrial that install with a minimal setup.py.
>
> If it's pure Python, then how does it access the libBRiAl library?
>
Puzzled me for a while too. It doesn’t.
--
You
On 2017-05-18 01:09, François Bissey wrote:
And I have a pure
python pybrial that install with a minimal setup.py.
If it's pure Python, then how does it access the libBRiAl library?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscrib
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.
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 shou
>
>
> 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 subs
>
> -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 Tru
48 matches
Mail list logo
