Activity
From 27 Jan 2013 to 25 Feb 2013
22 Feb 2013
- 20:03 Feature #300: Add fault tolerant rational reconstruction to library
- Added new fns to CoCoA-5 @RatReconstructByContFrac@ and @RatReconstructByLattice@; added doc.
Modified ctors: they no...
21 Feb 2013
- 17:58 Bug #89: MachineInt or long as fn arg type for indices
- Empty post -- just to "wake up" the issue.
- 17:53 Feature #320: PPMonoid pseudo-ctors without symbol names
- What would we want these pseudo-ctors to do?
# create a PPMonoid using anonymous symbols
# create a PPMonoid using ... - 17:50 Feature #320 (Rejected): PPMonoid pseudo-ctors without symbol names
- Here are 3 proposals for new PPMonoid pseudo-ctor signatures:...
- 17:42 Support #195: OrdvArith documentation needs rewriting
- The doc needs to be rewritten fairly urgently.
- 17:12 Feature #269 (In Progress): PPMonoids: check for exponent overflow in power function
- I have modified the powering mem fns for @PPMonoidEvImpl@ and @PPMonoidEvOvImpl@ (the @Ev@ half).
I have also made a ... - 16:50 Design #305: FreeModule: unique copy?
- should we allow *submodules* only for *FreeModules*?
- 16:22 Design #305: FreeModule: unique copy?
- Big problem: *operator==*
for *ring* equality is strict (only if pointers are equal)
for *ideal* equality is "mathe... - 16:41 Design #268: Exponent range (in power products)
- John Abbott wrote:
> Any objections to adopting option *@(C)@* _i.e._ the default type for "small" exponents in power... - 16:31 Design #268: Exponent range (in power products)
- Any objections to adopting option *@(C)@* _i.e._ the default type for "small" exponents in power products is @unsigne...
- 16:29 Feature #319: BOOST -- how it could help in CoCoALib
- (1) Specifying the unsigned integral type for small exponents -- see #268.
(2) Threadsafe counters -- see #157 (rela... - 16:24 Feature #319 (Closed): BOOST -- how it could help in CoCoALib
- We collect here some ideas on how using BOOST in CoCoALib could help improve the code. For the moment we opt not to ...
20 Feb 2013
- 16:43 Design #316 (In Progress): submodule constructor different from ideal
- The way we create a submodule (SubmoduleImpl ctor) is different from how we create ideals (IdealCtor).
I think it wo...
18 Feb 2013
- 20:19 Feature #283 (Closed): Rational approximation
- No problems have surfaced in 2 months. Doc is present; tests are present.
Closing this issue.
- 20:15 Feature #315 (New): Add doc for ApproxPts2
- Add doc for *@NBM@* and *@SOI@*.
Also add examples and tests.
- 16:48 Feature #211 (Closed): NBM: add SparsePolyRing as argument for ordering
- Eva reported no problems.
Code probably still needs to be cleaned.
Documentation (file @ApproxPts2.txt@) is complet... - 16:34 Bug #22 (In Progress): Rename PPMonoidEvZZ?
- We have agreed to implement the decision in note 6.
- 16:25 Feature #210 (Closed): Normaliz: "double" cone for speed and safety
- It seems to work fine (after 7 months since finishing the code).
No documentation currently -- not sure where it wou... - 16:22 Feature #224 (Closed): Leading form
- Well, it seems that Anna forgot to close this one...
Implemented, documented; appears to work fine.
So closing now. - 13:03 Feature #244 (Closed): Rings: default ctor & assignment
- Since no problems have surfaced in the last 4 months, I'm closing this issue. The code and doc appear to be correctl...
- 12:57 Feature #221 (Closed): Better RingElems
- No problems have surfaced in 4 months; the doc seems to be correct too.
So I'm closing this issue.
- 12:50 Feature #261 (Closed): Review the utility of RefRingElem
- Since no problems have surfaced in 4 months, I regard this matter as fully resolved, so I am closing it.
15 Feb 2013
- 19:24 Bug #178: IsHomog: should it throw an error when there is no grading?
- ex-PolyRing1 with debugging active fails:...
- 18:58 Feature #300 (In Progress): Add fault tolerant rational reconstruction to library
- Added impls of *@RatReconstructByContFrac@* and *@RatReconstructByLattice@*; also added doc, and an example (@ex-NumT...
- 18:54 Feature #312: LongRange(a,b) returning vector of long a..b (included)
- It's not very important, but JAA thinks that *@LongRange@* should not be inline:
its impl is not that short, and run... - 17:13 Feature #313 (In Progress): Elim(vector<long>) as PPOrderingCtor
- Same as lex, StdDegLex, ... also *Elim(vector<long>)* should be implemented as a *PPOrderingCtor*
14 Feb 2013
- 16:04 Feature #312: LongRange(a,b) returning vector of long a..b (included)
- It is a shame to have to include the standard header @<vector>@ in the file @utils.H@.
It may not be relevant, but I... - 12:35 Feature #312 (Closed): LongRange(a,b) returning vector of long a..b (included)
- I do miss in C++ the convenient cocoa syntax *a..b*.
In fact it is particularly useful for calling *submat*.
So I s... - 11:57 Design #311 (Closed): XelMat, StdDegRevLexMat, ... should be MatrixView
- Now we have
NewDenseMatXel(long n);
NewDenseMatRevLex(long n);
NewDenseMatStdDegRevLex(long n);
NewDe...
13 Feb 2013
- 11:57 Feature #310 (Closed): ordering and grading (weights) matrix
- We should have a function for accessing the matrix and the grading/weights matrix of a PPOrdering.
Now we have *Ge...
12 Feb 2013
- 17:39 Bug #178 (Feedback): IsHomog: should it throw an error when there is no grading?
- 17:33 Design #308: Error: ERR::NotNonZero instead of ERR::ZeroRingElem? [--> ReqNonZero]
- Should we call it *ZeroValue* instead of *NotNonZero*?
And *NegativeValue* instead of *NotNonNegative*? - 13:04 Design #308: Error: ERR::NotNonZero instead of ERR::ZeroRingElem? [--> ReqNonZero]
- All CoCoALib errors which refer to zero are:
*@BadPwrZero, DivByZero, LogZero, MemPoolZero, NotNonZero, ZeroModulus, ... - 12:37 Design #308 (In Progress): Error: ERR::NotNonZero instead of ERR::ZeroRingElem? [--> ReqNonZero]
- The error *@ZeroRingElem@* is used for:
@StdDeg, LC, Monic, IsIrred, MaxExponent, wdeg (& CmpWDeg & CmpWDegPartial),... - 12:13 Design #308 (In Progress): Error: ERR::NotNonZero instead of ERR::ZeroRingElem? [--> ReqNonZero]
- I've found the error *ERR::NotNonZero*. Should we remove *ERR::ZeroRingElem*?
(and LogZero, ZeroModulus,..)
- 11:38 Design #305 (In Progress): FreeModule: unique copy?
- While writing this I gave myself the answer "probably NO", this is the reason:
* *general case*: just one constructo... - 10:55 Feature #304 (In Progress): Module ordering and grading (and shifts)
- 10:52 Support #302: Compilation on M$Windows: Visual Studio
- That's more worrying that two compilers complain.
Despite comments in the file @Main.C@, as far as I can tell @FreeM...
11 Feb 2013
- 18:49 Support #302: Compilation on M$Windows: Visual Studio
- John Abbott wrote:
> Try separating the definition from the declaration:
Tried, but no success :-(
With the in... - 15:16 Support #302: Compilation on M$Windows: Visual Studio
- Try separating the definition from the declaration:
inside the class definition put just... - 14:59 Support #302: Compilation on M$Windows: Visual Studio
- Next I tried to build the console application. It does not need qt.
But here I get an error during the compilation... - 14:54 Support #302: Compilation on M$Windows: Visual Studio
- Anna Maria Bigatti wrote:
> Christof Soeger wrote:
> > I'm aware that the RandomXYZ.C files are removed. I only wan... - 14:14 Support #302: Compilation on M$Windows: Visual Studio
- Christof Soeger wrote:
> I'm aware that the RandomXYZ.C files are removed. I only wanted to document that this chang... - 14:11 Support #302: Compilation on M$Windows: Visual Studio
- I agree that most warnings are not important, I just wanted to give them to you, since they are valid sometimes. And ...
- 12:43 Support #302: Compilation on M$Windows: Visual Studio
- ...
- 12:39 Support #302: Compilation on M$Windows: Visual Studio
- ...
- 12:38 Support #302: Compilation on M$Windows: Visual Studio
- Please disable your compiler's warning about automatic conversion from @int@ to @bool@. Many basic functions "inheri...
- 12:31 Support #302: Compilation on M$Windows: Visual Studio
- The source files @RandomXYZ.C@ were removed from CVS some time (months) ago. Please update from the current CVS.
- 12:28 Support #302: Compilation on M$Windows: Visual Studio
- Even Microsoft says that it should work with an @unsigned long@:
*@http://msdn.microsoft.com/en-us/library/zfae7kt8%2... - 12:01 Support #302: Compilation on M$Windows: Visual Studio
- On my work laptop I have VS 2010. In addition to the already mentioned points I get an error:...
- 11:35 Support #302: Compilation on M$Windows: Visual Studio
- I think "ExternalLibs-NormalizTypes.C" is a relict from the time when libnormaliz was not a compiled independently an...
- 11:10 Support #302 (In Progress): Compilation on M$Windows: Visual Studio
- Bruno wrote:
I tried the new cocoa version and it is different from the version you
sent me. There is at least a ... - 11:09 Support #302 (In Progress): Compilation on M$Windows: Visual Studio
- We should offer all documentation is needed for compiling CoCoALib/CoCoA-5 on MSWindows.
CoCoA-5 has been compiled... - 18:31 Feature #304: Module ordering and grading (and shifts)
- Now the function *NewFreeModule(R, n)* calls *NewGradedFreeModule(R, n)* when *R* is a polynomial ring (more precisel...
- 15:59 Feature #304 (Closed): Module ordering and grading (and shifts)
- Set the interface for ordering and grading (and then shifts)
Add tests and examples.
Port to CoCoA5 - 16:18 Feature #236 (Feedback): Add homog (homogenized) for ideal
- 15:56 Feature #210 (Resolved): Normaliz: "double" cone for speed and safety
- 15:53 Feature #303: Rows and Columns of a matrix
- I prefer *cols* (always the same abbreviation).
Or should it be *GetCols*?
Which name represents better it is makin... - 15:30 Feature #303 (Closed): Rows and Columns of a matrix
- Two new fns *@rows(M)@* and *@cols(M)@* -- or should its name be *@columns@*?
These take a matrix and return a lis... - 15:35 Feature #298 (Feedback): Valgrind: keep CoCoALib at 0 memory leaks
- 15:24 Feature #300: Add fault tolerant rational reconstruction to library
- The hardest parts will be fixing the UI and choosing the name(s) of the fn(s).
I should also put in my impl of the...
08 Feb 2013
- 18:18 Feature #125: Matrix equation solving; linear system solving
- Check compatibility of fn names with those in CoCoA-5 (see #206).
Need fast lin sys solving over QQ for Buchberger... - 18:04 Feature #300 (Closed): Add fault tolerant rational reconstruction to library
- Implement the various fault tolerant rational reconstruction algms, and incorporate them into CoCoALib.
Experiment... - 18:00 Feature #143 (In Progress): Buchberger-Moeller (parent task)
06 Feb 2013
- 08:10 Feature #206: Matrix equation solving: LinKer
- Both ways make sense, then I think we should follow the usual rule: "do what other systems do" (and then find a good ...
05 Feb 2013
- 11:55 Feature #206: Matrix equation solving: LinKer
- Non sono d'accordo. Se si guarda la risposta, non si può proprio capire che le soluzioni sono le colonne.
Infatti que... - 09:06 Feature #206: Matrix equation solving: LinKer
- I think that solutions (and kernel) *X* should be written so that
*AX = b* and that is what we have chosen for CoCoA...
04 Feb 2013
- 16:41 Feature #298: Valgrind: keep CoCoALib at 0 memory leaks
- Removed leaks from *toric*.
This is now the situation on my Mac (which seems to have the mentioned problem with "thro... - 12:51 Feature #206: Matrix equation solving: LinKer
- Renzo does not like the current interface where the elements of the kernel appear as *columns* rather than rows. He ...
30 Jan 2013
- 18:01 Design #297: Modules design: brainstorming
- I think *GensToCols/GensToRows* would be quite useful functions, but what would be the actual meaning? It should rep...
- 11:51 Design #297: Modules design: brainstorming
- It would make lots of sense a syntax for creating a submodule from a matrix.
I suggest the syntax *SubmoduleCols(F,M... - 11:43 Design #297: Modules design: brainstorming
- I added (in CoCoA-5) the function *ModuleOf* analogue for *RingOf*
Does it make sense? for a ModuleElem yes, for a ...
28 Jan 2013
- 15:00 Feature #298 (In Progress): Valgrind: keep CoCoALib at 0 memory leaks
- JAA has corrected the leak which was detected in @test-RingElem1@.
JAA running @valgrind-3.8.1@ on his computer was ... - 08:26 Feature #298: Valgrind: keep CoCoALib at 0 memory leaks
- Almost all tests run with @definitely lost: 0 bytes in 0 blocks@.
These are the exceptions (I guess many are related)... - 08:02 Feature #298 (Closed): Valgrind: keep CoCoALib at 0 memory leaks
- We say CoCoALib does not leak memory, and that's mostly true.
Run...
Also available in: Atom