[sage-devel] Re: GSoC 2016 project on algebraic curves
> > > > I don't yet have a blog but will create one soon. I will post a link here > when it is up and will use it to document the project progress. My Sage > experience so far has mostly been with the arithmetic dynamics > functionality and progress in that area is managed within a page of the > Sage wiki. Is there a place for documenting goals/progress for general > algebraic geometry related functionality in Sage? > > As far as i know, there is not such place. But it could be a good idea to start it. -- 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-notebook] Re: [sage-devel] Coming SageMathCell upgrade - please test!
Firefox on Windows 10. Firefox on OS X El Capitan has the same problem. Chrome and Safari on OS X are both functional. On Monday, May 2, 2016 at 7:37:43 PM UTC-7, Andrey Novoseltsev wrote: > > Which browser OS are you using? I just checked now and have the same > issue with Firefox on Windows. Chrome on Windows seems to work (I even > have working 3d plot with JSmol, which is a bit unexpected!). > Yesterday both Firefox and Chrome worked under Linux. > > Regarding changes - I was using develop branch but it got so different > from "old master" that looking/asking about it was pointless. I also > consider the current state more or less stable and requiring only some > bug fixes - moving files was not anticipated. And I really feel the > need to see how it works on production servers preferably with the > "default" setup for branches. Last but not least - I was not aware of > anyone actually looking at the code and trying to do something with it > (Volker helped with require.js and I imagine it was convenient that > going to github was showing relevant files right away). Anyway, as you > can see last commits are quite small apart from splitting a file, so > hopefully I won't cause much more trouble and thank your for testing! > > On Mon, May 2, 2016 at 8:18 PM, paulmasson > wrote: > > Andrey, the test server is not completing evaluations. Just get the > spinning > > GIF. > > > > Also, I'm curious as to why you're making modifications in the master > branch > > of the sagecell repository. I happened to be reading the JavaScript > source > > code right when you split it into smaller files yesterday, and it was a > bit > > disconcerting. Shouldn't you be making changes of that sort in a > development > > branch and merging with the master branch when stable? If someone grabs > a > > copy of the master branch when you're making significant changes, the > > results will be confusing in the very least. > > > > > > > > On Sunday, May 1, 2016 at 6:56:37 PM UTC-7, Andrey Novoseltsev wrote: > >> > >> OK, embedding seems to work for Chrome and Firefox, so reported > >> regressions are fixed. > >> > >> I am planning to switch main servers in 3 weeks. (Probably 7.2 will be > >> out by then, so I'll also see how easy it is to upgrade with the new > >> setup.) > > > > -- > > You received this message because you are subscribed to a topic in the > > Google Groups "sage-devel" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/sage-devel/jPLfIbt048Q/unsubscribe. > > To unsubscribe from this group and all its topics, 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-notebook] Re: [sage-devel] Coming SageMathCell upgrade - please test!
Which browser OS are you using? I just checked now and have the same issue with Firefox on Windows. Chrome on Windows seems to work (I even have working 3d plot with JSmol, which is a bit unexpected!). Yesterday both Firefox and Chrome worked under Linux. Regarding changes - I was using develop branch but it got so different from "old master" that looking/asking about it was pointless. I also consider the current state more or less stable and requiring only some bug fixes - moving files was not anticipated. And I really feel the need to see how it works on production servers preferably with the "default" setup for branches. Last but not least - I was not aware of anyone actually looking at the code and trying to do something with it (Volker helped with require.js and I imagine it was convenient that going to github was showing relevant files right away). Anyway, as you can see last commits are quite small apart from splitting a file, so hopefully I won't cause much more trouble and thank your for testing! On Mon, May 2, 2016 at 8:18 PM, paulmasson wrote: > Andrey, the test server is not completing evaluations. Just get the spinning > GIF. > > Also, I'm curious as to why you're making modifications in the master branch > of the sagecell repository. I happened to be reading the JavaScript source > code right when you split it into smaller files yesterday, and it was a bit > disconcerting. Shouldn't you be making changes of that sort in a development > branch and merging with the master branch when stable? If someone grabs a > copy of the master branch when you're making significant changes, the > results will be confusing in the very least. > > > > On Sunday, May 1, 2016 at 6:56:37 PM UTC-7, Andrey Novoseltsev wrote: >> >> OK, embedding seems to work for Chrome and Firefox, so reported >> regressions are fixed. >> >> I am planning to switch main servers in 3 weeks. (Probably 7.2 will be >> out by then, so I'll also see how easy it is to upgrade with the new >> setup.) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/jPLfIbt048Q/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-notebook] Re: [sage-devel] Coming SageMathCell upgrade - please test!
Andrey, the test server is not completing evaluations. Just get the spinning GIF. Also, I'm curious as to why you're making modifications in the master branch of the sagecell repository. I happened to be reading the JavaScript source code right when you split it into smaller files yesterday, and it was a bit disconcerting. Shouldn't you be making changes of that sort in a development branch and merging with the master branch when stable? If someone grabs a copy of the master branch when you're making significant changes, the results will be confusing in the very least. On Sunday, May 1, 2016 at 6:56:37 PM UTC-7, Andrey Novoseltsev wrote: > > OK, embedding seems to work for Chrome and Firefox, so reported > regressions are fixed. > > I am planning to switch main servers in 3 weeks. (Probably 7.2 will be > out by then, so I'll also see how easy it is to upgrade with the new > setup.) > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: GSoC 2016 project on algebraic curves
Thanks! I really appreciate you taking the time to mentor this project! I don't yet have a blog but will create one soon. I will post a link here when it is up and will use it to document the project progress. My Sage experience so far has mostly been with the arithmetic dynamics functionality and progress in that area is managed within a page of the Sage wiki. Is there a place for documenting goals/progress for general algebraic geometry related functionality in Sage? Right now I'm set up to work in the location I will be staying during the summer. I think it would be good for me to try to get a head start on implementing what I have planned if possible. I also want to test the rational parameterization and genus functionality in Singular before the coding period starts. On Monday, May 2, 2016 at 2:24:15 PM UTC-4, mmarco wrote: > > Welcome! > > Now we have a couple of weeks for "community bonding" before you actually > start working in the project. I guess that means this is the time where you > get used to Sage development workflow: the trac server, review process, > discussions in this mailing lists and so on. Since you have already some > experience in Sage devlopment, you are probably familiar with all that. > Please feel free to ask any questions you might have, and to participate in > the discussions that you could be interested in. > > Do you plan to document your progress in a blog? > > El lunes, 2 de mayo de 2016, 10:38:12 (UTC+2), Grayson Jorgenson escribió: >> >> Hi everyone, >> >> I am one of the students selected to work on Sage this summer for GSoC >> 2016 and just wanted to introduce myself and my project here. Currently I >> am a pure math graduate student at Florida State University and am >> interested in algebraic geometry. The goal of the GSoC project I will be >> working on is to expand the algebraic curve functionality in Sage. In >> particular, I will be working on implementing functionality for >> analysis/resolution of singularities, intersection analysis, finding plane >> curve models, and computing rational parameterizations (when they exist) >> for algebraic curves. My mentors for this project are Benjamin Hutz and >> Miguel Marco. >> >> I really appreciate having the opportunity to work on this as a GSoC >> project and am excited to get started. Thank you! >> >> Grayson >> > -- 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] Rank Metric Codes in Sage
Welcome to the Sage community, Arpit! I'm sure this GSoC project will become a very nice addition to Sage :-) Best, Johan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: GSoC 2016 project on algebraic curves
Welcome! Now we have a couple of weeks for "community bonding" before you actually start working in the project. I guess that means this is the time where you get used to Sage development workflow: the trac server, review process, discussions in this mailing lists and so on. Since you have already some experience in Sage devlopment, you are probably familiar with all that. Please feel free to ask any questions you might have, and to participate in the discussions that you could be interested in. Do you plan to document your progress in a blog? El lunes, 2 de mayo de 2016, 10:38:12 (UTC+2), Grayson Jorgenson escribió: > > Hi everyone, > > I am one of the students selected to work on Sage this summer for GSoC > 2016 and just wanted to introduce myself and my project here. Currently I > am a pure math graduate student at Florida State University and am > interested in algebraic geometry. The goal of the GSoC project I will be > working on is to expand the algebraic curve functionality in Sage. In > particular, I will be working on implementing functionality for > analysis/resolution of singularities, intersection analysis, finding plane > curve models, and computing rational parameterizations (when they exist) > for algebraic curves. My mentors for this project are Benjamin Hutz and > Miguel Marco. > > I really appreciate having the opportunity to work on this as a GSoC > project and am excited to get started. Thank you! > > Grayson > -- 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: NTL 9.7.1
Thanks for sharing this Victor. It looks like there are some additional really good speedups there. Flint has always had just reasonable matrix code, nothing extraordinary. I put quite a bit of work into the recent minpoly and charpoly code I put into Flint (which NTL was already very good at). But I didn't do a comparison with anything except Sage and Magma yet. I definitely want to spend some time going through your benchmarks and improving Flint, but as usual, so many other things need doing that it probably won't happen soon. Much of what we have done in Flint is just out-of-date for modern CPU's, especially with AVX. For example, I doubt we should be using strassen. Many of our tuning cutoffs are also way out of date. This is particularly bad as Flint has no tuning code. Most of the recent work in Flint has been to add lots of small utility functions, to write better documentation and to make Flint more reliable (asserts, better test code, etc.) Oh well, one day we will get around to speeding it up again. Bill. On Wednesday, 20 April 2016 23:08:30 UTC+2, Victor Shoup wrote: > > I uploaded a new NTL version (9.7.1) to > http://www.shoup.net/ntl > This version completes the implementation of faster matrix > arithmetic (mul, inv, gauss, etc) modulo small primes. > > These new implementations are more cache friendly, and they > make more intelligent use of available hardware (e.g., AVX). > They also can be accelerated in a multicore environment. > > I've run some tests that show that this implementation is "not too > bad" compared to FFLAS/FFPACK based on OpenBLAS. > > I've also updated my NTL vs FLINT comparisons to include > some benchmarks for matrix arithmetic mod small primes. > You can also see those results at >http://www.shoup.net/ntl/benchmarks.pdf > > > > -- 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] Deprecate the use of properties in all public API
On Monday, May 2, 2016, Michael Orlitzky wrote: > On 05/02/2016 06:07 AM, Erik Bray wrote: > > On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer > wrote: > >> My vote: > >> > >>> [X] Phase out properties which perform any non-trivial computation > >> > >> > >> In certain cases, properties might be useful (but it could very well be > that > >> there are 0 such cases in Sage). > > > > I generally feel that properties *should* be used in general for > > invariants of some object, regardless of how it's computed in the > > first place. I see the point about not using them for "non-trivial" > > computations but I also find the lack of a clear definition of > > "non-trivial" troubling. > > > > Properties, in any programming language, are syntactic sugar over > getter/setter methods on private member variables. In a language like > C#, they're useful and you have a sensible rule for when to use them: > use properties to get/set private member variables, and methods for > everything else. So basically, properties do no computation at all. Another hugely relevant factor for us is that sage is used mostly interactively and with extensive use of doc strings and introspections. Most Python code and libraries (and most C# code) are normally used from other Python code/libraries, not interactively. Sage is somewhat unusual in this regard. > > In python, all member variables are public, so the concept of a property > is a bit redundant. It's hard to come up with a "when to use properties" > rule in python, because the only rule that makes sense doesn't apply. > Anywhere you could use a property, you can use a "public" member > variable instead (if you can't, then you wanted a method to begin with). > > The one useful feature of @property is that it lets you document your > member variables. If I have a class with a "public" nrows member > variable, then I can't document it so that when a user runs foo.nrows?, > it tells him what that variable is supposed to do. By creating a > property (which is only syntactic sugar over a getter method), I gain > the ability to add a docstring on what would otherwise be a variable. > > So, the rule I would put forth is: use @property to document public > member variables, and methods for anything else. > > -- > 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. > -- Sent from my massive iPhone 6 plus. -- 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] Deprecate the use of properties in all public API
On 05/02/2016 06:07 AM, Erik Bray wrote: > On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer > wrote: >> My vote: >> >>> [X] Phase out properties which perform any non-trivial computation >> >> >> In certain cases, properties might be useful (but it could very well be that >> there are 0 such cases in Sage). > > I generally feel that properties *should* be used in general for > invariants of some object, regardless of how it's computed in the > first place. I see the point about not using them for "non-trivial" > computations but I also find the lack of a clear definition of > "non-trivial" troubling. > Properties, in any programming language, are syntactic sugar over getter/setter methods on private member variables. In a language like C#, they're useful and you have a sensible rule for when to use them: use properties to get/set private member variables, and methods for everything else. So basically, properties do no computation at all. In python, all member variables are public, so the concept of a property is a bit redundant. It's hard to come up with a "when to use properties" rule in python, because the only rule that makes sense doesn't apply. Anywhere you could use a property, you can use a "public" member variable instead (if you can't, then you wanted a method to begin with). The one useful feature of @property is that it lets you document your member variables. If I have a class with a "public" nrows member variable, then I can't document it so that when a user runs foo.nrows?, it tells him what that variable is supposed to do. By creating a property (which is only syntactic sugar over a getter method), I gain the ability to add a docstring on what would otherwise be a variable. So, the rule I would put forth is: use @property to document public member variables, and methods for anything else. -- 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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)
> Consistency is a definitive plus, as well as not impeding > introspection. So I would tend to agree to officially phase out > properties from the public API. > > There is one use case for properties in the public API though which I > would like to bring up, namely "glorified methods". > ... Yes, this is a good example of where such syntactic micro-magic can be a very pleasant experience for the user. I think the cases of properties that both Jeroen and Erik are arguing to allow are exactly things like this. It seems that possible doc-issues can be managed, more or less. So I concede that the rigid stance of officially disallowing all properties would be "asking for trouble". Perhaps a more realistic stance is something like: [ ] Rule of thumb: don't use properties, except if there is a clear, syntactic benefit that presents a logical exception (to the "method default") for the user. Properties should particularly be avoided if exceptions could be thrown or heavy computation performed. OK, so that's not perfectly well-defined either, but at least things like MPolynomialIdeal.basis should be method'ized by this rule, as should the list of properties in the recent AsymptoticRing class (e.g. summands, growth_group, coefficient_ring, ao.). Going back to Matrix, I would argue that Matrix.T, Matrix.H, etc. also fall for this rule. Certainly, Matrix.I does. Best, Johan -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Optional doctest failure
As the author of #20182, I don't think that the behavior of `sage -t` changed. #20182 triggers a new behavior only if you put "optional=...,external,..." in the argument list. On the other hand, new definitions of make (p)testoptional(long) make (p)testall(long) indeed include "optional=sage,optional" and "optional=sage,optional,external", respectively. So their behavior changed from beta 6. Automatic testing of installed optional packages was introduced in a previous release of Sage. This is a different story. 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.
[sage-devel] [ANN] Job opening in Kaiserslautern for OpenDreamKit to work on MPIR
Hi all, Since February this year, Alex Best has been working for us in Kaiserslautern on a new superoptimiser for assembly language in MPIR. The superoptimiser is now working beautifully, but Alex has managed to get himself a PhD position and will be leaving us at the end of July this year. That means we have 6 months of funding left to fund a good C programmer with a willingness to learn x86_64 assembly, starting in August this year. Candidates must be prepared to come to Kaiserslautern (we can help with finding accommodation) for the duration and must have at least a Masters in Mathematics, Computer Science or Computer Engineering. More details about the position can be found here: http://opendreamkit.org/2016/05/02/developer-position3-kaiserslautern/ The main deliverables left are: * use the superoptimiser to speed up assembly routines for modern x86_64 processors * parallelise the FFT for multiplying large integers in MPIR (it has been written with parallelism in mind) * (Optionally) help with an ongoing effort to implement the triple large prime variant of the quadratic sieve, for factoring large integers Please see the link above for details on how to apply, and feel free to forward this to anyone you think might be interested. Bill. -- 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] Let's talk specifics (was Re: how we develop sage)
On Mon, May 2, 2016 at 2:52 PM, Erik Bray wrote: > On Wed, Apr 27, 2016 at 5:05 PM, William Stein wrote: >> On Wed, Apr 27, 2016 at 7:09 AM, Kwankyu Lee wrote: >>> This discussion is hardening the terms: Sage core and external packages. But >>> from the point of view of the people developing the would-be external >>> packages, the official term would better be >>> >>> Sage extension, >>> Sage library extension, >>> Sage library extension package, >>> or SLEP. > > Two easily confused with "extension module" in the sense of a Python > module written in C. * Too, not "Two"; I already had the next paragraph buffered somewhere but there was a stray memory copy error, possibly caused by a cosmic ray :) -- 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] Let's talk specifics (was Re: how we develop sage)
On Wed, Apr 27, 2016 at 5:05 PM, William Stein wrote: > On Wed, Apr 27, 2016 at 7:09 AM, Kwankyu Lee wrote: >> This discussion is hardening the terms: Sage core and external packages. But >> from the point of view of the people developing the would-be external >> packages, the official term would better be >> >> Sage extension, >> Sage library extension, >> Sage library extension package, >> or SLEP. Two easily confused with "extension module" in the sense of a Python module written in C. >> Or simply extension package. > > Or > > Python package (that depends on Sage) Well remember there are two types of projects we're talking about here: 1) Projects that adhere to some yet-to-be-determined standards set out by the Sage project, and that in return are promoted as extra, if not more specialized products built on Sage, included in Sage-the-distribution, and possibly used in continuous integration with Sage as well. Those would deserve a special name "affiliated package" or the like. 2) Packages that happen to "import sage" somewhere. Those I agree are Python packages (that depend on sage). Best, Erik -- 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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)
On Mon, May 2, 2016 at 10:35 AM, Jeroen Demeyer wrote: > My vote: > >> [X] Phase out properties which perform any non-trivial computation > > > In certain cases, properties might be useful (but it could very well be that > there are 0 such cases in Sage). I generally feel that properties *should* be used in general for invariants of some object, regardless of how it's computed in the first place. I see the point about not using them for "non-trivial" computations but I also find the lack of a clear definition of "non-trivial" troubling. I agree with Jeroen that there may be exceptions. I think a strict rule against "properties in public APIs" is asking for trouble, and that this should still be considered on a case-by-case basis. Perhaps more controversially, I'm fond of creating proxy objects that can become callable if need be For example an int that usually has an invariant value, but in might rare cases can be modified by some additional context that would be provided by "calling" it, in which case I make a proxy-int that's callable. I think in these cases Sage's policy has been to make them methods with zero required positional arguments, which is fine too. It's my preference, but it also has downfalls, so it's not a sword I care to die on :) Erik -- 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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)
On 2016-04-29 10:38, Nicolas M. Thiery wrote: P.f(x) # use the morphism as a function P.f.rank() # play with the morphism itself cached method also does this. You can do P.f(x) to call the cached_method f but you also do stuff like P.f.clear_cache(). I certainly do not want cached methods to become P.f()(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] GSoC 2016 project on algebraic curves
Hi everyone, I am one of the students selected to work on Sage this summer for GSoC 2016 and just wanted to introduce myself and my project here. Currently I am a pure math graduate student at Florida State University and am interested in algebraic geometry. The goal of the GSoC project I will be working on is to expand the algebraic curve functionality in Sage. In particular, I will be working on implementing functionality for analysis/resolution of singularities, intersection analysis, finding plane curve models, and computing rational parameterizations (when they exist) for algebraic curves. My mentors for this project are Benjamin Hutz and Miguel Marco. I really appreciate having the opportunity to work on this as a GSoC project and am excited to get started. Thank you! Grayson -- 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] Deprecate the use of properties in all public API (was: Heavy-computation @property in Matrix class)
My vote: [X] Phase out properties which perform any non-trivial computation In certain cases, properties might be useful (but it could very well be that there are 0 such cases in Sage). -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
