On Thursday, October 20, 2016 at 10:49:17 PM UTC-7, Travis Scrimshaw wrote:
>
>
>
> On Thursday, October 20, 2016 at 5:06:58 PM UTC-5, Brett Olsen wrote:
>>
>> This was a known bug in line_profiler that is fixed with the 2.0 release.
>> Try upgrading to line_profiler==2.0 and let us know if the
On Friday, November 4, 2016 at 7:11:27 PM UTC, Sébastien Labbé wrote:
>
> I created https://trac.sagemath.org/ticket/21826
>
OK, I've reviewed it already :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
Oups! closing #21826 as duplicate!
--
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
I created https://trac.sagemath.org/ticket/21826
--
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, se
I have created https://trac.sagemath.org/ticket/21825 to track this.
On Friday, November 4, 2016 at 1:18:34 AM UTC, Saul Schleimer wrote:
>
>
> This also appears to leak memory:
>
> def get_polytope():
> q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
> w = q.new_
Actually, I didn't even know that I changed the variable (because the
fricas interface treats all these as POLY INT). So I did a test in fricas,
and indeed, the bad ordering seems to be with y as first variable. Having
t first takes no time even on my (old) laptop, having z first takes a
seco
Actually, I've now checked and it looks like Fricas uses PSR, which will
take forever on this problem if you have the variable ordering with x the
main variable. Of course I'm not terribly familiar with the source code
layout of Fricas, so I could be wrong here.
Bill.
On Friday, 4 November 201
On Friday, 4 November 2016 17:38:17 UTC+1, Bill Hart wrote:
>
> Sure, if you change the order of the variables it will finish in no time
> using PSR.
>
Sorry, I should have said that x has to be the main variable. I could
design some polys for which the timing didn't depend on the main variabl
Sure, if you change the order of the variables it will finish in no time
using PSR.
On Friday, 4 November 2016 17:27:27 UTC+1, Martin R wrote:
>
> FriCAS does this in no time:
>
> sage: R. = PolynomialRing(QQ)
>
> sage: f = z^40*y^6*x^2100 + 2*t^15*z^53*y^9*x^2078 + z^40*y^7*x^2003 +
> z^40*y^6*
FriCAS does this in no time:
sage: R. = PolynomialRing(QQ)
sage: f = z^40*y^6*x^2100 + 2*t^15*z^53*y^9*x^2078 + z^40*y^7*x^2003 +
z^40*y^6*x^2000 - 14*z^31*y^6*x^1102 - 2*t*z^20*y^3*x^1101 +
78*z^20*y^3*x^1100 - 28*t^15*z^44*y^9*x^1080 - 4*t^16*z^33
: *y^6*x^1079 + 156*t^15*z^33*y^6*x^1078
I tried the gcd of the 2 polynomials from Bill Hart, I get
2*z^33*y^6*x^1078*t^15-14*z^
24*y^6*x^80*t^15+z^20*y^4*x^1003+z^20*y^3*x^1100+z^20*y^3*x^1000-2*z^13*y^3*x^79*t^16+78*z^13*y^3*x^78*t^15-7*z^11*y^4*x^5-7*z^11*y^3*x^102-7*z^11*y^3*x^2-y*x^4*t+39*y*x^3-x^101*t+39*x^100-x*t+39
after 20s usin
I tried the gcd of the 2 polynomials from Bill Hart, I get
2*z^33*y^6*x^1078*t^15-14*z^24*y^6*x^80*t^15+z^20*y^4*x^1003+z^20*y^3*x^1100+z^20*y^3*x^1000-2*z^13*y^3*x^79*t^16+78*z^13*y^3*x^78*t^15-7*z^11*y^4*x^5-7*z^11*y^3*x^102-7*z^11*y^3*x^2-y*x^4*t+39*y*x^3-x^101*t+39*x^100-x*t+39
after 20s using
On Friday, 4 November 2016 14:44:09 UTC+1, bluescarni wrote:
>
> On 4 November 2016 at 14:33, 'Bill Hart' via sage-devel <
> sage-...@googlegroups.com > wrote:
>>
>> There are many completely incorrect published algorithms for GCD, even in
>> the univariate and integer case. Dan Bernstein has a
On 4 November 2016 at 14:33, 'Bill Hart' via sage-devel <
sage-devel@googlegroups.com> wrote:
>
> There are many completely incorrect published algorithms for GCD, even in
> the univariate and integer case. Dan Bernstein has a hilarious rant about
> this somewhere online. It's tempting to completel
On Friday, 4 November 2016 14:19:26 UTC+1, bluescarni wrote:
>
> For what it's worth I spent some time earlier this year experimenting with
> multivariate poly GCD in piranha (e.g., here's the PSR_SR implementation
> https://github.com/bluescarni/piranha/blob/master/src/polynomial.hpp#L197).
>
I just tried to do the same for the sage appliance in windows for a
colleague, but I pip install does not seem to work there. What is the trick
to install entrypoint in the VMbox version of sage?
On Tuesday, September 13, 2016 at 2:27:38 PM UTC+2, Jeroen Demeyer wrote:
>
> On 2016-09-13 12:40,
For what it's worth I spent some time earlier this year experimenting with
multivariate poly GCD in piranha (e.g., here's the PSR_SR implementation
https://github.com/bluescarni/piranha/blob/master/src/polynomial.hpp#L197).
It's alpha-quality experimental code which I am about to remove for the
tim
By the way, that (Masters) thesis is absolutely superbly written. I really
wish all mathematics was written like this.
Bill.
On Friday, 4 November 2016 14:17:01 UTC+1, Bill Hart wrote:
>
>
>> For use in multivariate GCD over Z, I eventually want to implement Soo
>> Go's algorithm [1], and over
>
>
> For use in multivariate GCD over Z, I eventually want to implement Soo
> Go's algorithm [1], and over fields, probably a highly optimised Zippel.
> For more generic GCD I can't find anything better than the subresultant
> pseudoremainder algorithm of Collins. If anyone knows of anything b
BTW, I tried taking the GCD of the two polynomials below in Pari and it
just runs out of memory and takes ages. So it doesn't look like it does
much that is useful for multivariates.
On the other hand, their univariate factoring is quite good (better than
mine in some cases, at present).
f = z
On Friday, 4 November 2016 13:50:55 UTC+1, Jeroen Demeyer wrote:
>
> On 2016-11-04 13:41, 'Bill Hart' via sage-devel wrote:
> > Sorry just 1s after posting this, I remembered Pari doesn't have
> > multivariate factoring.
>
> PARI doesn't really have multivariate polynomials in the first place
On 2016-11-04 13:41, 'Bill Hart' via sage-devel wrote:
Sorry just 1s after posting this, I remembered Pari doesn't have
multivariate factoring.
PARI doesn't really have multivariate polynomials in the first place
(they do have polynomials with polynomial coefficients). And they
certainly do n
On Friday, 4 November 2016 13:39:39 UTC+1, Bill Hart wrote:
>
>
>
> On Thursday, 3 November 2016 23:42:27 UTC+1, Dima Pasechnik wrote:
>>
>> Are there open-source implementations of this available?
>>
>
> Pari might be a good place to look. Otherwise, I doubt it. If Bernard
> Parisse hasn't done
On Thursday, 3 November 2016 23:42:27 UTC+1, Dima Pasechnik wrote:
>
> Are there open-source implementations of this available?
>
Pari might be a good place to look. Otherwise, I doubt it. If Bernard
Parisse hasn't done it, it probably doesn't exist.
I remember one of the Maple people gettin
Hello,
Ideals are not restricted to polynomial rings (e.g. order in number
fields). Hence "change_ring" in that case should be generic enough.
For me,
* it would be better to have "change_ring" consistent everywhere
(possibly using *args and/or **kwds)
* if not possible, it would be better to h
25 matches
Mail list logo
