Activity
From 25 Mar 2024 to 23 Apr 2024
23 Apr 2024
-
22:26 Design #1787: Iterator design: compatible with C++STL? Advancing beyond end?
- A quick look on StackOverflow found a discussion which claims that the C++ standard says that advancing an iterator b...
-
- I created a memory leak in the gcd function for multivariate polynomials over a finite field. I have a first fix, an...
-
- While it might give slightly better performance to use @(unsigned) long long@ in some internal chinese-remaindering f...
-
- What I meant to say in comment 9 above is: if we choose a design for iterators where @operator*@ never throws then we...
22 Apr 2024
-
22:39 Design #1572: Use noexcept
- According to the C++ standard, a function is either not-throwing or potentially-throwing. The ...
-
- Another question is about @operator*@ for iterators: if an error is thrown when "beyond the end" then it cannot be @n...
-
- This has been mostly done. Comment 13 above is a good strategy.
Current state is good enough, so closing. -
- There are 2 designs for @MachineInt@
# internal repr is @unsigned long@ and an extra bit to indicate that the true v... -
- We should try to reduce the number of warnings (esp. when compiling in "debug" mode).
Then we can consider attribute... -
- If iterator operators can throw then they cannot be @noexcept@ (obviously!). See issue #1572
Not sure how important... -
- Some files still need tp be updated: I think the "morse" files need to be updated.
The "JB" files look to scary to t... -
- * @DynamicBitset@ uses iterators explicitly; maybe switch to @auto@?
* possibly review @TmpJB...@ code too?
* @Long... -
- The @configure@ script was changed some time ago; now it is clear which options are relevant to CoCoALib and which to...
-
- This has effectively been resolved by issue #1661. The solution there assumes **either 64-bit or 32-bit @long@**; ot...
-
-
- Thanks to Nico for the suggestion about @#pragma@. I read also the discussion about its pros and cons -- it is not c...
-
- I have not found any suitable macro in the gfanlib sources (v.0.6.2).
Without Anders's help we cannot really do much... -
- The current impl is good enough. It behaves well enough on the two "big" test examples listed above. If we really w...
-
- I have adopted the simple solution of changing the documentation: previously it said nothing about the order of the f...
18 Apr 2024
-
16:38 Feature #937: LinDepMill: Mill for linear dependencies
- LinDepMill could also be used by MakeTermOrdMat.
-
- I have implemented the (hidden but present) function ShapeLemma which returns the whole lex-GB when the MinPoly has m...
16 Apr 2024
-
- This might be another example where "final clean up" is not instant:...
-
- I have just removed @long long@ from @MachineInt@ (and had to change one call in @BigIntOps.C@)
There are actually *... -
- Indices into matrices (and other indexable objects, _e.g._ @ModuleElem@?) must be non-negative.
As already noted ind...
15 Apr 2024
-
- I think we are close to a decision: not to use @(unsigned) long long@ except perhaps internally.
I don't regard it a... -
- Winfried Bruns sent the following response by email:...
-
- My current thoughts are that we should avoid using LL/ULL in any (normal) user interfaces, but we may use them intern...
-
- Anna thinks she has found the cause. She'll do some more tests to confirm; then we hope to fix it.
-
- *Anna* plans to investigate today
-
- I am quite tempted just to try changing the automatic conversion, but this should probably also be done with some oth...
-
- I think we need a new central issue regard possible redesign of @MachineInt@
-
- I wonder if this change should be reconsidered in light of the discussion in #1804?
14 Apr 2024
-
- To be honest, I would also rather keep support for 32-bit platforms instead of using e.g., ...
-
- 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
-
- > Personally I was hoping to drop support for 32-bit platforms, but long on MinGW is only 32-bits.
Actually, MinGW... -
- Nico sent the following comment by email:...
-
- Here is a list of CPP symbols beginning with *@COCOA_@*
* @COCOA_ULONG2LONG@
* @COCOA_ULONGLONG2LONGLONG@
* @COCOA...
10 Apr 2024
-
- 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... -
- I'm not sure if I am recalling correctly the time-line...
* there was a bug in @IsInRadical@ which meant that it alw... -
- John Abbott wrote:
> I'm not surprised by the change in resources needed for @test-RadicalMembership1.C@ since the t... -
- I am a bit concerned that *@long long@* may incur unnecessary overhead on some platforms.
We could also have a CoC... -
- John Abbott wrote:
> Did we use a workaround?
The workaround introduced in #1662#note-4 is indeed in effect in ne...
08 Apr 2024
-
- My idea did not produce much gain (neither regarding time nor memory requirement).
There's a loop somewhere which is... -
- 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... -
- I realize that this issue was intended to be about something else. Feel free to move my posts as you see fit -- sorry...
-
- ...
-
- ...
-
- I have advanced this issue to *resolved* since it seems to be OK now -- thanks Nico for the clarification!
Anna is a... -
- 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
-
- The tests @test-RadicalMembership1@ and @test-SparsePolyRing2@ are the only ones where memory usage considerably wors...
-
- Strictly this is not CoCoALib but CoCoA-5.
I ran the CoCoA-5 tests with about 0.5GiB memory: there was 1 failure, na... -
- Assuming that @ulimit -v@ does what I think/hope it does, I confirm that the only test to fail with a limit of @25000...
-
- On my linux box the command *@ulimit -v 1048576@* will limit memory use to 1GiB (which seems a reasonable limit to me...
-
- Ulrich also reported that *@test-SparsePolyRing2@* now needs about 3GiB of RAM at some point. That is rather a lot!
... -
- 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...
-
- Ulrich reports by email that the test *@test-SparsePolyRing2@* has become significantly slower; also perhaps @test-Sp...
-
- *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
-
- 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
-
- Just a small question to throw in the room: Might it be worth considering to migrate to ...
29 Mar 2024
-
- There is no dependency on configuration/version in doc/Makefile for index...html.
(on the other hand the pdf manual ... -
- set to 100% (after being closed)
-
*done* Redmine Roadmap: close or postpone issue
*done* Redmine Release issues: check percentages, check timi...
28 Mar 2024
-
- I think Nico said it is OK now. Closing!
-
- Also the interpreter has CPP symbols without the CoCoA prefix. Is that right?
-
- Some files have include guards without the @CoCoA_@ prefix...
-
- Release issues:
https://cocoa.dima.unige.it/redmine/projects/cocoalib/issues?query_id=49
Here is a list of the ma... -
- Everything related to making a CoCoALib release:
Redmine Roadmap: close or postpone issue
Redmine Release... -
- Updated documentation submodule.txt (need proper example ex-syz.C)
Updated CoCoA-5 test test-syz, cvs-ed and include... -
- restored "final decisions" in description removed by mistake.
-
- added documentation for CoCoA-5
-
- Dealing with syzygies is non-trivial, expecially with shifts.
There is a dedicated function NewFreeModuleForSyz whic... -
- This issue originates #78 (for CoCoA-5).
However, elimination orderings are widely used in CoCoALib (not just for el... -
- New syntax @NewPolyRingElim(....)@ would be handy, and also easily transferred to CoCoA-5.
Design its interface (eg:...
27 Mar 2024
-
- Still to do: documentations showing how to deal with 0 entries, in CoCoALib and in CoCoA5
-
- Anna Maria Bigatti wrote:
> Should we make @SyzOfGens@ obsolescent? does it do anything more than calling @syz(gens... -
- I moved this issue from CoCoA-5 to CoCoALib
-
26 Mar 2024
-
- Michele Toriell is asking for this. There was C++ from when i was in Passau: dig it out, and blow the dust off.
-
- Good idea to make comprehensive tests.... perhaps not easy.
Why "feedback" and 10% complete?
-
- 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... -
- I think this has been agreed upon a long time ago, as explained in #582-3.
Moreover the recent addition of the conte... -
- In the general picture of improving the error codes, I suggest a trivial (though extensive) change.
Look at these na... -
- Added also to NewFreeModuleForSyz.
-
- Anna Maria Bigatti wrote:
> This is my suggestion: implement a new function @syz0@ which allows 0s in the input (giv...
25 Mar 2024
-
- Personally I was hoping to drop support for 32-bit platforms, but @long@ on MinGW is only 32-bits. Does MinGW offer ...
-
- Winfried Bruns suggested in issue #1661 to consider using *@long long@* wherever we want more than 32-bits.
Investig... -
- This might be a separate issue: should there also be a similar function which "prepares" the generators for computin...
-
- Sum is clever -- if HasGBasis(I) and is ideal(1).
Do the same for product and for other similar operations.... -
- First steps:
* remove 0 generators
* if any generator is 1 (or invertible) then the ideal is 1
* for integer ideal... -
- Generalize the ideas of issue #1647 to other types of ideal (and modules?)
-
- Moving note-33 (product) to another issue, because not related to generators.
-
- Sum is clever -- if HasGBasis(I) and is ideal(1)
Do it also for product.... -
- The function for CoCoA-5 is VersionInfo() defined in BuiltingFunctions.C
-
- We need to consider the behaviour both in CoCoALib and in CoCoA-5.
Anna suggests that it is more helpful to mainta... -
- Three things:
* why do some preprocessor flags have prefix *@COCOA_@* while others have *@CoCoA_@* ?
* for whom are... -
-
- Anna Maria Bigatti wrote:
> Add the value of this flag to "VersionInfo()" in CoCoA-5 (work for me)
and in BuildI... -
- Add the value of this flag to "VersionInfo()" in CoCoA-5 (work for me)
-
- I believe I have made all necessary changes. So closing -- it works fine for us...
-
- to be improved (see Nicolas Jagersma code using GPoly)
-
- We have long tried to avoid unsigned values because they can cause inconvenient, silent, automatic conversions.
But ... -
- Currently there is an "implicit" conversion from @SmallPrime@ to @signed long@.
Should the conversion instead be to ... -
-
- Anna Maria Bigatti wrote:
> I suggest having all headers in SparsePolyOps-RingElem.H (well indicated) and the "vecto... -
- After trying to rearrange the header files I found this problem.
There are functions on vectors of RingElem need hea... -
- After closing I realized that the "coefficients" functions were missing and that the .H files were not aligned.
Stil... -
- Anna Maria Bigatti wrote:
> Add syz and syz0 (allowing 0s) for vector of RingElem
*syz* should stay in @submodule...
Also available in: Atom