Activity
From 30 Apr 2016 to 29 May 2016
25 May 2016
- 17:01 Slug #881: ReadExpr is too slow on large polys
- Using the profiler on a linux box I noticed that @DistrMPolyInlPP::myPushFront@ was using surprisingly much time. I ...
- 16:57 Feature #885: IsIrred3: fast 3-way irred test (returning bool3)
- The idea of @IsIrred3@ was created because of some computations Mario needed to do with multivariate polynomials, so ...
- 11:13 Feature #885 (In Progress): IsIrred3: fast 3-way irred test (returning bool3)
- Some questions:
* *(A)* what should the function be called? Is @IsIrred3@ a reasonable name?
* *(B)* what should t... - 16:49 Design #846: IsIrred: correct design?
- The simplest design is to make @IsIrred@ call @IsIrred3@; this somehow equates calling @IsIrred3@ to handling the tri...
- 13:43 Design #846 (In Progress): IsIrred: correct design?
- I think a first version of @IsIrred@ should give error if the ring is a field; if it turns out that this is inconveni...
24 May 2016
- 17:27 Feature #885 (In Progress): IsIrred3: fast 3-way irred test (returning bool3)
- Implement an irreducibility test @IsIrred3@ which is guaranteed to be fast, but returns a @bool3@.
- 15:25 Slug #884: DistrMPolyInlPP::myPushFront and DistrMPolyInlPP::myPushBack inefficient if arg is a PP
- I wrote a special reading fn for polynomials (using a "private" linearization). It was not as fast as I hoped, and p...
- 15:20 Slug #884 (New): DistrMPolyInlPP::myPushFront and DistrMPolyInlPP::myPushBack inefficient if arg is a PP
- In the class @DistrMPolyInlPP@ the mem fns @myPushFront@ and myPushBack@ can accept raw coeff and raw pp, *BUT* the i...
18 May 2016
- 13:44 Slug #881 (Resolved): ReadExpr is too slow on large polys
- I have modified @ReadExprInSparsePolyRing@ so that sums of terms are handled specially: the terms are simply appended...
11 May 2016
- 14:48 Slug #881: ReadExpr is too slow on large polys
- I reran the test to read Mario's polynomial: now it takes about 0.4s (with the "wrong" term-ordering), and about 0.25...
- 14:32 Slug #881: ReadExpr is too slow on large polys
- I have now finished the main changes to @DistrMPolyInlPP@, and especially @myAddClear@. Time to read a correctly ord...
- 12:09 Slug #881: ReadExpr is too slow on large polys
- I wrote a very hacked version which uses @PushBack@, and it went considerably faster (but it also gave SEGV on some e...
10 May 2016
- 16:36 Slug #881: ReadExpr is too slow on large polys
- I have already implemented (and checked in) a version which uses geobuckets when the ring is a sparsepolyring.
Mar... - 16:19 Slug #881: ReadExpr is too slow on large polys
- John Abbott wrote:
> I have done a quick profile of the current version of the code (using the _ad hoc_ impl with @s... - 15:33 Slug #881 (In Progress): ReadExpr is too slow on large polys
- I have done a quick profile of the current version of the code (using the _ad hoc_ impl with @std::map@). Now most (...
- 13:25 Slug #881: ReadExpr is too slow on large polys
- I have hacked the @ReadExpr@ code so that it produces a table of symbols (of type @std::map@).
This improved the rea...
09 May 2016
- 22:10 Slug #882: Impl faster multiplication for DUP (dense univariate polys)
- I also tried implementing a method which uses fast integer multiplication in GMP.
Evaluate both polys at 1000000 (... - 22:07 Slug #882: Impl faster multiplication for DUP (dense univariate polys)
- I made a very _ad hoc_ impl of karatsuba when I was in Osnabrueck as I wanted to get an idea of when cross-over might...
- 22:05 Slug #882 (New): Impl faster multiplication for DUP (dense univariate polys)
- Christof wanted faster multiplication for DUPs.
He suggested implementing karatsuba's method. - 21:49 Slug #881: ReadExpr is too slow on large polys
- I did a quick test:...
- 21:23 Slug #881: ReadExpr is too slow on large polys
- Since my "stupid" MacBook cannot profile, I can only guess that reading a symbol is probably quite costly (see line 7...
- 21:13 Slug #881: ReadExpr is too slow on large polys
- I have implemented a first improvement by implementing a new fn @ReadExprInSparsePolyRing@ which uses geobuckets to s...
- 21:10 Slug #881 (Closed): ReadExpr is too slow on large polys
- Recently Mario has passed me some large polys in their printed form (_i.e._ sum of terms). Reading them by pasting t...
- 20:51 Slug #874: factor: too slow on largish multivariate poly
- I have implemented a prototype "heuristic" irred test which returns a @bool3@.
First it checks for a non-triv comm...
06 May 2016
- 16:43 Slug #866: implicit, ImplicitHypersurface: improve output verification
- I have not yet had time to look at your horner code. Anyway, I would expect it work fairly well provided the "variab...
03 May 2016
- 13:14 Slug #874: factor: too slow on largish multivariate poly
- Mario has just sent me an even bigger polynomial to try: 100 indets, about 127000 terms, total degree 9.
He also m... - 10:50 Slug #874 (In Progress): factor: too slow on largish multivariate poly
- Computing all contents takes about 44s; and computing contents wrt all indets which appear just linearly takes about ...
- 10:42 Slug #874: factor: too slow on largish multivariate poly
- Mario has given me an example poly. The poly ring has 84 indets; the poly itself uses 69 indets, and has about 6800 ...
- 10:37 Slug #874 (In Progress): factor: too slow on largish multivariate poly
- Mario generates lots of multivariate polys (over @QQ@); most of them are irreducible. He reports that factorization ...
- 10:34 Support #861 (In Progress): Janet basis code: TmpJB files give some problems with C++11 (using CLANG/LLVM)
- Mario has given me an updated version of his code. He has used the @__cplusplus@ preprocessor variable to have code ...
Also available in: Atom