Activity
From 08 May 2016 to 06 Jun 2016
06 Jun 2016
- 23:50 CoCoA-5 Slug #875 (In Progress): Interpreter is too slow reading a big polynomial
- I have taken one of Mario's big polys: this one is about 6Mbyte when printed out.
I tried to ways of converting th... - 21:58 CoCoA-5 Slug #875: Interpreter is too slow reading a big polynomial
- The solution to use @ReadExpr(P, "poly-as-a-string")@ works tolerably well from the point of view of the interpreter,...
- 15:37 CoCoALib 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...
- 13:47 CoCoALib 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... - 13:31 CoCoALib 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...
- 13:28 CoCoALib 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...
01 Jun 2016
- 17:05 CoCoALib Support #887: My first compilations with clang
- CoCoA-5 running!!...
31 May 2016
- 15:55 CoCoALib Support #887: My first compilations with clang
- ... another thing I don't really know the meaning of:...
- 15:49 CoCoALib Support #887: My first compilations with clang
- I expect this is well under control ;-)...
- 15:27 CoCoALib Support #887: My first compilations with clang
- ... I'm not quite sure what this refers to......
- 15:16 CoCoALib 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... - 15:14 CoCoALib 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.
25 May 2016
- 17:01 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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:41 CoCoA-5 Feature #883: gin: return/print a suitable change of variables
- How about a new fn which computes both gin and a "simple" suitable transformation?
Or maybe a fn which takes an idea... - 16:30 CoCoA-5 Feature #883: gin: return/print a suitable change of variables
- John Abbott wrote:
> Werner also asked whether the transformation used is triangular or square.
triangular (auxil... - 15:28 CoCoA-5 Feature #883 (In Progress): gin: return/print a suitable change of variables
- Werner also asked whether the transformation used is triangular or square.
It might be nice to have the option to ... - 13:54 CoCoA-5 Feature #883: gin: return/print a suitable change of variables
- John Abbott wrote:
> Werner Seiler asks whether it would be possible to make @gin@ also produce a "good" linear chan... - 11:11 CoCoA-5 Feature #883 (Closed): gin: return/print a suitable change of variables
- Werner Seiler asks whether it would be possible to make @gin@ also produce a "good" linear change of variables (ideal...
- 16:36 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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... - 14:02 CoCoA-5 Feature #877: Easier syntax to make a PRINCIPAL ideal?
- John Abbott wrote:
> Perhaps the error message should say which signatures @ideal@ does offer?
Yes, I like that (...
09 May 2016
- 22:10 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib Slug #881: ReadExpr is too slow on large polys
- I did a quick test:...
- 21:23 CoCoALib 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 CoCoALib 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 CoCoALib 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 CoCoALib 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... - 15:56 CoCoA-5 Bug #880 (Closed): subst should check that indet is in same ring as 1st arg, but does not.
- @subst@ should check that indet is in same ring as 1st arg, but does not.
Here is an example:... - 15:30 CoCoA-5 Support #879: LOGAR: make CoCoA-5 easier to use
- At some point I triggered a bug in CoCoA-5. I was trying to use @subst@ somehow (to replace @a[6]@ by zero); perhaps...
- 15:25 CoCoA-5 Support #879: LOGAR: make CoCoA-5 easier to use
- Sandro then wanted to compute the expressions for the coordinates of the intersection points of the line and the elli...
- 15:16 CoCoA-5 Support #879: LOGAR: make CoCoA-5 easier to use
- @cond1@ corresponds to the condition that the ellipse passes through the origin.
It simplifies to @a[6]=0@.
We woul... - 15:10 CoCoA-5 Support #879: LOGAR: make CoCoA-5 easier to use
- ...
- 15:05 CoCoA-5 Support #879 (New): LOGAR: make CoCoA-5 easier to use
- In early May 2016 I met (Sandro) Logar at the Normaliz workshop in Osnabrueck.
I wanted to persuade him to use CoCoA... - 14:51 CoCoA-5 Feature #877 (In Progress): Easier syntax to make a PRINCIPAL ideal?
- Now I recall what I tried: @ideal(R,x)@ does not work; it says it wants a list instead of a RINGELEM.
Are there an... - 11:43 CoCoA-5 Feature #877: Easier syntax to make a PRINCIPAL ideal?
- It is already done, both in CoCoA-5 and CoCoALib (in CoCoALib up to 4 generators).
- 11:11 CoCoA-5 Feature #877 (Closed): Easier syntax to make a PRINCIPAL ideal?
- Currently the way to make a principal ideal is not so natural: the generator must be put into a list.
Are there an... - 11:29 CoCoA-5 Bug #878: RingElem applied to a symbol (repr as a string)
- Personally I find the situation described quite confusing.
It is not clear to me why @ReadExpr@ is not already inc... - 11:25 CoCoA-5 Bug #878 (Closed): RingElem applied to a symbol (repr as a string)
- The current design for converting a symbol (repr as a string) into a RINGELEM is inconvenient.
I wanted to do this...
Also available in: Atom