Big +1.
There's the sage/tests folder which seems to be a place where certain
developers who really couldn't help themselves put some additional
tests. But it doesn't go near as far as what you're proposing.
However, there's obvious issues wrt. ensuring that such tests gets
written once in a
> It's a little dangerous, our doctest framework uses the XKCD random
> number generator.
There's prior work by S. Adams:
http://dilbert.com/strip/2001-10-25
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Seems like a similar patch needs to be applied to
git_trac/digest_transport.py when your system defaults to Python 3.
Best,
Johan
Volker Braun writes:
> Thats because of https, you need to do the analog change that I just did on
> the git-trac script:
>
> diff --git
sage: import warnings
sage: warnings.filterwarnings('always',".*", DeprecationWarning)
sage: deprecation(3,"m")
Hi sage-devel,
On my Sage installation, as well as on David Lucas' (having different
Linux distros), the following *does not* print the expected deprecation
warning in the Sage shell or
Hi,
> 1- is it desirable for quo_remo and _floordiv_ to be equivalent for
> all of R1, R2, R3 and R4?
> 2- what is the most reasonable behavior?
I wouldn't expect those rings to behave the same. Defining the
multivariate ring in steps indirectly gives a position-over-term
ordering in the
Hi sage-devel,
As a huge part of Arpit Merchant's GSoC project on Gabidulin codes,
we've been working on Xavier Caruso's old patch implementing skew
polynomial rings, #13215.
While everyone involved has considered the code and math carefully, it
is my opinion that the design could still be
Hi,
On my machine, Ivan's workaround also does not help: I get exactly the
same behaviour as Martin R. I run Emacs 24.5.1 on Arch Linux 4.6.3-1,
x86_64.
See also this depressing post on Emacs Stack Exchange:
http://emacs.stackexchange.com/questions/24453/weird-shell-output-when-using-ipython-5
Hi Jori,
Are you missing other standard spkgs? Such as database_cremona_ellcurve,
palp, sympy?
I never resolved my problem regarding missing packages:
https://groups.google.com/forum/#!searchin/sage-devel/johan|sort:date/sage-devel/WERLdTKfAho/OoKt3Z2YBgAJ
Best,
Johan
Jori Mäntysalo writes:
ave been
removed or altered, and that's why Make is not picking up those targets.
Any thoughts?
Best,
Johan
leif writes:
> Johan S. H. Rosenkilde wrote:
>>> Except for the Sage library (and probably docbuilding, not sure), yes.
>>> If you explicitly use 'make -j1
Hi Stan,
It seems that trait_names() was originally added as part of a mechanism
for giving tab-completion to certain objects in IPython and the
Notebook, and this mechanism changed. Hence what used to be
trait_names() is now called _tab_completion() -- at least
units.energy._tab_completion()
> well, we already have this: https://trac.sagemath.org/report/79
> IMHO it's a great idea to have all such places explicitly marked.
+1. I think it's great to have such a list which contains both the ones
for which we wish to add a stopgap, as well as those we don't/haven't
yet.
If the stopgap
Hi Arpit,
Did you try doctesting other parts of Sage to see whether your
segfaults are related to the ticket or not? It could be related to your
system setup.
If this is not the case, you should, as Travis asked you on an earlier
question, try to find a minimal example which causes the bug from
Sounds pretty great!
> [X] Yes
> [ ] No
> [ ] Maybe
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post
> You are trying to build a DAG of tickets that is a coarser version of the
> git DAG. You'd need
>
> * Tools to make sure that the two different graphs stay alined.
> * UI to visualize the two different graphs, and to report conflicts
> * Documentation
We are informally and without tools
> Though really you want to know "what would be added if the ticket were
> merged right now" which is, in general, not a single git query (for
> starters merge can fail but git can diff anything). This is what clicking
> on the branch in trac does.
This shows the diff of the current ticket +
> No, because dependencies are not static. You can e.g. delete the branch
> from a dependency after the dependent ticket has been reviewed...
I don't think I understand what you mean. If that happens, then surely
some action should be taken on the dependent ticket?
Say #B is dependent on #A. If
> Changing the branch on A doesn't change the branch on B.
>
> E.g. assume A, B started on the develop branch. Then commit on A, merge A
> in B, commit on B.
>
> Now A contains one commits, and B contains two commits.
>
> Then reset A back to develop. B still contains two commits.
Yes, that's
> Because there is no ticket-DAG and there is no immutable history of
> tickets.
I don't see why there couldn't be. Once a ticket is closed, it is
immutable. While a ticket is open, its position in the DAG is mutable:
it will always depend on the tip of develop, as well as tickets that it
> 2) When I do git-blame, or other similar commands, I can easily get a
> commit message or commit hash, but I can't get a ticket number. Which is
> usually what I want (to look up e.g. why a change had been done). That's
> user-unfriendly.
I should have added that I don't think we can do much
> sounds like the first "make" failed...
That's not clear to me. The compile of Sage itself seemed to work but
then make failed during doc-building. This has happened so often during
the years I've worked with Sage, however, that I've learned to ignore
it. Inspecting the error now, I see that
>> ar: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required
>> by /usr/lib/libLLVM-3.8.so)
>
>
> Are you using llvm? As far as I know that doesnt' work, though I haven't
> tried it myself.
I was baffled about that too. I haven't consciously done anything that
would use llvm.
Hi,
> sage: sage: f1(x) = -1
> sage: sage: f2(x) = 2
> sage: sage: f = Piecewise([[(0,pi/2),f1],[(pi/2,pi),f2]])
> /home/novoselt/sage/src/bin/sage-ipython:1: DeprecationWarning: use
> lower-case piecewise instead
> See http://trac.sagemath.org/14801 for details.
>
Hi leif,
> Well, it's apparently just that your toolchain isn't using binutils
> consistently; usually LLVM's tools get installed as 'llvm-ar' and
> 'llvm-ranlib', or they don't get installed into the default PATH.
I don't have llvm-ar or llvm-ranlib installed AFAIK (they're in the
package llvm
Are you having the same problem as me:
https://groups.google.com/forum/#!topic/sage-devel/WERLdTKfAho
For instance, do you have sympy installed? (if you don't, "./sage -t
src/sage/arith.py" will fail immediately due to uninstalled sympy).
Do you have Cremona's mini-database installed? Test by
> $ make --version
GNU Make 4.2.1
Built for x86_64-pc-linux-gnu
> Did you build in parallel, and if so, does probably building
> sequentially fix the problem (such that the missing packages then get
> built)?
I just did "make"; the default is still sequential build, right? I have
no suspect
zlib-1.2.8.p0
zn_poly-0.9.p11
zope_interface-4.1.3
Best,
Johan
leif writes:
> Johan S. H. Rosenkilde wrote:
>>> $ make --version
>> GNU Make 4.2.1
>> Built for x86_64-pc-linux-gnu
>>
>>> Did you build in parallel, and if so, does probably building
>>> se
Hi,
I just noticed, in the very beginning when doing "make" after distclean,
the build process prints a list of packages:
checking package versions...
4ti2-1.6.7
alabaster-0.7.8
arb-2.8.1.p0
...
This list *does* contain the uninstalled packages:
Hi sage-devel
Today I made a fresh clone of the develop branch, ran "make", and then
tried to run "./sage -t". To my surprise, this didn't work at all!
First off, the doctest framework wouldn't even run, since sympy wasn't
installed. After doing "./sage -pip install sympy", I could now actually
> leif wrote:
> Well, depends on /what/ you write there...
>
> At least mentioning the different notions of skew polynomial evaluation
> (and that currently only one, and which, is implemented) shouldn't hurt.
>
> And you could clearly state what aspects of the interface are probably
> subject to
> Regarding this whole @experimental discussion (I never heard of
> @experimental until just now), it seems like yet another case of
> trying to use some awkward mechanism to get around ignorance of Python
> packaging and modules. Python has this amazing thing called
> "Python libraries" and
> That thread doesn't mention @experimental or decorators explicitly.
Well, you're replying to Daniel Krenn's comment: he points at a public
branch, explicitly mentioning that it introduces
sage.misc.superseded.experimental which "acts like a deprecation, but
giving a FutureWarning stating that
Hi Harald,
Thanks for yelling out. I've added the polynomial class project that
I mentioned on the list earlier. But 1 project is surely not enough...
Best,
Johan
Harald Schilly writes:
> Hello, in 3 days is the deadline regarding the project application.
> I'm working on the application
> Exactly. I wouldn't like to have documentation that is *not* included in the
> SageMath sources. Currently, one can access all documentation locally, during
> a
> SageMath session.
+1
Most of the Feature Tour pages http://www.sagemath.org/tour.html are not
in the source tree. They are also
Johan S. H. Rosenkilde writes:
> Hi Everyone,
>
> This is to announce that we are organizing Review Days 3 on Coding
> Theory. This is a one-day *online* event which will take place:
>
>February 7, 2017
>From 9-17 GMT+1, or until everyone runs out of steam
>
> S
Hi sage-devel
Yesterday we held Sage Review Day 3, and it was a big success. I just
wanted to briefly share my experience with this.
Overall, 8 developers participated, most of them all day. We
communicated using Slack, Framapad and Trac. We got 14 tickets
positively reviewed, and had good
Jean-Pierre Flori writes:
>>
>> I would be very interested in working on this.
Cool :-) Let's discuss the project description off the mailing list.
Also, thanks Peter for your input. We should definitely take a closer
look at #15601.
Best,
Johan
--
You received this message because you are
Kwankyu Lee writes:
>
> I understand this as practically saying that we should avoid breaking
> existing doctests as much as possible and try to be consistent in new
> doctests as much as possible.
>
> And how the new doctests would be written is determined when we actually
> write the code.
Hi sage-devel,
Our current polynomial implementation has severe issues:
- Our speed for GF(2^e)[x] is abysmal.
- For other cases we are probably not linking to the currently fastest
libraries.
- We don't have multi-point evaluation or fast Lagrange interpolation,
even though the libraries
I confirm the problem, even with develop:
$ git fetch trac develop
fatal: Couldn't find remote ref develop
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Harald Schilly writes:
> Just got word:
>
>> Congratulations! Sage Mathematical Software System has been selected as a
>> Google Summer of Code 2017 mentor organization.
Awesome! I got a bit worried the last few days before deadline since our
GSoC page was somewhat sparse :-)
--
You received
The mails seems to have been correctly sent out to subscribers (of
sage-devel). At least a few of us here at SD75 got it. I can't explain
why it's not showing up on the google groups web site.
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel"
I should perhaps clarify my main question:
Isn't the unique citation as used in Sphinx a Bad Idea for Sage?
Most source files in Sage are not ordered, and if we refer to document
[X] in two different source files, we currently have three options:
1) Arbitrarily define [X] in one file and refer
I just ran into a doc issue that has been bothering me for years: global
uniqueness of reference labels in Sphinx. For instance, in
sage.coding.code_construction, we have:
.. [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting
Codes, Cambridge Univ. Press, 2003.
This means I
leif writes:
>> ... [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting
>>Codes, Cambridge Univ. Press, 2003.
>
> Well, first of all it is stupid to use such a short abbreviation, even
> without a year. Presumably it was introduced when references were
> local, so we may create a
Dima Pasechnik writes:
> only a small minority of Sage users actually use terminal.
How do you know that? Seriously, I'd like to know how our users
distributed across interfaces. It's my impression that quite a lot of
casual users of Sage begin with terminal use and never leave it.
> And in any
> Regarding speed, there are two issues:
>
> 1. Building the documentation from scratch. I don't know if we can expect
> this to go any faster. The PDF version of the documentation is 3,474 pages
> long. No, wait, that's just the contribution from references/combinat: the
> whole reference
> In any large document, such as the sage manuals, there are bound to be
> uniqueness issues with the choice of labels for references. The best way to
> resolve this is for us to start using a specified format for the
> references. Currently we do not even have guidelines for this so it is not
> ... while you don't need a catalog to create such an alias.
But then we would have even more stuff in the global namespace.
> Still, having a catalog wouldn't be bad.
+1 to having the catalogue. +1 to allowing aliases in that catalogue.
+1 to removing not-very-common categories from global
Volker Braun writes:
> Thats ok for reviewing tickets, and implemented as "git trac try
> ".
OK. I had a chat with Thierry Monteil and we agreed there were some
subtle differences I don't remember - but I'll take a look at "git trac
try".
> But if you want to actually make changes then this
Jeroen Demeyer writes:
> On 2016-09-10 00:03, Paul Masson wrote:
>> Why would recythonizing be necessary when only changing the same file on
>> the same branch?
>
> You are not changing just one file. When you checkout a new branch, a
> lot of files get changed. When you checkout the old branch
leif writes:
>> But if you want to actually make changes then this creates a new merge
>> commit which furthermore is against the conventional order (where the
>> feature branch is the first parent). So it makes the commit history harder
>> to understand.
>
> I'd rather say "impossible", or
leif writes:
> Well, probably it's just me, but I always (also) review tickets on trac
> (i.e., via what git-o-lite gives); the whole branch, but also each
> individual commit. You just need a browser to do so.
I use git-o-lite a lot too, but often switch back to my Emacs and git
log using
Jeroen Demeyer writes:
>> https://ccache.samba.org/
>
> And I forgot to mention that I have 2 complete Sage installation trees
> so I can let one compile while I use the other.
Thanks, that's useful. Do you need any special setup or care for making
it work in the complicated Sage compilation
I just got bit by the following behaviour, which is surprising to me:
sage: hash(GF(17))
-9223363248217694901
sage: hash(GF(17))
-9223363251803121333
So the hash of the very-much-the-same-every-time object GF(17) is not
constant across invocations of Sage. Is this expected behaviour? Is this
> On 2016-10-07 13:35, Johan S. H. Rosenkilde wrote:
>> Should __hash__ be constant across Sage invocations?
>
> No. I see no reason why it should be.
I presume there's nothing in the Python spec that says so, since
object() doesn't satisfy this. Is that what you mean?
To me it
I've created #21661 reporting that @func_persist is currently broken for
this reason.
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Jeroen Demeyer writes:
> $ python3 -c "print(hash('hello'))"
> -74281615791272169
> $ python3 -c "print(hash('hello'))"
> 447613799834866972
> $ python3 -c "print(hash('hello'))"
> 5466708731786648082
>
> I think the only logical conclusion is that you should *not* rely on
> comparing hashes
With MR numbers, do you mean a link of the type [MR3352496]?
> well, for preprints clearly there is of course the arXiv number and for
> sciences without a good database, there is doi.
Neither arXiv nor DOI completely catalogues all publications. I don't
know how many such cases appear in
> Having said this, I again would argue for an option to have aliases.
>
> E.g. say there is a popular Arxiv preprint cited 10 times in the source,
> which then becomes
> a publication. It is really unnecessary to change all these 10 citations?
That's a good point. But does Sphinx support such
>>> As discussed in another thread [1]_ on sage-devel recently, I propose
>>> changing our policy toward references:
>>>
>>> - all references should be put into a master bibliography file
>>>
>>
>> There is one significant drawback to this: it will mean that a lot of
>> ticket branches will be
Super exciting - Congratulations! And please keep us updated when the
web page comes up.
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
William Stein writes:
> Good point. Also, I'm for making the user type
>
>import something.or.other
>
> **explicitly**, rather than having it pre-imported on startup. Of
> course, the import command will be documented.
I see your point. But is
"You need an explicit import, and a warning
Thierry Dumont writes:
> Certainly, it is http://wiki.sagemath.org
Haha, yes of course it is :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Hi everyone,
I just edited the front page of http://wiki.sagemath.com so that it
appears less embarrassingly out of date. I restructured it so that it is
more clear that it is a place for certain developer organization (mostly
SageDays), so that it now less pretends to be a very lively place with
>> What do the Sage developers even want to use the wiki for? Apart from
>> SageDays organisation.
>
> - listing sage days
> - there's a nice list of interact examples: https://wiki.sagemath.org/interact
>
> Look at https://wiki.sagemath.org/RecentChanges to see what people
> *do* use the wiki
> Would you have any interest in moving the wiki
> to https://github.com/sagemath/sage/wiki ?
What would be the advantage of doing so?
What do the Sage developers even want to use the wiki for? Apart from
SageDays organisation.
At SageDays75, we just created (or rewrote)
> +1. If anything wiki.sagemath.org should redirect to
> trac.sagemath.org/wiki since Trac already provides a (generally nicer,
> more powerful) wiki that integrates better with development ;)
+1 to merging wiki.sagemath.org into trac.sagemath.org/wiki.
Right now there's tendency for duplicated
VulK writes:
> The first question is about which is the correct way to implement methods
> that are not always defined.
I agree with Nils that subclassing is the most OOP-clean way of
achieving this. That being said, one might argue that it is a pretty
heavy-handed solution which potentially
I don't understand -- aren't you getting the full documentation, as in this
page:
http://doc.sagemath.org/html/en/reference/combinat/sage/combinat/posets/__init__.html#sage-combinat-posets
At least, on my machine it prints the exact same information.
Best,
Johan
'Martin R' via sage-devel
> Yes, but there are no links. Or do you have them?
True, they are not links. It would be nice if they were, though
personally I like that what is printed is the actual module name that I
should type in followed by ? to see its doc. That's probably how I would
do it even if it was a link, and
> In case no one else has noticed, doc.sagemath.org is now showing up in
> Google searches, including the link that initiated this thread.
Indeed I have noticed! It's really good news for us and - especially -
for new Sage users :-)
Best,
Johan
Paul Masson writes:
> In case no one else has
> 0 = 42
> print 0
Hahaha, easiest way to get a contradiction and thereby prove any statement
in Sage :-D
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
>> sage: a = range(10**8) # takes a lot of memory
>> sage: del a# free the memory
>
> Ok, so now, I understand why it takes the memory: a list was created.
Using xrange instead of range will also avoid creating the list even
without cdef'ing a (the code is still slow of
Ted Kosan writes:
> Unfortunately, what most mathematics teachers are teaching is not
> mathematics. This observation is described well by Scott Gray ...
Indeed, I'm sure there's many examples of such teaching going on, and it
is important to try to improve this.
> High school mathematics
> Johan's suggestion is very intriguing but, unless I am completely mistaken,
> it does not work in python. If I understand correctly if O is an instance of
> Foo and O does not have the attribute x then python looks for Foo().x
You're right, I seem to have confused myself with deleting
> Not me -- but I did review it in 2010! -- see
> https://trac.sagemath.org/ticket/9069
Ah, I misunderstood what you had written previously :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
> I'm sure that Sage already has code for Weak Popov Form. I
> implemented it myself in about 2004 but from the date you can tell
> that it was not in Sage (but Magma).
>
> Indeed, search_src("popov") finds
>
> matrix/matrix_misc.py:32:def weak_popov_form(M,ascend=True):
That function doesn't
John Cremona writes:
> That was the algorithm I implemented in Magma. It was not very hard.
Indeed. My student made an effort of comparing C++, Cython and pure Sage
implementations, in combination with various tweaks to the algorithm.
In the end the Cython version was at best 2x faster than my
There's been quite a bit of work on Hermite normal form of K[x]-matrices
recently, most notably by Vincent Neiger:
http://dl.acm.org/citation.cfm?id=2930889.2930936
This algorithm gives a much faster way of computing the Hermite Normal
form of K[x] matrices. Unfortunately it relies on quite
Hi all,
I just tracked down a nasty bug completely messing up my experiments to
this internal caching mechanism. In a clean Sage type:
sage: E = FiniteEnumeratedSet([ GF(97)(i) for i in [1,2,3,4,5,6]])
sage: type(E[0])
Restart Sage and type instead
sage: E = FiniteEnumeratedSet([1,2,3,4,5,6])
havior and the coercion framework.
>
>My guess is that you are treating the finite enumerated set as a tuple,
> and so I would suggest that you just used tuples (which has far less
> overhead).
>
> Best,
> Travis
>
>
> On Wednesday, November 2, 2016 at 12:45
Hi everyone,
OK, we can bicker about the semantic difference of the words "bug" vs
"intentional but bad design" all day, but in the end we agree it's not
great for the user. It seems the ever-vigilant Vincent discovered the
problem already a year ago and proposed a sensible fix for the problem
in
> Travis wrote:
> Also, instead of Subsets(L), I would also use subsets(L) (or powerset(L))
> as you don't need the set of all subsets to be a parent.
I see now that those functions don't support an argument for which size
subsets you need (which is critical in my application).
Best,
Johan
--
Hi Ted,
As William stated, I think any functionality improving SageMath's appeal
for, say, educating high school students would be very welcome. My main
concern is how valuable what you propose with PRESS-like printing is in
this respect.
You gave a printout of your current PRESS implementation
> TL;DR: if you have a 64-bit Windows (Windows 7 and up should work)
> please demo and give me your thoughts on the new build of Sage for
> Windows using the installer at [1].
Great work, Erik!
Best,
Johan
--
You received this message because you are subscribed to the Google Groups
Volker Braun writes:
> There is a somewhat painless approach to generating human-readable release
> notes using https://github.com/hawkowl/towncrier. As far as the ticket
> author is concerned, if you think that your ticket #12435 is of wider
> interest and should be announced then all you'd
Hi Everyone,
This is to announce that we are organizing Review Days 3 on Coding
Theory. This is a one-day *online* event which will take place:
February 7, 2017
From 9-17 GMT+1, or until everyone runs out of steam
See the Review Days web page: https://wiki.sagemath.org/review3.
We will
I reported this bug 1,5 years ago:
https://groups.google.com/forum/#!topic/sage-devel/rvs5E6AEXVc
Not to point fingers, but you said: "The behavior is bad but I would not
call it a bug. You modified wrongly the vector." ;-)
Back then you proposed to change the semantics such that a vectors'
Hi Harald,
Sorry I've been unresponsive for a while. I realise I'm not on the
mentors list to review projects - could you please add me?
Probably best to use this email address: santaph...@gmail.com
Best,
Johan Rosenkilde
Harald Schilly writes:
> Hi, a follow up for mentors: I thought mentors
>
> (2) _pari(): meant for private methods. This doesn't seem correct to me,
> because we want this method to be part of the public API.
But as Thierry says, perhaps not so public that we want it to figure in
tab-completion on all objects everywhere.
Isn't this exactly because most users would
> That's absolutely correct, and a point I make in my blog. One heuristic is
> that GBs tend to have a large number of very small polynomials and so one
> can dispatch larger arithmetic operations to a different back end safely
> (converting to and from some other format on the fly). This is
Thanks a lot for reporting! We *really* appreciate any feedback from
using Sage in classes: on bugs, designs and feature requests.
This bug is now #23433. I'll push a patch momentarily.
Best,
Johan Rosenkilde
Dima Pasechnik writes:
> On Thursday, July 13, 2017 at 11:43:18 AM UTC+1, David
Vincent Delecroix writes:
> If the basis of a "Finite dimensional module with basis" is always assumed to
> be
> ordered, then such method make sense. However, the terminology is quite
> strange.
> I see 1+1/2 ambiguities for matrices over polynomial ring such as Mat(ZZ[X],
> 3).
>
> 1)
Compared to Sage 8.0, matrices in Sage 8.1.beta1 now have a host of new
methods:
- leading_coefficient
- leading_item
- leading_monomial
- leading_support
- leading_term
These are inherited from the category of finite dimensional modules with
basis of which matrix spaces are now
Hi Friedrich
I totally agree with 1) and 2): that kind of implementations would be
very appropriate and valuable to have in Sage. Concerning 3), I would
initially think that doc-tests could be sufficient.
I was loosely involved in some discussions on implementing the McEliece
public-key
Hi Paul,
>1. Is there a process to ask for a code review of this type of code
>(i.e. code primarily written to support a paper)?
Alas, one of the weaknesses of the current research publication process...
>2. Do you have any suggestions as to how and where I could publish a
>
+1 to "this lattice" and +1/2 to "the lattice". In either case I think
it should mention in the guideline that using ``self`` is also
acceptable if the sentence would become more clear.
Kwankyu Lee writes:
> Hi,
>
> I prepared H2 revised from G2 based on your ideas and wishes. It was hard
> to
+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.
> As I mentioned on the other thread, since OUTPUT is not a list of things
> (as opposed to INPUT), I would prefer
>
> OUTPUT: tuple of lattices
+1 on this option (and hence -1 to the thread's suggestion).
--
You received this message because you are subscribed to the Google Groups
> H6. Write
>
> INPUT:
>
> - ``n`` -- integer (default: 1); the number of repetition
+1. I agree with the grammatical reasons to slightly prefer ";" over ","
(but I am not a native speaker).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To
1 - 100 of 104 matches
Mail list logo
