Re: [sage-devel] Re: Matrix groups are not uniquely represented, why?
On Thursday, May 31, 2018 at 9:24:57 AM UTC-7, Nils Bruin wrote: > > > > On Thursday, May 31, 2018 at 3:05:26 AM UTC-7, Erik Bray wrote: >> >> >> Could you actually point me to one of those memory leaks? I'm sure >> they exist but I'm still not clear on how this happens. I suspect it >> could be improved, and I would like to look into how... >> > > https://trac.sagemath.org/ticket/17008#comment:13 (prediction) > https://trac.sagemath.org/ticket/23851 > https://trac.sagemath.org/ticket/23807#comment:14 (explanation) > https://trac.sagemath.org/ticket/14549#comment:6 > https://trac.sagemath.org/ticket/18426 > https://trac.sagemath.org/ticket/14356 > https://trac.sagemath.org/ticket/17360 > https://trac.sagemath.org/ticket/18905#comment:26 > > The main thing that strikes me is how reasonable the code that introduces > the memory leak appears. That is why I expect this is a trap people will > keep falling in again and again. > And to illustrate with what frequency you can expect to discover these things in our code base: https://trac.sagemath.org/ticket/25560 -- 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: Error building Sage on MacBook Pro running MacOS High Sierra version 10.13.5
Dear Sage Development team, I was able to resolve the issue. It seems that there is a problem with the build script which performs a parallel compilation of Sage using multiple jobs. Staying clear of any sophisticated export options works just fine. Thanks and best regards, -- 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] divisions
On Monday, June 11, 2018 at 10:30:42 AM UTC-7, David Roe wrote: > > The standard that I would propose is the following: > 1. If R has been constructed as a localization (namely, if the > construction() method returns some kind of localization functor) then the > result of a/b will lie in R. If b is not invertible in R (like 0 in a > field), raise an error. This error can provide instructions on using the > fraction field if R is an integral domain. > 2. Otherwise, if R is an integral domain, a/b will live in the fraction > field of R. > 3. Finally, if R is not an integral domain, a/b will live in R, raising an > error if b is not a unit. > And you would exclude p-adics and power series from this because they are obtained via completion? On the face of it, this seems to make sense: if someone goes out of their way to invert some elements but not all, then he/she probably doesn't want those other elements to be inverted automatically. You are introducing some non-commutativity into the coercion graph that way, though. If we have R=LaurentPolynomialRing(QQ,'x') Qx.=QQ[] then with your proposal we'd have sage: parent((x+1)/x) Fraction Field of Univariate Polynomial Ring in x over Rational Field sage: parent(R(x+1)/x) Univariate Laurent Polynomial Ring in x over Rational Field [as we have now] but sage: parent(x/(x+1)) Fraction Field of Univariate Polynomial Ring in x over Rational Field sage: parent(R(x)+x) Univariate Laurent Polynomial Ring in x over Rational Field sage: parent(R(x)/(x+1)) thus, we see that sage (rightly) has the canonical embeddings QQ[x] subset QQ[x,x^(-1)] subset QQ(x) but coercion into the middle set might prevent operations from succeeding. On the user level I don't think there is anything wrong with that: it's basically what the user asks for. As always, though, the real problems with coercions occur when they happen some levels deeper, i.e., if we have other objects defined over QQ[x], QQ[x,x^(-1)] and QQ(x). I think a decision like this will prevent Laurent polynomials from being a "fully supported base ring", in the sense that objects based on top of it will behave in unexpected ways. That might just be fine, though. You might want to ask some toric geometers if they are going to be happy with this, though. > Of course, currently the construction method for Laurent polynomials is a > special LaurentPolynomialFunctor, but this can be changed. I think an > approach that treats localizations differently is important if we want to > support other kinds of localizations in a reasonable way. > David > > >>> > I think that any comparison to the integers is a bit unfair given that >>> ZZ >>> > and QQ are generally very good with ducktyping and there is no natural >>> way >>> > to create the inverse of the variables (i.e., what makes them Laurent >>> > polynomials) other than by division or exponentiation. >>> >>> "natural" sounds strange in that context. As already mentioned there is >>> >>>1 // x >>> >>> to get the inverse of x. And x.inverse_of_unit() also does the job. >>> >> >> Nobody is going to want to type inverse_of_unit() when they want x^-1; >> plus I would never have thought of that to get x^-1. >> >> I had the same first thought as Jeroen with 1 // x == 0, but then I >> thought in terms of quo_rem, and 1 // x should return the quotient, which >> in this case is x^-1. However, it would take a little bit for me to realize >> this is what I have to do. >> >>> >>> Though, close to what Nils talked about, there is no straight >>> method for "internal division or raise error". >> >> >> I thought inverse_of_unit() did this? >> >> Best, >> Travis >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+...@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] divisions
On Sat, Jun 9, 2018 at 8:03 PM Travis Scrimshaw wrote:
>
>
> On Sunday, June 10, 2018 at 12:12:46 AM UTC+10, vdelecroix wrote:
>>
>> On 09/06/2018 04:00, Travis Scrimshaw wrote:
>> > What Vincent has neglected to mention is the reasoning why I am
>> suggesting
>> > to keep the current behavior for Laurent polynomials. A casual user
>> will
>> > almost certainly do
>> >
>> > 1 / x^k
>> >
>> > and then try to do a method on Laurent polynomials (say, iterate over
>> such
>> > element). The rational functions code does not have many of the methods
>> and
>> > features that Laurent polynomials have.
>> >
>> > Also, they (or at least I) would be quite surprised when x^-1 does not
>> > behave the same as 1/x as they are mathematically equivalent. Also,
>> what
>> > about ~x, should that be the same as 1/x or x^-1? You now have to
>> choose
>> > the correct inverse to get working code. I think this inconsistency is
>> far
>> > worse.
>>
>> Mathematically equivalent is first of all vague
>
>
> Can I frame that quote? :P
>
>
>> and secondly not
>> relevant within most CAS since there are tons of different 0 that behave
>> very differently.
>>
>
> I agree that for a CAS, we sometimes need to sacrifice mathematical
> statements for programming reasons (0 is good, plus things like ==, RR).
>
>>
>> I agree that having x^-1 and 1/x being different is confusing. I will
>> update the branch at #25524 to make them identically return a rational
>> fraction.
>>
>
> I think this is even worse than the confusion. I would suspect we will get
> a ton of AskSage questions asking how do we construct x^-1 in the Laurent
> polynomial ring (maybe efficiently). At least, upon seeing this behavior,
> my first approach would be L(1/x) because I know I would leave the ring,
> but then need to come right back (well, if I didn't know that x // y was
> suppose to always return a result in the ring you started).
>
I think I agree with Travis here that Laurent polynomials are different
from every other ring currently in Sage in their relationship to division.
The reason is that they are constructed via localization (like fraction
fields) but the corresponding multiplicative subset is not just R\{0} (and
thus there are non-zero non-invertible elements). Elements of
localizations are explicitly defined as ratios, and if we force divisions
to leave the ring it becomes very awkward to work with elements.
It's already the case that division doesn't always land in the fraction
field, since some rings are not integral domains and thus don't have
fraction fields:
sage: parent(mod(6,8)/mod(3,8))
Ring of integers modulo 8
The standard that I would propose is the following:
1. If R has been constructed as a localization (namely, if the
construction() method returns some kind of localization functor) then the
result of a/b will lie in R. If b is not invertible in R (like 0 in a
field), raise an error. This error can provide instructions on using the
fraction field if R is an integral domain.
2. Otherwise, if R is an integral domain, a/b will live in the fraction
field of R.
3. Finally, if R is not an integral domain, a/b will live in R, raising an
error if b is not a unit.
Of course, currently the construction method for Laurent polynomials is a
special LaurentPolynomialFunctor, but this can be changed. I think an
approach that treats localizations differently is important if we want to
support other kinds of localizations in a reasonable way.
David
>> > I think that any comparison to the integers is a bit unfair given that
>> ZZ
>> > and QQ are generally very good with ducktyping and there is no natural
>> way
>> > to create the inverse of the variables (i.e., what makes them Laurent
>> > polynomials) other than by division or exponentiation.
>>
>> "natural" sounds strange in that context. As already mentioned there is
>>
>>1 // x
>>
>> to get the inverse of x. And x.inverse_of_unit() also does the job.
>>
>
> Nobody is going to want to type inverse_of_unit() when they want x^-1;
> plus I would never have thought of that to get x^-1.
>
> I had the same first thought as Jeroen with 1 // x == 0, but then I
> thought in terms of quo_rem, and 1 // x should return the quotient, which
> in this case is x^-1. However, it would take a little bit for me to realize
> this is what I have to do.
>
>>
>> Though, close to what Nils talked about, there is no straight
>> method for "internal division or raise error".
>
>
> I thought inverse_of_unit() did this?
>
> Best,
> Travis
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscr
Re: [sage-devel] Re: divisions
On 10/06/2018 10:51, Marc Mezzarobba wrote: Travis Scrimshaw wrote: I agree that having x^-1 and 1/x being different is confusing. I will update the branch at #25524 to make them identically return a rational fraction. I think this is even worse than the confusion. I agree with that. Mee too :-) In the branch at #25524 I like the WYSIWYG sage: L. = LaurentPolynomialRing(QQ) sage: 1/q 1/q sage: q^-1 q^-1 But we have to agree that q^-1 has no reason to be equivalent to 1/q. Though, close to what Nils talked about, there is no straight method for "internal division or raise error". I thought inverse_of_unit() did this? Only in the case of 1/b, not for general a/b... Exactly. Vincent -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Patching policy
To be clear I am not advocating to create a fork of every dependency. That would probably only worsen the problem (making it even easier to pull the "patch trigger" and harder to find the patches for distributions). -- 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] Patching policy
On 2018-06-08 13:05, Dima Pasechnik wrote: patches are not the best way to update things. VCSs are much better... Fair enough, that's a reasonable argument, although most patches actually don't need to be updated. For example, if the patch comes from upstream, there is no need to do anything. And patches which are not submitted/accepted upstream may survive many versions without conflicts. -- 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.
