According to the above discussion I marked
https://trac.sagemath.org/ticket/28774 as wontfix, please review.
Am Dienstag, 3. Dezember 2019 13:16:30 UTC+1 schrieb Simon King:
>
> Hi Nils,
>
> On 2019-12-02, Nils Bruin > wrote:
> > On Monday, December 2, 2019 at 3:18:20 PM UTC-8, Michael Orlitzky
Hi Nils,
On 2019-12-02, Nils Bruin wrote:
> On Monday, December 2, 2019 at 3:18:20 PM UTC-8, Michael Orlitzky wrote:
>>
>> Who do I have to make a campaign donation to if I want this to be the
>> default?
>>
>
> The Society for the Prevention of Predictable Performance would be a good
> place
On 12/2/19 6:48 PM, Nils Bruin wrote:
>
>
> On Monday, December 2, 2019 at 3:18:20 PM UTC-8, Michael Orlitzky wrote:
>
> Who do I have to make a campaign donation to if I want this to be the
> default?
>
>
> The Society for the Prevention of Predictable Performance would be a
> good pl
On Monday, December 2, 2019 at 3:18:20 PM UTC-8, Michael Orlitzky wrote:
>
> Who do I have to make a campaign donation to if I want this to be the
> default?
>
The Society for the Prevention of Predictable Performance would be a good
place to start.
Trying to find a radical expression for an
On 12/2/19 10:55 AM, Brent W. Baccala wrote:
> I'd suggest setting AA.options.display_format = 'radical' to eliminate
> the "numerical noise".
Who do I have to make a campaign donation to if I want this to be the
default?
--
You received this message because you are subscribed to the Google Grou
I'd suggest setting AA.options.display_format = 'radical' to eliminate the
"numerical noise".
--
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
On Saturday, November 30, 2019 at 5:10:48 PM UTC-8, vdelecroix wrote:
>
>
> Calling c.minpoly() triggers some exactification. Compare with
>
> sage: a = AA(2).sqrt()
> sage: b = AA(3).sqrt()
> sage: (a + b) * (a - b) * (b - a) * (-a -b)
> 1.000?
>
Sure, but there is no "numerical n
Le 30/11/2019 à 14:52, Nils Bruin a écrit :
On Saturday, November 30, 2019 at 1:47:47 PM UTC-8, Jonathan Kliem wrote:
I don't know if the choice of RLF was appropriate for a default embedding,
but I'd be wary of embedding in AA/QQbar by default, because they are so
unpredictable in their
On Saturday, November 30, 2019 at 1:47:47 PM UTC-8, Jonathan Kliem wrote:
>
>
> I don't know if the choice of RLF was appropriate for a default embedding,
>> but I'd be wary of embedding in AA/QQbar by default, because they are so
>> unpredictable in their performance. Generally, you should NOT
Thanks for the comment.
Am Freitag, 29. November 2019 22:47:13 UTC+1 schrieb Nils Bruin:
>
>
>
> On Friday, November 29, 2019 at 12:45:45 PM UTC-8, Jonathan Kliem wrote:
>>
>> The following leads to a TypeError:
>>
>> sage: K2. = QuadraticField(2)
>> sage: K3. = QuadraticField(3)
>> sage: sqrt2 +
On Friday, November 29, 2019 at 12:45:45 PM UTC-8, Jonathan Kliem wrote:
>
> The following leads to a TypeError:
>
> sage: K2. = QuadraticField(2)
> sage: K3. = QuadraticField(3)
> sage: sqrt2 + sqrt3
>
> Both of them are real embedded by default, so coercion should work (at least
> this is my o
On 2018-06-13 01:33, Simon King wrote:
It is, if the absence of a direct coercion triggers the construction of
a pushout that uses a more efficient implementation than the two rings
under consideration.
What do you have against R[x][y]? There are certainly cases where that's
a much more natura
On 2018-06-12 17:39, Nils Bruin wrote:
Possibly a nice test for
seeing if the list of coercions and conversions present is sufficient is
to see if all those maps can be defined by giving a list of images of
generators.
No, that won't be sufficient because you need to give a map from the
base r
On 2018-06-12, Jeroen Demeyer wrote:
>> However,
>> these iterated polynomial ring constructions are quite inefficient.
>
> True, but I don't see that as an argument to have no coercion.
It is, if the absence of a direct coercion triggers the construction of
a pushout that uses a more efficient i
On Tuesday, June 12, 2018 at 2:09:53 PM UTC-7, Simon King wrote:
>
>
> Problem:
> It is currently possible to create the polynomial ring R[x][x]
> (hence, x occurs twice). If "x" has two different meanings in the
> same ring, the notion "name preserving map" makes no sense. I believe
> it shoul
On 2018-06-12 23:07, Simon King wrote:
And now think about quotients of polynomial rings. Let A,B have the same
variable names in the same positions, but let the monomial orderings be
different. Let I be an ideal in A and J the corresponding ideal in B.
So, if we say that there is a name and posi
Hi!
We are talking about rings that mathematically are multivariate
polynomial rings over a commutative ring R. So, R[x,y], R[y,x], R[x][y],
R[y][x], PolynomialRing(R,['x','y'],'lex'), PolynomialRing(R,['x','y'],
'degrevlex'),...
About conversions: They can basically be anything. But:
i) There
On Tuesday, June 12, 2018 at 7:24:45 AM UTC-7, Jeroen Demeyer wrote:
>
> I'd like to say that the following should be coercions:
> R -> R[x,y]
> R[x] -> R[x,y]
> R[y] -> R[x,y]
> R[x][y] -> R[x,y]
>
> But not the following:
> R[x,y] -> R[x][y]
> R[x,y] -> R[y,x]
> R[x,y][z] -> R[x][y,z]
>
Hello Simon,
> One can of course try the following rule for constructing C: If the
> minimal polynomial used in the construction of GF(8,'x') is obtained
> from the minimal polynomial used in the construction of GF(8,'y') by
> substitution y->x, then the map extends to an isomorphism that shall
>
On 18 September 2015 at 16:21, Simon King wrote:
> Hi Nathann,
>
> On 2015-09-18, Nathann Cohen wrote:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
>>>
>>> Not a bug, because cross-parent comparison would only make sense if
>>> there is some kind of a c
Hi Nathann,
On 2015-09-18, Nathann Cohen wrote:
>>> sage: K1 = GF(8,'x')
>>> sage: K2 = GF(8,'y')
>>> sage: K1(1) == K2(1)
>>> False
>>
>> Not a bug, because cross-parent comparison would only make sense if
>> there is some kind of a canonical map of one parent (and not just of a
>> single elemen
Simon,
>> sage: K1 = GF(8,'x')
>> sage: K2 = GF(8,'y')
>> sage: K1(1) == K2(1)
>> False
>
> Not a bug, because cross-parent comparison would only make sense if
> there is some kind of a canonical map of one parent (and not just of a
> single element!) into the other or of both parents into a third
Hi Nathann,
On 2015-09-17, Nathann Cohen wrote:
> Here is another discovery after 15 minutes of debugging:
>
> sage: K1 = GF(8,'x')
> sage: K2 = GF(8,'y')
> sage: K1(1) == K2(1)
> False
Not a bug, because cross-parent comparison would only make sense if
there is some kind of a canonical map of o
On Thu, Sep 17, 2015 at 8:00 AM, Nils Bruin wrote:
> On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>>
>> The real problem here is that *conversion* gives rise to an error
>> that mentions *coercion*.
>>
>> sage: K. = GF(25)
>> sage: L. = GF(25)
>> sage: K(y)
>> Tra
On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>
> The real problem here is that *conversion* gives rise to an error
> that mentions *coercion*.
>
> sage: K. = GF(25)
> sage: L. = GF(25)
> sage: K(y)
> Traceback (most recent call last):
> ...
> TypeError:
On Thu, Sep 17, 2015 at 2:53 AM, Simon King wrote:
> Hi!
>
> On 2015-09-17, Jeroen Demeyer wrote:
>> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>>> Hi,
>>>
>>> I guess one of the issue is that there is no canonical map between two
>>> different representations of the same finite field (so no c
Equals is not transitive in Sage. Addition (of floating point
numbers) is not commutative either. And many, many other things that
are different from our perfect abstractions when you try to model
infinite objects in a finite machine. I definitely do not consider
this a bug:
sage: K1 = GF(8,'x
This one is also fun:
sage: K = GF(8, 'a')
sage: K(1) == ZZ(1) == QQ(1)
True
sage: K(1) == QQ(1)
False
--
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+
Another instance of our non-transitive equality
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1.one() == 1 == K2.one()
True
On 17/09/15 07:19, Nathann Cohen wrote:
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
Nathann
On 17 September 2015 at 12:15, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
>
> On 17/09/15 06:53, Simon King wrote:
>>
>> Hi!
>>
>> On 2015-09-17, Jero
On 17/09/15 06:53, Simon King wrote:
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
On 2015-09-16 16:43, Jean-Pierre Flori wrote:
Hi,
I guess one of the issue is that there is no canonical map between two
different representations of the same finite field (so no coercion).
The question is real
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>> Hi,
>>
>> I guess one of the issue is that there is no canonical map between two
>> different representations of the same finite field (so no coercion).
>
> The question is really: is the map between repre
On Sunday, February 22, 2015 at 1:03:54 PM UTC+1, Burcin Erocal wrote:
>
> Pynac already calls the Python comparison function if both are
> pyobjects. In this case, infinity and constants are not pyobjects. They
> are a basic class as in mul, add, symbol, etc.
>
The code need not be fast so my s
On Sun, 22 Feb 2015 03:17:13 -0800 (PST)
Volker Braun wrote:
> Just to tell you what you already know, the symbolic ring is the
> parent of last resort if there is nothing more specific. So its to be
> expected that you don't have any canonical maps elsewhere.
>
> Pynac should probably unwind th
Just to tell you what you already know, the symbolic ring is the parent of
last resort if there is nothing more specific. So its to be expected that
you don't have any canonical maps elsewhere.
Pynac should probably unwind the comparison of two wrapped (non-symbolic)
python objects to the compa
Hi,
Just to tell that no later than two days ago, I had a bug in my code that
was caused by
bool(SR(0) < Infinity) returning False.
I was about to post a message to sage-devel, but thanks to your post, I
realize this is a known issue.
Best wishes,
Eric.
--
You received this message becau
Sorry, I press enter to fast. There is a coercion problem. The result
of division of GF(5)['x'] by ZZ should live in GF(5)['x']. But right
now the coercion model thinks that it should go to the fraction
field... (see the example in my first mail).
Is there a ticket related to that issue? Does anyb
Ok, you are talking about 1.0 argument, which should lower the precision to
53 bit.
We should probably use all inexact (floating-point) arguments to decide the
precision, not just the first one.
On Friday, October 10, 2014 12:32:29 PM UTC+1, Jeroen Demeyer wrote:
>
> On 2014-10-10 12:38, Volk
On 2014-10-10 12:38, Volker Braun wrote:
This is probably what you wanted:
sage: bessel_Y(RealField(200)(1), 1.0, hold=True)
-0.7812128213002887165471504796482054990639071644460784383
No, that's not what I wanted. It doesn't make sense to return an answer
which is more precise than the inpu
This is probably what you wanted:
sage: bessel_Y(RealField(200)(1), 1.0, hold=True)
-0.7812128213002887165471504796482054990639071644460784383
On Friday, October 10, 2014 10:25:57 AM UTC+1, Jeroen Demeyer wrote:
>
> Could somebody who knows about numerical evaluation of symbolic
> functions
On 2014-10-08 04:29, Nils Bruin wrote:
sage: A = RealField(50)
sage: B = RealField(100)
sage: R. = A[]
sage: a = A(-1)
sage: c = R(a)
sage: b = B(1+2^-80)
sage: a + b # with your change this would have higher precision
sage: c + b # with your change this addition would happen in R and hence
with
Consider
sage: a = RR(pi/4); a
0.785398163397448
sage: b = RealField(100)(arctan(1/2) + arctan(1/3)); b
0.78539816339744830961566084582
sage: a - b
0.000
sage: a._sub_(b)
-3.06161699786838e-17
I don't know that that's an improvement. The problem is that one
simply doesn't have the pre
On Tuesday, October 7, 2014 1:33:19 PM UTC-7, Jeroen Demeyer wrote:
>
>
> > The ramifications for coercion discovery are also quite big:
> No, you're understanding it wrong. The parent of the result of any
> computation would be the same as now. The result of adding 2 RealNumbers
> with differin
On Tuesday, October 7, 2014 9:32:56 PM UTC+1, Jeroen Demeyer wrote:
>
> I would argue that the result would be *more* predictable and certainly
> more accurate than now.
>
How do you explain somebody when precision is lost due to the extra
rounding for coercion?
Is composition of "compatible"
On 2014-10-07 17:45, Nils Bruin wrote:
Another conclusion one can draw from that is that floats got modelled
wrong: that precision is a property of the element, not the parent.
That cannot really work, since we really want RealField(100)(1/3) to be
different from RealField(53)(1/3)
That's a v
On 2014-10-07 19:03, Volker Braun wrote:
IMHO way too complicated, and too few people understand coercion as it
is already. I'd rather have one unnecessary rounding than ring
operations where I can't predict the outcome without reading the source
first.
I would argue that the result would be *mor
On Tuesday, October 7, 2014 7:14:57 PM UTC+1, Nils Bruin wrote:
>
> I'd say in p-adics elements simply carry around their own precision. The
> different parents simply supply a cap on how big that precision can be.
>
Thats just another way of saying that they implement precision both in the
pare
Hey Jeroen,
My understanding of why we coerce to the lower precision is to have at
least the required amount of significant figures, and I'd guess doing
things this way is more numberically stable. In the same vein, I think
we're better off just letting the coercion to go through normally rat
On Tuesday, October 7, 2014 10:03:54 AM UTC-7, Volker Braun wrote:
>
> p-adics are even more weird, they coerce in the wrong direction. And, to
> patch up that mistake, have a precision in the parent and another precision
> in the element:
>
I'd say in p-adics elements simply carry around their
IMHO way too complicated, and too few people understand coercion as it is
already. I'd rather have one unnecessary rounding than ring operations
where I can't predict the outcome without reading the source first.
The only takeaway is: If you care about the last decimal places then start
by def
On Tuesday, October 7, 2014 7:03:54 AM UTC-7, Jeroen Demeyer wrote:
>
> Hello,
>
> Consider the following Sage session:
>
> sage: a = RR(-1)
> sage: b = 1.0001
> sage: a + b
> 0.000
> sage: a._add_(b)
> 1.03397576569128e-24
>
> Here, the coercion model makes
Hi Travis,
On 2014-06-22, Travis Scrimshaw wrote:
> Now startup a new session:
>
> sage: SGA4 = SymmetricGroupAlgebra(QQ, 4)
> sage: SGA3 = SymmetricGroupAlgebra(QQ, 3)
> sage: SGA3.has_coerce_map_from(SGA4)
> False
> sage: lift = SGA4.module_morphism(lambda x: SGA3.zero(), codomain=SGA3)
> sage:
Hi,
I just opened a ticket on http://trac.sagemath.org/ticket/15821#ticket
Aladin
On Wednesday, February 12, 2014 6:50:01 PM UTC-8, Aladin VIRMAUX wrote:
>
> Hello everyone,
>
> here is a bug that is maybe related to coercion system to Integers in sage:
>
> sage: W = Words(4)
> sage: W([1,2])
Hi Vincent,
On 2014-02-13, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> Words currently do not fit well with category... (for example they do
> not inherit from parent).
If it is supposed to behave like an object in a sub-category of Sets,
then it is a quite severe bug not to derive it
Hi Volker,
On 2013-10-05, Volker Braun wrote:
> I think that presents again a chicken and egg problem. We build the
> reference manual first, and then make its index available (via intersphinx)
> to the other doc builders. In order to link back we would have to first
> build the tutorial (igno
On Saturday, October 5, 2013 8:44:55 PM UTC+1, Simon King wrote:
> Nevertheless, is a link "reference manual -> thematic tutorial" easily
> possible? A link "thematic tutorial -> reference manual" is ease, it is
> enough to write :meth:`sage.structure.parent.Parent.register_coercion` and
> so o
Hi Volker,
On 2013-10-05, Volker Braun wrote:
> Use ".. automethod:: _coerce_map_from_" to force docbuild of the underscore
> methods that should be in the reference manual. See, for example,
> sage.structure.parent.Parent.__init__
Thank you! This is a good idea (and I just see that `_coerce_m
Use ".. automethod:: _coerce_map_from_" to force docbuild of the underscore
methods that should be in the reference manual. See, for example,
sage.structure.parent.Parent.__init__
On Saturday, October 5, 2013 8:29:24 PM UTC+1, Simon King wrote:
>
> Hi!
>
> This post has two purposes, namely
On 11/5/12 11:56 PM, Rob Beezer wrote:
Like Volker, I'd like to keep the matrix dimension checks in the "over
eager" error-checking. While building the class for vector space
morphisms (aka linear transformations), I discovered several bogus
doctests for free module morphisms which were passing
On Saturday, November 3, 2012 8:44:19 AM UTC-7, jason wrote:
>
> Rob Beezer, what do you think?
>
>
Well, my first thought is that I am glad you and Volker are getting to the
bottom of this. I knew scalars were only working "on the wrong side," but
I'd been under the (mistaken) impression thi
On Saturday, November 3, 2012 4:23:57 PM UTC, jason wrote:
> That's how analogous is_* commands are defined
Yes, you are right. I got myself confused there.
I agree with your patch except that it might be nice to still check the
matrix dimensions if it is a matrix. Just to give a more human
On 11/3/12 11:01 AM, Volker Braun wrote:
Isn't this the real issue:
def is_VectorSpaceMorphism(x):
return isinstance(x, VectorSpaceMorphism)
With the category stuff the correct check is whether VectorSpaceMorphism
in x.__class__.__mro__. Is there a better way to express this? Whats the
...
Isn't this the real issue:
def is_VectorSpaceMorphism(x):
return isinstance(x, VectorSpaceMorphism)
With the category stuff the correct check is whether VectorSpaceMorphism in
x.__class__.__mro__. Is there a better way to express this? Whats the
..._with_category class if I want an isinstan
On 11/3/12 9:56 AM, Jason Grout wrote:
sage: phi = (ZZ^2).hom(matrix(ZZ,2,[1..4]))
sage: h = (RR^2).hom(matrix(RR, 2, [1..4]))
sage: type(phi.parent())
sage.modules.free_module_homspace.FreeModuleHomspace_with_category
sage: type(h.parent())
sage.modules.vector_space_homspace.VectorSpaceHomspace_
On 11/3/12 9:33 AM, Volker Braun wrote:
On Saturday, November 3, 2012 1:53:24 PM UTC, jason wrote:
sage: h = linear_transformation(RR^2, RR^2, matrix(RR, [[0, 1], [2,
3]]))
sage: h*3 #works fine
This does not involve coercion. h.__mul__(3) figures out that 3 is
scalar multiplicatio
On Saturday, November 3, 2012 1:53:24 PM UTC, jason wrote:
> sage: h = linear_transformation(RR^2, RR^2, matrix(RR, [[0, 1], [2, 3]]))
> sage: h*3 #works fine
>
This does not involve coercion. h.__mul__(3) figures out that 3 is scalar
multiplication and handles it.
sage: 3*h #doesn't work
>
I have in the meantime tracked this to ComplexIntervalField and
RealIntervalField both overriding __call__ in a way that seems to preempt
usual coercion from working.
Note that CIF(s2) fails, but CIF.coerce(s2) works just fine. It seems that
CIF/RIF just end up calling
ComplexIntervalFieldEleme
The above of course modulo the inconsistency's python allows. Since defining
both:
class C(A,B):
class D(B,A):
don't give errors yet, but it does make it impossible to inherit from C and
D wich might be annoying.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsub
I was also thinking about checking if the whole subcategory category graph
is also a valid python inheritance graph. This so that inconsistencies
cannot exist silently. But I guess that is also automatically checked by
python as soon as you construct an explicit parent in each category so this
On Mon, Sep 05, 2011 at 02:58:52PM -0700, Maarten Derickx wrote:
>Hmmm maybe it would be worth using the same algorithm as python for
>determining the inheretance order for categories.
I assume you mean the algorithm that translates the classes
inheritance diagram into the method resolutio
Hi Maarten,
On 5 Sep., 23:58, Maarten Derickx wrote:
> Hmmm maybe it would be worth using the same algorithm as python for
>
> determining the inheretance order for categories.
In the first place, the mathematical inheritances must be obeyed.
However, mathematically, it makes no difference whet
On Monday, September 5, 2011 4:49:25 PM UTC+2, Simon King wrote:
>
>
> And I learnt, while working at #10667: If several super categories are
> returned, then their order matters a lot. The order is essential,
> because otherwise Python can not find a consistent method resolution
> order when
Hi Volker,
On 5 Sep., 15:53, Volker Braun wrote:
> def super_categories(self):
> from sage.categories.all import AdditiveMagmas, Modules
> R = self.base_ring()
> return [Modules(R), AdditiveMagmas()]
You have
sage: Modules(ZZ).is_subcategory(AdditiveMagmas())
True
Mike is correct about your first question: your confusion is between
coercion maps and conversion maps.
The function you're looking for is _mpoly_base_ring, which is written in
sage.rings.polynomial.multi_polynomial_ring_generic.pyx
David
On Wed, Feb 16, 2011 at 13:06, mmarco wrote:
> I already
On Wed, Feb 16, 2011 at 7:06 PM, mmarco wrote:
> I already new all that, but my question would be: "why
> S.has_coerce_map_from(R) returns False?"
Because S(r) is doing a "converion" rather than a "coercion".
Coercion is implicit and happens when doing arithmetic.
S.has_convert_map_from(R) should
I already new all that, but my question would be: "why
S.has_coerce_map_from(R) returns False?"
And the second question is "is there a command (or an easy way to
implement it) to recover QQ[x,y,z] from QQ[x][y][z] or any other
similar situation?"
I know how to deal with these cases by hand, but i
I think Robert's said it fairly well. Which is good, since I'll have
spotty internet for the next couple weeks, and my battery is about to
run out.
On 5/15/10, Robert Bradshaw wrote:
> On May 14, 2010, at 11:13 AM, Simon King wrote:
>
>> Hi Robert!
>>
>> On 14 Mai, 18:34, Robert Bradshaw
>> wro
On May 14, 2010, at 11:13 AM, Simon King wrote:
Hi Robert!
On 14 Mai, 18:34, Robert Bradshaw
wrote:
1. Do you agree this is a bug?
The p-adic fields are of capped precision, not set precision, but
each
element remembers its own actual precision, so this is why the
coercion goes in that d
Would the following be what you want?
sage: R1. = Zp(5,prec=20)[]
sage: R2 = Qp(5,prec=40)
sage: R2(1)+a
(1 + O(5^20))*a + (1 + O(5^40))
This results when one changes the merge method (and makes fraction
field functor and completion functor commute).
Cheers,
Simon
--
To post to this group, sen
Hi Robert!
On 14 Mai, 18:34, Robert Bradshaw
wrote:
> > 1. Do you agree this is a bug?
>
> The p-adic fields are of capped precision, not set precision, but each
> element remembers its own actual precision, so this is why the
> coercion goes in that direction, and I don't think its a bug.
W
first, you might be interested by this:
L = zip(Vars,p.lm().exponents()[0].sparse_iter())
its faster but still not enough...
then you might look at http://trac.sagemath.org/sage_trac/ticket/7587,
apply it ( review it ;) )
and do
L = [(Vars[i],e) for i,e in enumerate(p.lm().exponents
(as_ETuples=
Hi!
On 2 Dez., 17:47, Simon King wrote:
[...]
> IIRC, I tried various other methods (without strings), but they were
> all slower. However, I don't remember any concrete examples.
> So, it would help me if you commented
> onhttp://trac.sagemath.org/sage_trac/ticket/7580
> what I should try inste
Hi William!
On 2 Dez., 17:26, William Stein wrote:
...
> I'm not surprised. Looking through the code, its use of strings and
> regular expressions is fairly delicate -- I wouldn't use regular
> expressions at all to implement the same functionality (and more). But
> I'm not rewriting anything (t
On Wed, Dec 2, 2009 at 4:36 AM, Nathann Cohen wrote:
> Hello everybody
>
> Concerning the use of InfinitePolynomialRing in Sage, it was discussed
> in another thread and I since wrote a patch (#7561) to change it. As
> mentionned, I need nothing of what this class has been built for, and
> n
Hello everybody
Concerning the use of InfinitePolynomialRing in Sage, it was discussed
in another thread and I since wrote a patch (#7561) to change it. As
mentionned, I need nothing of what this class has been built for, and
now that it is replaced with plain "var", it is a thousand times
f
Hi!
On Dec 2, 6:40 am, William Stein wrote:
> On Wed, Dec 2, 2009 at 1:01 AM, Mike Hansen wrote:
> > On Wed, Dec 2, 2009 at 12:57 PM, William Stein wrote:
> >> WTF? Regular expressions?!?!
There are regular expressions in InfinitePolynomialRing, but (at least
after applying my patch) I don't
On Wed, Dec 2, 2009 at 1:01 AM, Mike Hansen wrote:
> On Wed, Dec 2, 2009 at 12:57 PM, William Stein wrote:
>> WTF? Regular expressions?!?!
>
> The following messages are probably relevant for the fast conversion
> between singular polynomial rings:
Thanks. There's also regular expression stuf
On Wed, Dec 2, 2009 at 12:57 PM, William Stein wrote:
> WTF? Regular expressions?!?!
The following messages are probably relevant for the fast conversion
between singular polynomial rings:
On Sat, Oct 18, 2008 at 2:55 AM, Michael Brickenstein
wrote:
> In Singular the same thing is essentially
WTF? Regular expressions?!?!
On Tue, Dec 1, 2009 at 6:57 PM, Simon King wrote:
> Hi!
>
> Here is a first ticket, with patch:
> http://trac.sagemath.org/sage_trac/ticket/7578
>
> It reduces the computation time of the original example of this thread
> to the time that is needed to convert the un
Hi!
Here is a first ticket, with patch:
http://trac.sagemath.org/sage_trac/ticket/7578
It reduces the computation time of the original example of this thread
to the time that is needed to convert the underlying finite
polynomials. Hence, as long as the conversion does not improve, it
seems to m
On 1 Dez., 21:57, Nick Alexander wrote:
[...]
> I'm certain you are aware, but there is an art to optimizing regular
> expressions. It might be that a tuned regex is necessary, rather than
> avoiding a regex altogether.
Can you suggest some manual that can teach me about optimizing regular
e
Hi!
I just found that part of the problem is coercion -- or actually
conversion -- for classical polynomial rings:
sage: R1 = PolynomialRing(QQ,'x',10001)
sage: R2 = PolynomialRing(QQ,'x',10002)
sage: x1 = R1('x1')
sage: %prun a = R2(x1)
160026 function calls in 5.073 CPU sec
> Nevertheless, the regular expression business isn't good either. I'll
> see what I can do -- recent sage-devel/sage-support threads indicated
> some improvements.
I'm certain you are aware, but there is an art to optimizing regular
expressions. It might be that a tuned regex is necessary, rat
Hi Martin!
On 1 Dez., 20:30, Martin Albrecht
wrote:
[...]
> Sure, but up to 50 seconds for a simple coercion seems way way too much even
> in that case.
Agreed. Let's try to find out what happens here.
My first thought was that it is due to the huge polynomial rings. But
the following seems to
On Tuesday 01 December 2009, Simon King wrote:
> Hi Martin!
>
> On 1 Dez., 19:02, Martin Albrecht
>
> wrote:
> > Hi there,
> >
> > the following code is really, really really (REALLY!) slow:
>
> Well, the default implementation creates a polynomial ring with 1
> variables in the background
Hi Robert!
On 1 Dez., 19:18, Robert Bradshaw
wrote:
[...]
> Ouch, that is pretty bad. Looks like something changed in 4.2, it's
> doing a huge amount of regular expressions stuff...
It does a lot of regular expressions in the background. I did not see
a way to do it better. However, the code d
Hi Martin!
On 1 Dez., 19:02, Martin Albrecht
wrote:
> Hi there,
>
> the following code is really, really really (REALLY!) slow:
Well, the default implementation creates a polynomial ring with 1
variables in the background when you say x[1], and another ring
with 10001 variables if you th
William Stein wrote:
> I just want to personally thank you for your comments in this thread
> (and others!). I think they were extremely helpful and clarifying, at
> least to me, in understanding the issue being discussed and coming up
> with several examples to... show you are in fact right.
On Tue, Oct 27, 2009 at 9:04 PM, Nick Alexander wrote:
>
>> Note that we already do that for things like parametric_plot,
>> derivatives, etc.
>
> And it's a continual pain in the ass. Telling the difference between
> a list, tuple, sequence, iterator, vector, multiple arguments, etc...
> in Pyt
Nick Alexander wrote:
>> Note that we already do that for things like parametric_plot,
>> derivatives, etc.
>
> And it's a continual pain in the ass. Telling the difference between
> a list, tuple, sequence, iterator, vector, multiple arguments, etc...
> in Python, it's just all so inconsist
1 - 100 of 228 matches
Mail list logo
