>
> I did think about this... One would then have to find gcd's between
> all pairs of (non-prime) factors which would get expensive very
> quickly compared to a single gcd of the product.
I am not sure this is so clear cut in general. But since your example
is in a sense the worst possible cas
On May 29, 2007, at 12:50 AM, Michel wrote:
> Hi,
>
> Thanks for taking the time to make up this example. I think it is
> good to put it in the documentation.
> Yes you can break factorcaching (with auto_reduce=False) the way you
> do it. ***But***
> let me point out that by rewriting your examp
Hi,
Thanks for taking the time to make up this example. I think it is
good to put it in the documentation.
Yes you can break factorcaching (with auto_reduce=False) the way you
do it. ***But***
let me point out that by rewriting your example only slightly it
becomes *much* faster than the current
I don't think you want to them as doctests, they take dozens of
minutes to run! (That is, for the cached rings which take 1 times
longer to compute.) Ideally this issue can be fixed, but I'm not sure
how...
- Robert
On May 28, 2007, at 4:35 PM, Nick Alexander wrote:
> Robert Bradshaw
Robert Bradshaw <[EMAIL PROTECTED]> writes:
> I'm kind of late jumping into this thread, but I have some concerns.
> Unless the factorization is known completely (or gcd's are taken on
> the unknown part), I still think this can lead to combinatorial
> explosion fairly quickly. For example,
I'm kind of late jumping into this thread, but I have some concerns.
Unless the factorization is known completely (or gcd's are taken on
the unknown part), I still think this can lead to combinatorial
explosion fairly quickly. For example,
sage: from sage.rings.fraction_field_cache import
On May 28, 2007, at 06:23 , David Harvey wrote:
> On May 28, 2007, at 4:36 AM, Michel wrote:
[snip]
> I think I would generally support including the code you are
> proposing, assuming a referee is happy with the code. (I insist
> however on the spelling "caching" rather than "cacheing" :-))
Eww
On May 27, 2007, at 11:47 , David Harvey wrote:
> On May 27, 2007, at 2:21 PM, Michel wrote:
[snip]
> Well I have another idea, I'm not sure to what extent this is already
> implemented in your factor_cache.pyx, or to what extent it even makes
> sense. (I haven't actually looked at your code yet.
On May 28, 2007, at 2:02 PM, Michel wrote:
> This being said I actually want FractionField_cache to be optional so
> that I can improve
> it without disrupting anything else. Om my sage installation I have
> given the FractionField method an extra optional parameter 'cache='
> which
> when true
>
> I think I would generally support including the code you are
> proposing, assuming a referee is happy with the code. (I insist
> however on the spelling "caching" rather than "cacheing" :-))
>
No problem. For me cache is a french word. Hence cacheing. But Google
seems to favor caching by far.
Michel <[EMAIL PROTECTED]> writes:
> Question: What should I do now? I think the implementation of
> FractionField_cache
> improves upon the implementation of FractionField_generic. Please
> give some feedback.
Hi Michel,
I will referee this patch. Since it is a little involved, I may take
a f
On May 28, 2007, at 4:36 AM, Michel wrote:
>> Does this idea
>> only make sense over division rings? Because it is sometimes nice to
>> do integer arithmetic and have everything factored, as well.
>
> The factor cache works of course for non-fields. There is not much
> point
> taking the fracti
> I vote +1 to this idea, because it is more modular. Does this idea
> only make sense over division rings? Because it is sometimes nice to
> do integer arithmetic and have everything factored, as well.
>
> I will referee such a patch, if needed.
Hi,
I would very much prefer the patch to be re
> R = some ring
> S = FactorCache(R)
>
> So now S is a ring, whose elements are products of elements of R.
> Multiplication does the obvious thing, addition and subtraction I
> suppose checks for common factors and just expands the rest? (I suppose
> this is very much like the Factorization class
David Harvey <[EMAIL PROTECTED]> writes:
> On May 27, 2007, at 2:21 PM, Michel wrote:
>
>>> And I assume if you have a fraction a/b, where the system has
>>> remembered some factorisation information about b, then if you compute
>>> 1/(a/b) it throws that information away?
>>>
>> No it does not t
On May 27, 2007, at 2:21 PM, Michel wrote:
>> And I assume if you have a fraction a/b, where the system has
>> remembered some factorisation information about b, then if you compute
>> 1/(a/b) it throws that information away?
>>
> No it does not throw that information away. Internally elements o
> case where you evaluate for example a polynomial (or rational
> function) with a large number of terms
> on fractions.
And actually if you have a slow gcd algorithm you
don't need a large number of terms before things become
really very slow.
Michel
--~--~-~--~~~--
On May 27, 7:28 pm, David Harvey <[EMAIL PROTECTED]> wrote:
> What happens if I add a/(bc) to d/(be)? Does the implementation attempt
> to recognise that there is a common factor in the denominators? (i.e.
> assuming the system does not already know about the factor of b.)
The implementation does
What happens if I add a/(bc) to d/(be)? Does the implementation attempt
to recognise that there is a common factor in the denominators? (i.e.
assuming the system does not already know about the factor of b.) Or do
I just end up with the numerator a(be) + d(bc) and the "factorised"
denomina
19 matches
Mail list logo
