This is now trac 17692
--
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@goo
On Thursday, January 29, 2015 at 10:52:32 AM UTC-8, Stefan wrote:
>
> No coercion is still faster than a fast coercion.
>
The line "1/self" occurs INSIDE the __invert__ special method of
> element.pyx.
>
> Should I open a ticket to replace that 1 by self.parent().one() ?
>
Yes, that seems like a
On Wednesday, January 28, 2015 at 4:45:54 PM UTC-6, Simon King wrote:
>
> Hi Stefan,
>
> On 2015-01-28, Stefan > wrote:
> > The question, now, is why the coercion system is invoked at all: I'm
> doing
> > arithmetic within my own ring. The culprit, I guess, is the expression
> > 1/self in el
Hi Stefan,
On 2015-01-28, Stefan wrote:
> The question, now, is why the coercion system is invoked at all: I'm doing
> arithmetic within my own ring. The culprit, I guess, is the expression
> 1/self in element.pyx.
>
> Does a ring keep track of its own multiplicative identity element?
It looks
> The question, now, is why the coercion system is invoked at all: I'm doing
> arithmetic within my own ring. The culprit, I guess, is the expression
> 1/self in element.pyx.
>
> Does a ring keep track of its own multiplicative identity element?
>
A: yes, it does. If I replace, in element.pyx
> No. The coercion system has a cache of its own. It does keep strong
> references to the coercion maps. They don't have homsets, though. The
> problem might be that you keep extracting coercion maps from the coercion
> system:
>
> if all(R.has_coerce_map_from(S) for R in self._rings):
On Wednesday, January 28, 2015 at 3:14:33 AM UTC-8, vdelecroix wrote:
>
> Agreed. But these dramatic slowdown are for me a critical drawback.
> But of course preferable than the previous state.
>
Packaging coercions into a map has never been "good" for performance.
There's a good chance that if
2015-01-28 10:02 UTC+01:00, Simon King :
> Hi Vincent,
>
> On 2015-01-28, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
>> This is really annoying from the user perspective
>
> I strongly disagree. It used to be very annoying from the user
> perspective that seemingly harmless computations r
Hi Vincent,
On 2015-01-28, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> This is really annoying from the user perspective
I strongly disagree. It used to be very annoying from the user
perspective that seemingly harmless computations resulted in caches
filling up because for some silly
On Wednesday, January 28, 2015 at 12:03:00 AM UTC-8, vdelecroix wrote:
> This is really annoying from the user perspective
Not nearly as annoying as the unavoidable memory leaks we had before,
though. Note that most internal structure types do not suffer from
slowdowns, so you could study them
2015-01-28 8:00 UTC+01:00, Simon King :
> Hi Nils,
>
> On 2015-01-27, Nils Bruin wrote:
>> It suggests there is a homset that gets created and forgotten every time.
>>
>> You should probably dig into the callgraph to see who is triggering this
>> call. It suggests to me that between 5.12 and 6.4,
Hi Nils,
On 2015-01-27, Nils Bruin wrote:
> It suggests there is a homset that gets created and forgotten every time.
> You should probably dig into the callgraph to see who is triggering this
> call. It suggests to me that between 5.12 and 6.4, some memory leak in Hom
> caching was resolved.
12 matches
Mail list logo
