Activity
From 19 Mar 2024 to 17 Apr 2024
16 Apr 2024
- 22:46 Slug #1394: Oddly slow GBasis computation (slow final cleanup)
- This might be another example where "final clean up" is not instant:...
- 22:40 Support #1666 (In Progress): MachineInt: chase through ULL changes
- I have just removed @long long@ from @MachineInt@ (and had to change one call in @BigIntOps.C@)
There are actually *... - 22:29 Design #925: MachineInt or long for args which are indices (yet again)
- Indices into matrices (and other indexable objects, _e.g._ @ModuleElem@?) must be non-negative.
As already noted ind...
15 Apr 2024
- 22:27 Design #1804: Use long long (at least sometimes)?
- I think we are close to a decision: not to use @(unsigned) long long@ except perhaps internally.
I don't regard it a... - 22:22 Design #1804: Use long long (at least sometimes)?
- Winfried Bruns sent the following response by email:...
- 10:14 Design #1804: Use long long (at least sometimes)?
- My current thoughts are that we should avoid using LL/ULL in any (normal) user interfaces, but we may use them intern...
- 19:05 Support #1814: Ensure tests do not need too much RAM
- Anna thinks she has found the cause. She'll do some more tests to confirm; then we hope to fix it.
- 10:09 Support #1814: Ensure tests do not need too much RAM
- *Anna* plans to investigate today
- 10:09 Design #1800 (In Progress): Conversion from SmallPrime to UNSIGNED long?
- I am quite tempted just to try changing the automatic conversion, but this should probably also be done with some oth...
- 10:08 Feature #828: MachineInt: function for checking that value is greater than some lower limit (and below MAXLONG)
- I think we need a new central issue regard possible redesign of @MachineInt@
- 10:05 Support #1666: MachineInt: chase through ULL changes
- I wonder if this change should be reconsidered in light of the discussion in #1804?
14 Apr 2024
- 20:44 Design #1804: Use long long (at least sometimes)?
- To be honest, I would also rather keep support for 32-bit platforms instead of using e.g., ...
- 09:20 Design #1804: Use long long (at least sometimes)?
- The more I think about making a "typedef", the less I am convinced. For convenience I shall suppose it is called *@C...
13 Apr 2024
- 22:38 Design #1804: Use long long (at least sometimes)?
- > Personally I was hoping to drop support for 32-bit platforms, but long on MinGW is only 32-bits.
Actually, MinGW... - 22:21 Design #1804 (In Progress): Use long long (at least sometimes)?
- Nico sent the following comment by email:...
- 22:18 Design #1801 (In Progress): BuildInfo
- Here is a list of CPP symbols beginning with *@COCOA_@*
* @COCOA_ULONG2LONG@
* @COCOA_ULONGLONG2LONGLONG@
* @COCOA...
10 Apr 2024
- 11:47 Support #1814: Ensure tests do not need too much RAM
- Ulrich von der Ohe wrote:
> @test-RadicalMembership1.C@ did not change from 0.99824 to 0.99850. Do you think the 20-...
09 Apr 2024
- 23:31 Support #1814: Ensure tests do not need too much RAM
- John Abbott wrote:
> * there was a bug in @IsInRadical@ which meant that it always returned @true@ IIRC
@test-Rad... - 20:55 Support #1814: Ensure tests do not need too much RAM
- I'm not sure if I am recalling correctly the time-line...
* there was a bug in @IsInRadical@ which meant that it alw... - 14:31 Support #1814: Ensure tests do not need too much RAM
- John Abbott wrote:
> I'm not surprised by the change in resources needed for @test-RadicalMembership1.C@ since the t... - 21:53 Design #1804: Use long long (at least sometimes)?
- I am a bit concerned that *@long long@* may incur unnecessary overhead on some platforms.
We could also have a CoC... - 14:21 Bug #1662: txt2tags: problem with filenames containing "_" or "-"
- John Abbott wrote:
> Did we use a workaround?
The workaround introduced in #1662#note-4 is indeed in effect in ne...
08 Apr 2024
- 21:42 Support #1814: Ensure tests do not need too much RAM
- My idea did not produce much gain (neither regarding time nor memory requirement).
There's a loop somewhere which is... - 20:57 Support #1814: Ensure tests do not need too much RAM
- It is not clear to me why @test-SparsePolyRing1-b.C@ should have become slower by a factor of 2.
I'm not surprised b... - 16:18 Support #1814: Ensure tests do not need too much RAM
- I realize that this issue was intended to be about something else. Feel free to move my posts as you see fit -- sorry...
- 16:05 Support #1814: Ensure tests do not need too much RAM
- ...
- 12:23 Support #1814: Ensure tests do not need too much RAM
- ...
- 20:26 Bug #1662 (Resolved): txt2tags: problem with filenames containing "_" or "-"
- I have advanced this issue to *resolved* since it seems to be OK now -- thanks Nico for the clarification!
Anna is a... - 15:31 Bug #1662: txt2tags: problem with filenames containing "_" or "-"
- I am using txt2tags 3.9 and it works fine on my end as well. This issue was only related to txt2tags 2.7-dev (commits...
07 Apr 2024
- 23:17 Support #1814: Ensure tests do not need too much RAM
- The tests @test-RadicalMembership1@ and @test-SparsePolyRing2@ are the only ones where memory usage considerably wors...
- 22:48 Support #1814: Ensure tests do not need too much RAM
- Strictly this is not CoCoALib but CoCoA-5.
I ran the CoCoA-5 tests with about 0.5GiB memory: there was 1 failure, na... - 22:18 Support #1814 (In Progress): Ensure tests do not need too much RAM
- Assuming that @ulimit -v@ does what I think/hope it does, I confirm that the only test to fail with a limit of @25000...
- 21:57 Support #1814: Ensure tests do not need too much RAM
- On my linux box the command *@ulimit -v 1048576@* will limit memory use to 1GiB (which seems a reasonable limit to me...
- 21:55 Support #1814 (In Progress): Ensure tests do not need too much RAM
- Ulrich also reported that *@test-SparsePolyRing2@* now needs about 3GiB of RAM at some point. That is rather a lot!
... - 21:53 Slug #1813 (In Progress): Some tests have become slower
- I think the slow down may be due to a change in code in radical (of ideals)" I believe we now speculatively try to co...
- 21:49 Slug #1813 (In Progress): Some tests have become slower
- Ulrich reports by email that the test *@test-SparsePolyRing2@* has become significantly slower; also perhaps @test-Sp...
- 20:49 Bug #1662: txt2tags: problem with filenames containing "_" or "-"
- *AnnA* can you check whether this issue can now be closed?
Ulrich reports that 0.99850 is OK with txt2tags-2.6; I s...
06 Apr 2024
- 15:34 Bug #1662: txt2tags: problem with filenames containing "_" or "-"
- The files released as 0.99850 work for me with txt2tags 2.6 (the latest stable 2.x version) as well as with txt2tags ...
31 Mar 2024
- 20:35 Bug #1811: Check include guards
- Just a small question to throw in the room: Might it be worth considering to migrate to ...
29 Mar 2024
- 10:37 Bug #1812 (New): Documentation: indexXX.html should be recompiled if version has changed
- There is no dependency on configuration/version in doc/Makefile for index...html.
(on the other hand the pdf manual ... - 08:25 Design #1753: Clean up EulerTotient, InvTotient jungle in NumTheory-misc
- set to 100% (after being closed)
- 08:22 Support #1687: Release CoCoALib 0.99850
*done* Redmine Roadmap: close or postpone issue
*done* Redmine Release issues: check percentages, check timi...
28 Mar 2024
- 23:10 Bug #1661 (Closed): Microsoft: cannot compile with signal handling
- I think Nico said it is OK now. Closing!
- 23:04 Bug #1811 (Resolved): Check include guards
- Also the interpreter has CPP symbols without the CoCoA prefix. Is that right?
- 23:00 Bug #1811 (Feedback): Check include guards
- Some files have include guards without the @CoCoA_@ prefix...
- 15:12 Support #1810: Release CoCoALib 0.99900
- Release issues:
https://cocoa.dima.unige.it/redmine/projects/cocoalib/issues?query_id=49
Here is a list of the ma... - 15:11 Support #1810 (New): Release CoCoALib 0.99900
- Everything related to making a CoCoALib release:
Redmine Roadmap: close or postpone issue
Redmine Release... - 10:15 Feature #1206 (Closed): syz, SyzOfGens: which shifts for zero?
- Updated documentation submodule.txt (need proper example ex-syz.C)
Updated CoCoA-5 test test-syz, cvs-ed and include... - 08:15 Feature #1206: syz, SyzOfGens: which shifts for zero?
- restored "final decisions" in description removed by mistake.
- 08:12 Feature #1206: syz, SyzOfGens: which shifts for zero?
- added documentation for CoCoA-5
- 08:45 Feature #1809 (New): Make ex-syz.C
- Dealing with syzygies is non-trivial, expecially with shifts.
There is a dedicated function NewFreeModuleForSyz whic... - 07:35 Feature #1808: New constructor for PolyRing with elimination ordering
- This issue originates #78 (for CoCoA-5).
However, elimination orderings are widely used in CoCoALib (not just for el... - 07:31 Feature #1808 (In Progress): New constructor for PolyRing with elimination ordering
- New syntax @NewPolyRingElim(....)@ would be handy, and also easily transferred to CoCoA-5.
Design its interface (eg:...
27 Mar 2024
- 17:47 Feature #1206 (Resolved): syz, SyzOfGens: which shifts for zero?
- Still to do: documentations showing how to deal with 0 entries, in CoCoALib and in CoCoA5
- 17:43 Feature #1206: syz, SyzOfGens: which shifts for zero?
- Anna Maria Bigatti wrote:
> Should we make @SyzOfGens@ obsolescent? does it do anything more than calling @syz(gens... - 17:31 Feature #598: Syzygy for modules: non-homogeneous module
- I moved this issue from CoCoA-5 to CoCoALib
- 17:24 Feature #598 (In Progress): Syzygy for modules: non-homogeneous module
26 Mar 2024
- 17:19 Feature #1667: GBasis over ZZ: port to CoCoALib
- Michele Toriell is asking for this. There was C++ from when i was in Passau: dig it out, and blow the dust off.
- 17:14 Feature #598: Syzygy for modules: non-homogeneous module
- Good idea to make comprehensive tests.... perhaps not easy.
Why "feedback" and 10% complete?
- 10:02 Feature #598 (Feedback): Syzygy for modules: non-homogeneous module
- This issue is old.
I'm making a test file test-sys.cocoa5.
I'll update and write there what we have working for hom... - 14:36 Design #582: Error codes: use same code for "not poly ring" and "not elem poly ring"
- I think this has been agreed upon a long time ago, as explained in #582-3.
Moreover the recent addition of the conte... - 14:22 Design #1807 (New): Error codes: "Not..." for "blah must be ..." -- change prefix
- In the general picture of improving the error codes, I suggest a trivial (though extensive) change.
Look at these na... - 11:50 Feature #1793: Use ErrorContext instead of string FnName
- Added also to NewFreeModuleForSyz.
- 10:42 Feature #1206: syz, SyzOfGens: which shifts for zero?
- Anna Maria Bigatti wrote:
> This is my suggestion: implement a new function @syz0@ which allows 0s in the input (giv...
25 Mar 2024
- 19:31 Design #1804: Use long long (at least sometimes)?
- Personally I was hoping to drop support for 32-bit platforms, but @long@ on MinGW is only 32-bits. Does MinGW offer ...
- 19:29 Design #1804 (In Progress): Use long long (at least sometimes)?
- Winfried Bruns suggested in issue #1661 to consider using *@long long@* wherever we want more than 32-bits.
Investig... - 19:16 Feature #1797: Add a function CleanupGens making some easy cleaning on the generators?
- This might be a separate issue: should there also be a similar function which "prepares" the generators for computin...
- 19:06 Feature #1803 (New): Improve trivial operations with ideal whose GBasis is [1]
- Sum is clever -- if HasGBasis(I) and is ideal(1).
Do the same for product and for other similar operations.... - 19:05 Design #1802: Tidying ideal generators (for non-polynomial ideals)
- First steps:
* remove 0 generators
* if any generator is 1 (or invertible) then the ideal is 1
* for integer ideal... - 19:02 Design #1802 (New): Tidying ideal generators (for non-polynomial ideals)
- Generalize the ideas of issue #1647 to other types of ideal (and modules?)
- 19:02 Design #1647 (Closed): Suppress zero from ideal generators? Detect 1 and simplify generators?
- Moving note-33 (product) to another issue, because not related to generators.
- 18:13 Design #1647: Suppress zero from ideal generators? Detect 1 and simplify generators?
- Sum is clever -- if HasGBasis(I) and is ideal(1)
Do it also for product.... - 18:51 Design #1801: BuildInfo
- The function for CoCoA-5 is VersionInfo() defined in BuiltingFunctions.C
- 18:49 Design #1801: BuildInfo
- We need to consider the behaviour both in CoCoALib and in CoCoA-5.
Anna suggests that it is more helpful to mainta... - 18:47 Design #1801 (In Progress): BuildInfo
- Three things:
* why do some preprocessor flags have prefix *@COCOA_@* while others have *@CoCoA_@* ?
* for whom are... - 18:18 Bug #1661 (Resolved): Microsoft: cannot compile with signal handling
- 09:32 Bug #1661: Microsoft: cannot compile with signal handling
- Anna Maria Bigatti wrote:
> Add the value of this flag to "VersionInfo()" in CoCoA-5 (work for me)
and in BuildI... - 09:30 Bug #1661: Microsoft: cannot compile with signal handling
- Add the value of this flag to "VersionInfo()" in CoCoA-5 (work for me)
- 18:05 Bug #1726 (Closed): Dangling references to temporaries
- I believe I have made all necessary changes. So closing -- it works fine for us...
- 17:55 Design #1720: DivAlg in CoCoALib
- to be improved (see Nicolas Jagersma code using GPoly)
- 17:49 Design #1800: Conversion from SmallPrime to UNSIGNED long?
- We have long tried to avoid unsigned values because they can cause inconvenient, silent, automatic conversions.
But ... - 17:47 Design #1800 (In Progress): Conversion from SmallPrime to UNSIGNED long?
- Currently there is an "implicit" conversion from @SmallPrime@ to @signed long@.
Should the conversion instead be to ... - 17:49 Design #1649 (Closed): Add file SparsePolyOps-vector.C
- 09:06 Design #1649: Add file SparsePolyOps-vector.C
- Anna Maria Bigatti wrote:
> I suggest having all headers in SparsePolyOps-RingElem.H (well indicated) and the "vecto... - 08:22 Design #1649: Add file SparsePolyOps-vector.C
- After trying to rearrange the header files I found this problem.
There are functions on vectors of RingElem need hea... - 08:12 Design #1649 (Resolved): Add file SparsePolyOps-vector.C
- After closing I realized that the "coefficients" functions were missing and that the .H files were not aligned.
Stil... - 07:42 Design #1649 (Closed): Add file SparsePolyOps-vector.C
- Anna Maria Bigatti wrote:
> Add syz and syz0 (allowing 0s) for vector of RingElem
*syz* should stay in @submodule...
24 Mar 2024
- 10:52 Design #1799: Clean out OLD CODE?
- Apart from being untidy (& possibly embarassing) the old code does sometimes cost time if we have to maintain it.
Wh... - 10:50 Design #1799 (New): Clean out OLD CODE?
- The sources contain some quite old code which is likely no longer used.
We should identify the code and consider rem...
22 Mar 2024
- 23:20 Bug #1661: Microsoft: cannot compile with signal handling
- A macro like ...
- 22:04 Bug #1661: Microsoft: cannot compile with signal handling
- I have been working through Nico's changes. Still undecided about several of them :-/
The 32-bit vs 64-bit problems... - 23:13 Support #302: Compilation on M$Windows: Visual Studio
- The problem with ...
- 21:01 Support #302: Compilation on M$Windows: Visual Studio
- Is any of this still relevant?
- 18:17 Feature #313 (In Progress): Elim(vector<long>) as PPOrderingCtor
- Probably the functions ElimMat-like are good enough for this.
At least we should write some explicit example here (f... - 18:12 Slug #777: SLUG: elimination
- There are two improvements we can still make:
# tell myFinalizeGBasis interreduce only the polynomials with the want... - 17:25 Slug #777: SLUG: elimination
- Now it takes 165s (I don't know how long it was before)
- 15:58 Slug #777: SLUG: elimination
- Anna Maria Bigatti wrote:
> Apart from the improvements we can do for @elim@ (and are about to do ;-)
I wonder if... - 18:01 Slug #1394 (Resolved): Oddly slow GBasis computation (slow final cleanup)
- 17:56 Slug #1394: Oddly slow GBasis computation (slow final cleanup)
- John Abbott wrote:
> Anna points out that the actual cost is the normal form reduction inside the *@isin@* operator.... - 17:53 Slug #1394 (In Progress): Oddly slow GBasis computation (slow final cleanup)
- Anna points out that the actual cost is the normal form reduction inside the *@isin@* operator. The computation of t...
- 16:43 Slug #1394: Oddly slow GBasis computation (slow final cleanup)
- Current timings after the LT checking in the final cleaning (just marginally better than before, but most of the time...
- 16:16 Slug #1394: Oddly slow GBasis computation (slow final cleanup)
- I changed the verbosity to 130 (to see what goes on in the -Final clean up)
Now it is faster because the polynomials... - 16:19 Slug #1796: myFinalizeGBasis ("Final clean up") should be more flexible
- Improved (see #777-12).
Still, could be more clever when computing elimination and some reductions are completely us... - 14:38 Feature #1094: Revive code for SelfSaturating GBasis
- Remember to add tests to test-GB.cocoa5
- 14:32 Feature #1212 (Closed): New function: GBasisByHomog
- Good thing I wrote #1212-19! My first implementation was wrong (embarrassing).
Now all implemented and I added a Co... - 10:20 Support #942: Which names to use? Intersection/saturation vs intersect/saturate
- I prefer to go through similar situations before changing the current names.
Make a list.
Postponing.
- 10:18 Slug #967: Improve saturate
- Different situations to consider (from #1619-8)
* monomial
* homog
* principal
* univariate
* general
- 10:14 Feature #1619 (Closed): Make saturate available in CoCoALib
- 09:38 Design #1649 (Resolved): Add file SparsePolyOps-vector.C
- Add syz and syz0 (allowing 0s) for vector of RingElem
- 09:35 Design #1649 (Feedback): Add file SparsePolyOps-vector.C
- 09:35 Bug #1726 (Feedback): Dangling references to temporaries
- 09:30 Design #1798: Computing in sub polyring
- The test in note-3 would be faster if called in the minimal sub-polyring.
- 09:27 Design #1798: Computing in sub polyring
- From #1641-11
It seems it's the "high number of variables" problem, and syz itself is quite fast: this examples take... - 09:23 Design #1798 (New): Computing in sub polyring
- Investigate whether it is a good idea to adapt certain operations to compute in a sub polyring (without unnecessary i...
- 09:29 Slug #1588: ElimMat is slow
- I though we had a class for incremental gaussian reduction. That should be useful in this case!
We can also make ... - 09:13 Feature #1780 (Closed): radical for ideals in SparsePolyRing: code in C++
- The old CoCoA-5 radical code is currently still available as function @radical_COCOALANGUAGE@ in the radical.cpkg5 pa...
21 Mar 2024
- 20:40 Slug #1756: deg(f) is slow if f is long
- My previous comment just above is correct, but we can sometimes do better.
I think we need to consider just the "low... - 20:31 Bug #1749 (Closed): Configuration hiccups on Mac M1
- 20:29 Design #1085 (Closed): Fns with "OUT" args: should they give ERR::MixedRings?
- I'm too lazy to track down all the functions which ought to be tested, and then to write the corresponding tests.
So... - 20:24 Design #1606 (Closed): Return type with const
- 20:18 Bug #1641 (Closed): gcd does not recognize univariate input
- I have added some new tests to @test-SparsePolyRing1.C@.
I conform that Anna's example from comment 11 does seems to... - 12:02 Bug #1641: gcd does not recognize univariate input
- The problem for multivariate syz with many indets (from note-8 on) seems to be considered in #1057 and #1068, so I wo...
- 11:31 Bug #1641: gcd does not recognize univariate input
- It seems it's the "high number of variables" problem, and syz itself is quite fast: this examples takes ~4s on my com...
- 10:25 Bug #1641: gcd does not recognize univariate input
- Ah yes, I do have debugging on.
Do you get a measurable time difference if the ring contains just 3 indets or if it ... - 10:01 Bug #1641: gcd does not recognize univariate input
- John Abbott wrote:
> The new code seems to work now, and is faster if the polys are recognized as univariate.
>
>... - 18:02 Slug #967: Improve saturate
- I also added the factorization in the case of a monomial (similar test as in #967-5, now in test0saturate.cocoa5).
... - 17:56 Bug #1790 (Closed): saturate with zero ideals
- 13:27 Bug #1790: saturate with zero ideals
- John Abbott wrote:
> The problem was that in @BuiltInFunctions-CoCoALib.C@ there was a call to @I->mySaturate(J)@ in... - 17:55 Feature #1619: Make saturate available in CoCoALib
- added CoCoA-5 test-saturate.cocoa5
- 17:54 Feature #1619: Make saturate available in CoCoALib
- John Abbott wrote:
> Maybe different types:
> * monomial
> * principal
> * univariate
> * general
also homog
20 Mar 2024
- 22:03 Bug #1641 (Resolved): gcd does not recognize univariate input
- The new code seems to work now, and is faster if the polys are recognized as univariate.
What I do not understand ... - 16:48 Design #1647: Suppress zero from ideal generators? Detect 1 and simplify generators?
- This is all done (I believe) for ideals in SparsePolyRing.
Do it also for ideals in other rings (should we have anot... - 15:53 Feature #1788 (Closed): New MatrixView/function "FirstRows/FirstCols"?
- Added documentation for CoCoALib/5.
- 15:26 Feature #1788 (Feedback): New MatrixView/function "FirstRows/FirstCols"?
- I liked this too much and I did it.
Called in some lib/5 tests, called by GradingMat.
Easy enough. should not need...
19 Mar 2024
- 22:10 Bug #1641: gcd does not recognize univariate input
- Made some progress. This is more tedious than I thought... the doc for CoCoALib could be better... (and the design t...
- 20:18 Bug #1641: gcd does not recognize univariate input
- The problem code is in @SparsePolyOps-RingElem.C@ around line 718 (search for @SyzOfGens@ or maybe just @syz@).
I...
Also available in: Atom