Project

General

Profile

Activity

From 10 May 2016 to 08 Jun 2016

08 Jun 2016

15:46 Bug #756: frobby (v0.9.0) does not compile with g++-4.8
Could you write the changes in the documentation @ExternalLibs-Frobby.txt@?
Anna Maria Bigatti

06 Jun 2016

15:37 Feature #206: Matrix equation solving: LinKer
For aesthetics: now changes sign to the LinKer matrix (so that the entries corresponding to the "pivots" are "1" inst... Anna Maria Bigatti
13:47 Support #887: My first compilations with clang
John Abbott wrote:
> I like the idea of adding some hints about compiling external libraries. I already have some n...
Anna Maria Bigatti
13:31 Support #887: My first compilations with clang
I like the idea of adding some hints about compiling external libraries. I already have some notes (but perhaps they... John Abbott
13:28 Support #887: My first compilations with clang
The warnings about infinite recursion correspond to code which has a comment @BUG BUG BUG@; I suppose I'll fix it wh... John Abbott

01 Jun 2016

17:05 Support #887: My first compilations with clang
CoCoA-5 running!!... Anna Maria Bigatti

31 May 2016

15:55 Support #887: My first compilations with clang
... another thing I don't really know the meaning of:... Anna Maria Bigatti
15:49 Support #887: My first compilations with clang
I expect this is well under control ;-)... Anna Maria Bigatti
15:27 Support #887: My first compilations with clang
... I'm not quite sure what this refers to...... Anna Maria Bigatti
15:16 Support #887: My first compilations with clang
*This is just a local problem with files not in cvs*
The file @/include/CoCoA/TmpSBStats.H@ contains the line...
Anna Maria Bigatti
15:14 Support #887 (Closed): My first compilations with clang
I've just updated to MacOS 10.11 (from 10.6).
Here I note the problems and remarks on the first compilations.
Anna Maria Bigatti

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 ... John Abbott
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 ... John Abbott
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...
John Abbott
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... John Abbott
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... John Abbott

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@.
John Abbott
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... John Abbott
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... John Abbott

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... John Abbott

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... John Abbott
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... John Abbott
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... John Abbott

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...
John Abbott
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...
Anna Maria Bigatti
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 (... John Abbott
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...
John Abbott
 

Also available in: Atom