Re: Significant slow-down with Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg96007] Re: Significant slow-down with Mathematica
- From: Albert Retey <awnl at gmx-topmail.de>
- Date: Sun, 1 Feb 2009 04:40:11 -0500 (EST)
- References: <200901291059.FAA18289@smc.vnet.net> <A4E4DA09141B9D419606C6D67A4078530915CE@BEL1EXCLV01.adcorp.kla-tencor.com> <glvkiv$e7i$1@smc.vnet.net>
Hi,
> The difference can be arbitrarily large in either direction.
> Here is an example where the "NumberField" method is faster
> by a factor of 7700, and the automatic method selection does
> pick the faster method.
>
> a=Root[#^3-#-1&, 1];
> b=2^(1/6);
> SeedRandom[1];
> e=Sum[RandomInteger[{-100, 100}] a^i b^j, {i, 0, 2}, {j, 0, 5}];
>
> In[5]:= RootReduce[e, Method->"Recursive"]//Timing//InputForm
>
> Out[5]//InputForm=
> {1506.076042, Root[50505808949809153821722941914635112509348143 +
> 365741513511248529376047597425831003016630*#1 +
> 1473003695813636128968413692365061482423*#1^2 -
> 3359272977645340460068844677894763898*#1^3 -
> 2268307929809600173042830013292805*#1^4 -
> 341043359192920761513389626609458*#1^5 -
> 376075465654830707036759067602*
> #1^6 + 4778789762834862609186205542*#1^7 + 17180009746242542883294492*
> #1^8 - 158122155627340901637452*#1^9 - 551174348020538766903*#1^10 +
> 5346473922554086776*#1^11 + 36128131851043581*#1^12 +
> 68316117333306*#1^13 - 84751803045*#1^14 - 450805238*#1^15 -
> 1710*#1^16 +
> 1392*#1^17 + #1^18 & , 1, 0]}
>
> In[6]:= RootReduce[e]//Timing//InputForm
>
> Out[6]//InputForm=
> {0.19397000000008335, Root[50505808949809153821722941914635112509348143 +
> 365741513511248529376047597425831003016630*#1 +
> 1473003695813636128968413692365061482423*#1^2 -
> 3359272977645340460068844677894763898*#1^3 -
> 2268307929809600173042830013292805*#1^4 -
> 341043359192920761513389626609458*#1^5 -
> 376075465654830707036759067602*
> #1^6 + 4778789762834862609186205542*#1^7 + 17180009746242542883294492*
> #1^8 - 158122155627340901637452*#1^9 - 551174348020538766903*#1^10 +
> 5346473922554086776*#1^11 + 36128131851043581*#1^12 +
> 68316117333306*#1^13 - 84751803045*#1^14 - 450805238*#1^15 -
> 1710*#1^16 +
> 1392*#1^17 + #1^18 & , 1, 0]}
>
> This example is actually pretty close to the method crossover
> in the current heuristic. If I change b to 2^(1/8) the method
> automatically selected is "Recursive", even though "NumberField"
> is much faster for that example too. Unfortunately I wasn't
> able to find a better way to decide a priori which method will
> be faster...
wouldn't that be an example where it would make more sense to start both
methods in extra threads and stop the one which takes longer when the
faster has finished? Especially with more than one processor one would
gain a lot, and even on a single processor one would in average only
wait twice the shorter runtime, which is in average probably much better
than anything that an a priori decision which sometimes chooses the
wrong method would achieve...
albert