IMO we do not want there to be too much of a distinction between
multivariate polynomial rings in 1 variable and univariate polynomial
rings. I would say the proper thing to do is to pass along the underlying
implementation as part of the MPoly functor (which is what you proposed
change is
On 2/28/19 10:53 AM, Jeroen Demeyer wrote:
> Since many years, we have patched the Python in Sage with a patch to
> mitigate some security issues related to sys.path.
>
There are two issues here:
1) You should never be doing anything at a predictable world-writable
location.
Do we do
On Thursday, February 28, 2019 at 9:16:19 AM UTC-8, E. Madison Bray wrote:
>
>
> I suggest a middle ground: I don't believe this behavior should be
> tested in Sage's test suite, because this is a question about the
> Python interpreter's behavior, not Sage. The possibility of running
> Sage
> On 1/03/2019, at 08:40, Timo Kaufmann wrote:
>
> I suggest a middle ground: I don't believe this behavior should be
> tested in Sage's test suite, because this is a question about the
> Python interpreter's behavior, not Sage.
> [...]
> Otherwise, I don't think the Sage test suite has
There is some previous discussion here:
https://trac.sagemath.org/ticket/26457
--
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
>
> I suggest a middle ground: I don't believe this behavior should be
> tested in Sage's test suite, because this is a question about the
> Python interpreter's behavior, not Sage.
>
[...]
> Otherwise, I don't think the Sage test suite has any business testing
> this.
>
+1, I agree with
On Thu, Feb 28, 2019 at 4:53 PM Jeroen Demeyer wrote:
>
> Since many years, we have patched the Python in Sage with a patch to
> mitigate some security issues related to sys.path.
>
> The security issue is the following: if you run a Python script from a
> world-writable directory, say a script
Since many years, we have patched the Python in Sage with a patch to
mitigate some security issues related to sys.path.
The security issue is the following: if you run a Python script from a
world-writable directory, say a script like /tmp/foo.py this is very
insecure since Python will add
On Tue, Feb 26, 2019 at 7:33 PM Nils Bruin wrote:
>
>
>
> On Tuesday, February 26, 2019 at 6:16:56 AM UTC-8, E. Madison Bray wrote:
>>
>> I'll note also that there is a 7 year old(!) open ticket about this
>> at: https://trac.sagemath.org/ticket/13071
>>
>> I think it would be a very good problem
On 28.02.19 09:15, Daniel Krenn wrote:
> Does someone have a glue why
>
> sage: T = PolynomialRing(QQ, 't', 1); t = T.gen()
> sage: t * vector([1,2])
The underlying problem is that the functor MPoly[t] applied to QQ (for
example) returns a true univariate polynomial ring instead of a
On 28.02.19 09:15, Daniel Krenn wrote:
> I tried to debug, but I am a bit lost on this particalar problem, so any
> kind of input is welcome.
Found something; I'll report back soon.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
On Thu, Feb 28, 2019 at 12:14 AM Nils Bruin wrote:
>
> On Wednesday, February 27, 2019 at 2:17:06 PM UTC-8, John H Palmieri wrote:
>>
>> Why does Sage allow inequalities in Z/nZ?
>
>
> I'm pretty sure that it's a historical artifact from Python 2, where
> inequality relations exist between
Does someone have a glue why
sage: T = PolynomialRing(QQ, 't', 1); t = T.gen()
sage: t * vector([1,2])
results in an error
TypeError: unsupported operand parent(s) for *: 'Multivariate
Polynomial Ring in t over Rational Field' and 'Ambient free module of
rank 2 over the principal
13 matches
Mail list logo
