On Monday, September 18, 2017 at 3:08:11 AM UTC-7, Jeroen Demeyer wrote:
>
> On 2017-09-16 03:31, Nils Bruin wrote:
> > So if you're finding you can't put a "from A import a" at the top-level
> > and using it locally has noticeable cost (which can easily happen:
> > imports have a significant
On 2017-09-15 21:48, Travis Scrimshaw wrote:
On Friday, September 15, 2017 at 2:31:05 PM UTC-5, Maarten Derickx wrote:
Is it assymptotically 10% or is it 10% for the case in which you are
testing it? In the first case I would be surprised in the second
case it is not that weird.
On 2017-09-16 03:31, Nils Bruin wrote:
So if you're finding you can't put a "from A import a" at the top-level
and using it locally has noticeable cost (which can easily happen:
imports have a significant cost, even for modules that are already
present), then you could try to do a straight
Hi!
On 2017-09-16, Nils Bruin wrote:
> On Friday, September 15, 2017 at 2:28:06 PM UTC-7, Travis Scrimshaw wrote:
>>> Why are you proposing local imports? If python puts a performance penalty
>>> on them (in fact a significant performance penalty), they should be
>>> avoided,
On Friday, September 15, 2017 at 2:28:06 PM UTC-7, Travis Scrimshaw wrote:
>
>
> Why are you proposing local imports? If python puts a performance penalty
>> on them (in fact a significant performance penalty), they should be
>> avoided, no?
>>
>> It is a relatively small penalty, so when it is
Am Freitag, 15. September 2017 23:28:06 UTC+2 schrieb Travis Scrimshaw:
>
>
> Why are you proposing local imports? If python puts a performance penalty
>> on them (in fact a significant performance penalty), they should be
>> avoided, no?
>>
>> It is a relatively small penalty, so when it is
> Why are you proposing local imports? If python puts a performance penalty
> on them (in fact a significant performance penalty), they should be
> avoided, no?
>
> It is a relatively small penalty, so when it is not in a tight loop, it is
useful to break out of those cyclic imports (and has
I agree. Then I have to remove the local import.
Am Freitag, 15. September 2017 21:50:01 UTC+2 schrieb Travis Scrimshaw:
>
>
>
> On Friday, September 15, 2017 at 2:39:29 PM UTC-5, Martin R wrote:
>>
>> I haven't done any "professional" profiling, but it seems to me that the
>> 10% are stable,
Why are you proposing local imports? If python puts a performance penalty
on them (in fact a significant performance penalty), they should be
avoided, no?
It's not that I'm doing these optimizations just for fun. I am applying
many of these little maps very very very often. I am now
On Friday, September 15, 2017 at 2:39:29 PM UTC-5, Martin R wrote:
>
> I haven't done any "professional" profiling, but it seems to me that the
> 10% are stable, i.e., roughly independent of the size of the permutation.
>
> I just found a much faster alternative: simply bypass
On Friday, September 15, 2017 at 2:31:05 PM UTC-5, Maarten Derickx wrote:
>
> Is it assymptotically 10% or is it 10% for the case in which you are
> testing it? In the first case I would be surprised in the second case it is
> not that weird.
>
> See the late_import function in
I haven't done any "professional" profiling, but it seems to me that the
10% are stable, i.e., roughly independent of the size of the permutation.
I just found a much faster alternative: simply bypass MatrixSpace.matrix
completely:
entries = { (v-1, i): 1 for i, v in enumerate(self) }
Is it assymptotically 10% or is it 10% for the case in which you are
testing it? In the first case I would be surprised in the second case it is
not that weird.
See the late_import function in src/sage/rings/complex_field.py for how you
can speed up the import statement for the cyclic import
13 matches
Mail list logo