Activity
From 06 Aug 2018 to 04 Sep 2018
04 Sep 2018
-
15:45 CoCoA-5 Bug #1224 (Closed): Lexer: unclosed multi-line comment
- The lexer supposedly handles unclosed multi-line comments (at the end of input).
However, it seems that the error me... -
14:33 CoCoALib Design #1223: NewPolyRing default indet names
- We first had this "friendly" pseudo constructor because the syntax for indet names was tedious.
Now we have @SymbolR...
02 Sep 2018
-
- The problem arises in a call to *@Hom_P_Px@* which creates a new polyring by calling *@NewPolyRing@* specifying only ...
-
- The problem was originally communicated to JAA via email. The following is a failing example:...
-
- Currently @NewPolyRing@ may be called specifying just the number of indets (but not their names).
Currently the name...
28 Aug 2018
-
- Summary of things to put into release notes:
* added new fn *@RandomPermutation@*
* *removed* old fn @NewRingFp@ ... -
- Everything for the release
CHECK FOR BUGS
Compile with *@--debug@* flag, and check that everything runs O...
16 Aug 2018
-
- The current design for accessing headers of external libs more or less assumes that the external lib has a single hea...
-
- Made obsolescent in CoCoA-5. Manual updated. tests and packages updated.
Also I prefer @NewZZmod@ to @NewRingFp@... -
- The function *@NewZZmod@* generalizes @NewRingFp@, so make the latter obsolescent.
-
- With the current design it is trickier than expected.
The main point is that the current design of CoCoALib assume... -
- The Frobby version number (C string) is in @constants::version@ defined in @src/stdinc.h@ and @src/stdinc.cpp@.
Note... -
- It is possible to get the version number from Frobby.
Modify @ExternalLibs.C@ so that it extracts Frobby's version n...
09 Aug 2018
-
-
08 Aug 2018
-
- Currently I use the following "trick" to hide code on 32-bit platforms:...
-
- To avoid compiler warnings etc. I have used (3 times so far) a CPP trick to "hide" code from 32-bit platforms (which ...
-
- There are some "suspect" files in the CoCoA-5 tests directory.
Check the contents, and eliminate any "junk".
-
- Another example......
-
- Assuming we still want to have the automatic selection between affine and projective solving, I suggest the following...
-
- What should @RationalSolve@ do if the input is homogeneous but the grading is non-standard?
-
- The point is that @RationalSolve@ tries to be clever about deciding whether it should look for solutions in affine sp...
07 Aug 2018
-
- Here is a 0-dim failing example:...
-
- @RationalSolve@ gives the wrong answer in this example:...
-
- The first cause of the bug is that the code attempts to factorize the zero polynomial.
Perhaps in a finite field, th... -
- I tried running the example in the first comment of issue #723. The call to @RationalSolve@ reported @Error: value m...
-
- The example comment 1 gives @ERROR: Value must be non-zero@ when calling @RationalSolve@. This cannot be right!
-
- I have added some more tutorials (since there are two imminent summer schools).
The original list in comment 1 wil... -
- I think this already have been done (in most entries).
In the description we have used @<tt>@ rather than @code@ be... -
- I think that has already been (mostly) done. Right?
Setting new target version.
-
- I have revised the @Makefile@ in @src/CoCoA/CoCoAManual/@ so that LaTeX warnings are made visible.
Anna has elimin... -
- Compiling the LaTeX version of the CoCoA-5 manual produces a number of warnings and overfull boxes.
We should elim... -
- I think that has been partly done. There is certainly *a preliminary @README@ file.*
We should check that it is rea...
06 Aug 2018
-
- fixed bug: now result is homog
-
- Anna has done the work, but it gives obviously wrong result (not homog).
Here is a failing example:... -
- valgrind tests OK!
-
-
- Just tested the two examples. They are acceptably fast now.
Closing.
-
- As done as it may be, for this version.
-
- As done as it may be, for this version.
-
- We have decided to call the release 0.99600 -- this is no longer relevant. Rejected this; closed.
See issue #1149
-
- Decide what we really want for these two functions.
They are mostly OK. -
- Some things still to do (or consider doing):
# Compare speed with Singular
# using CpuTimeOut option, attempt to co... -
-
- After closing this, I changed my mind:
It is simpler to leave the in @SparsePolyOps-RingElem.C@.
As simple is good,... -
- We should also check whether there are functions in *@SparsePolyOps-RingElem@* which should be moved here.
The mai... -
- Consider creating a new file *@PolyOps-RingElem@* to contain all functions on ringelems which belong to a polyring.
Also available in: Atom