Activity
From 17 Sep 2021 to 16 Oct 2021
15 Oct 2021
- 14:24 Bug #1620 (New): MinPolyQuot not documented
- MinPolyQuot is available in CoCoALib but is not documented.
- 14:22 Feature #1619 (Closed): Make saturate available in CoCoALib
- It seems like this is already implemented. There is a function mySaturate in _AlgebraicCore/SparsePolyOps-ideal.C_.
...
14 Oct 2021
- 15:50 Design #1617: UnivariateIndetIndex: exact semantics
- Mmm, should it be an error to call @UnivariateIndetIndex@ if the polyring has just 1 indet?
After all, the answer i... - 15:48 Support #1618 (Closed): Tidy ex-RingElem2
- I think that *@ex-RingElem2@* needs to be updated/tidied.
For instance, there is no need to pass the ring to the f...
13 Oct 2021
- 20:34 Design #1617: UnivariateIndetIndex: exact semantics
- What about the case of a constant poly in a polyring with just 1 indet?
Error or not? (assuming we opt for an error... - 20:14 Design #1617 (Closed): UnivariateIndetIndex: exact semantics
- What are the exact semantics of *@UnivariateIndetIndex@*?
In particular what should the function return if passed ...
04 Oct 2021
- 12:08 Bug #1601: Compilation ambiguity
- This particular problem has been resolved (by eliminating the *@apply@* fn from CoCoALib).
In this case the removal ... - 12:03 Feature #1598: RingHom: implement phi(X) as apply(phi, X) also for X vector and matrix
- We should move towards making *@apply@* obsolescent in CoCoA-5 now that RINGHOM can be applied directly to LIST and M...
- 12:00 Feature #1598: RingHom: implement phi(X) as apply(phi, X) also for X vector and matrix
- I am not sure whether the following behaviour is what is wanted:...
- 11:50 Design #1467: Change syntax apply(phi,M) into phi(M)?
- In the end my hand was forced.
Some future version of C++ (maybe C++17?) defines a template fn *@apply@* which match... - 09:50 Feature #1589: IdealOfPoints: allow matrix of points to be defined over "wrong" ring
- checked in (4 Oct 21)
30 Sep 2021
- 14:13 Feature #1602: Sparse matrix (SparseMat)
- Do we want to handle structured matrices like sparse matrices? _e.g._ Toeplitz matrices are specified by just a few ...
- 10:45 Support #1612 (Closed): Merge the doc file RadicalMembership.txt into ideal.txt
- Merge the doc file *@RadicalMembership.txt@* into *@ideal.txt@*?
Note that the doc refers to @ex-RadicalMembership... - 10:23 Support #1611 (New): Documentation for PrimaryDecomposition
- The CoCoALib doc for @PrimaryDecomposition@ needs to be improved.
I have just added a description of the data type i...
22 Sep 2021
- 17:45 Bug #1585 (Closed): CRASH/ABORT: GMP overflow
- As observed in comment 11, it would be very hard to try to prevent overflow in all cases.
It thus seems reasonable t...
21 Sep 2021
- 11:31 Bug #1601: Compilation ambiguity
- I think I know understand what happens: g++ v.11 has as default C++ version something newer than C++14.
My script @c...
20 Sep 2021
- 21:33 Bug #1585: CRASH/ABORT: GMP overflow
- I have worked around the @FloatStr@ problem (actually in @FloorLogBase@) mentioned in comment 4 above.
I just call t... - 20:52 Bug #1585: CRASH/ABORT: GMP overflow
- I have put a new constant called *@OVERFLOW_BITS@* in *@config.H@*, and modified the impls so that they use this cons...
- 16:49 Bug #1601: Compilation ambiguity
- Florian succeeded in installing g++-10 on his computer; and he reports that CoCoALib compiled just fine (except a kno...
- 16:17 Support #861 (Closed): Janet basis code: TmpJB files give some problems with C++11 (using CLANG/LLVM)
- I have removed the commented-out code (and another function which existed only for that code).
It all compiles, and ... - 16:09 Support #1609 (New): Clean time.C
- The file @time.C@ contains some hackery to work on Microsoft (or other non-unix-like) platforms.
Can we clean this... - 15:41 Design #1558 (Closed): CpuTimeLimit: more frequent clock checks
- No problems have been reported in 7 months. So closing.
Maybe the imminent CoCoA school will find some "interesting... - 14:08 Design #1608 (Feedback): Domain of definition of NextPrime (and PrevPrime)
- I have spoken to Anna who agrees to change the behaviour:
* both fns throw @BadArg@ (or similar) if given (strictly)... - 13:24 Design #1608 (In Progress): Domain of definition of NextPrime (and PrevPrime)
- I am now inclined to allow 0 as arg to @NextPrime@; perhaps this is related to my preference to consider 0 as a "natu...
Also available in: Atom