Activity
From 11 Oct 2015 to 09 Nov 2015
09 Nov 2015
-
23:22 Feature #747: New function for making list of symbols (indeterminate names)
- John Abbott wrote:
> Do we want this function to handle symbol ranges?
>
> It probably makes sense for @symbols... -
15:21 Feature #747: New function for making list of symbols (indeterminate names)
- Do we want this function to handle symbol ranges?
_e.g._ @symbols("x[1..3,2..5]")@ would produce the same result as ... -
15:46 Feature #801: Test whether a symbol is in a ring
- Currently this operation is implemented in a hidden way inside @RingBase::myNew(symbol)@.
The implementation there... -
15:39 Feature #801 (New): Test whether a symbol is in a ring
- Should there be a function which tests whether a given @symbol@ is in given @ring@?
I am thinking of "recursive" s... -
13:35 Feature #800: PPMonoidSparse: impl of sparse PPs
- I had assumed that this issue already existed, but a quick search did not find it.
There is already a partial impl... -
13:33 Feature #800 (Closed): PPMonoidSparse: impl of sparse PPs
- Implement a PPMonoid which uses a sparse repr for the PPs.
This is useful when there are many indets.
-
13:30 Slug #799: vector of "indets" in each PPMonoid?
- The vector of indets is used in the (mem) function @mySymbolValue@, which currently returns a reference to the image ...
-
13:26 Slug #799 (In Progress): vector of "indets" in each PPMonoid?
- Is it truly useful to have each PPMonoid keep a vector of its own indets?
This is not a problem if the indets are ...
07 Nov 2015
-
22:35 Feature #797 (In Progress): SmallFpImpl: make it faster
- The speed gains varies form platform to platform -- surprise, surprise!
The old @DUPFF@ code was (significantly) f... -
21:57 Feature #797 (In Progress): SmallFpImpl: make it faster
- After comparing @gcd@ for @DUPFp@ and @DUPFF@, I saw that the latter was significantly faster (_e.g._ factor 2 or mor...
05 Nov 2015
-
16:45 Feature #796 (Closed): CoCoALib function for radical (or SqFree) of a polynomial
- This problem is generally easier than @SqFreeFactor@, indeed in @SqFreeFactorPosDerChar0@ it is just computed by the ...
-
16:16 Feature #48: Squarefree factorization - multivariate polynomials, char 0
- Anna Maria Bigatti wrote:
> John Abbott wrote:
> > I'm not sure; I suspect it will not work in every case.
>
> I... -
16:14 Feature #48: Squarefree factorization - multivariate polynomials, char 0
- Good point! So if @gcd@ works then we can expect that squarefree decomposition works.
-
15:06 Feature #48: Squarefree factorization - multivariate polynomials, char 0
- John Abbott wrote:
> I'm not sure; I suspect it will not work in every case.
I thought it would: in char 0 the squar... -
16:01 Bug #793: compilation on fedora 23: some worrying "error messages"
- The *@Fatal error@* messages appeared once again when I tried building CoCoALib from a new unpackaged tar file. The ...
-
15:41 Feature #795 (Feedback): Add new fn InvModNoCheck
- Implemented, documented. No separate test; it is effectively tested inside @test-NumTheory1@
-
15:39 Feature #795 (Closed): Add new fn InvModNoCheck
- For efficiency it would be nice to have public access to the "fast" function for computing inverses modulo an integer.
-
15:37 Design #649 (Feedback): Make SmallFpImpl safer to use
- [oops cut-and-paste did the wrong thing]
Changing to feedback; implemented the fn mentioned in comments 18-20. See #795 -
13:47 Design #649: Make SmallFpImpl safer to use
- John Abbott wrote:
> I am thinking of the name @InvModNoCheck@; it is pretty clear; it is a bit long, so that ought ... -
13:17 Design #649: Make SmallFpImpl safer to use
- I am thinking of the name @InvModNoCheck@; it is pretty clear; it is a bit long, so that ought to discourage "casual ...
-
11:49 Design #649: Make SmallFpImpl safer to use
- In @NumTheory.H@ there is a fn called @InvMod@ which expects two @MachineInt@; internally it calls the fn @InvMod_pri...
-
11:15 Design #649: Make SmallFpImpl safer to use
- I have resolved the mystery of the two identical functions running at different speeds: my test program was giving (v...
04 Nov 2015
-
19:41 Design #649 (Resolved): Make SmallFpImpl safer to use
- I have implemented @NonRedValue@.
Checked everything last night; revised examples, doc, etc.
Checked in today.
T...
03 Nov 2015
-
22:59 Feature #48: Squarefree factorization - multivariate polynomials, char 0
- I'm not sure; I suspect it will not work in every case.
What coeff ring did you have in mind? Were you thinking o... -
17:26 Feature #48: Squarefree factorization - multivariate polynomials, char 0
- In @factor.C@ there is the line:...
-
16:15 Bug #793: compilation on fedora 23: some worrying "error messages"
- I'm compiling some other programs; compilation time varies from 2mins to almost 5mins. I'll ask the technical guy if...
-
15:00 Bug #793: compilation on fedora 23: some worrying "error messages"
- I'm recompiling (with full debugging), and the mysterious @Fatal error@ messages have not reappeared; and anyway desp...
-
14:45 Bug #793: compilation on fedora 23: some worrying "error messages"
- John Abbott wrote:
> The new computer took *100mins* to compile and run the examples. Just running the examples take... -
12:56 Bug #793 (In Progress): compilation on fedora 23: some worrying "error messages"
- The new computer took *100mins* to compile and run the examples. Just running the examples takes only 30secs.
-
11:34 Bug #793: compilation on fedora 23: some worrying "error messages"
- I shall try to investigate this, but it may take a long time. The new computer seems to be quite fast (_e.g._ more t...
-
14:15 Design #794 (Rejected): ar gives warnings on fedora 23
- The archive creator @ar@ gives warnings about the use of @u@ flag with the @r@ flag (because the default is @D@).
... -
11:31 Design #649: Make SmallFpImpl safer to use
- I quite like @NonRedValue@; it is quite clear, and a bit long (to discourage "casual use"). I'll try changing the co...
02 Nov 2015
-
15:53 Design #649: Make SmallFpImpl safer to use
- John Abbott wrote:
> There is a question about names:
> * *@SmallFpImpl::value@* is the class for reduced values
>... -
15:01 Bug #793 (Closed): compilation on fedora 23: some worrying "error messages"
- Compilation on the new computer (with fedora 23, due for release tomorrow ?!!? according to Wikipedia) produced sever...
-
14:41 Slug #792: configure: search for libgmp too slow
- Since I believe that the @find@ command is the culprit, the solution would be to eliminate it. This could be done by...
-
14:39 Slug #792: configure: search for libgmp too slow
- The situation was the following. The new computer did not have GMP installed, so the attempt to use @-lgmp@ failed, ...
-
14:16 Slug #792 (Closed): configure: search for libgmp too slow
- I have new computer (here in Kassel). I am trying to build CoCoALib/CoCoA-5. The @configure@ script took *ages* to ...
30 Oct 2015
-
18:49 Design #649: Make SmallFpImpl safer to use
- When a @SmallFpImpl@ is printed currently it appears as @SmallFpImpl(p)@ where @p@ is the prime. Should the export c...
-
18:45 Design #649: Make SmallFpImpl safer to use
- I am not entirely happy with the length of the names for the export conventions:
* *@GlobalSettings::SymmResidues@*
... -
16:06 Design #649: Make SmallFpImpl safer to use
- I like all types in CoCoALib to be printable; naturally this includes *@value@* and *@uvalue@*.
@SmallFpImpl@ offers... -
10:56 Design #649: Make SmallFpImpl safer to use
- I now disagree with my comment number 3. I think that the impl using new types (classes) to represent the values is ...
-
10:47 Support #791: Clean code for DistrMPolyClean
- I'm hoping Anna will "volunteer" to do this ;-)
29 Oct 2015
-
21:55 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Victor Shoup said he made NTL threadsafe (using C++11)
-
14:52 Bug #790: RingDistrMPolyInlFpPPImpl::mySummandPool frees ZERO PTR many times
- John Abbott wrote:
> Now I am slightly undecided which implementation I prefer:
> Impl *(A)*:
> [...]
> Impl *(B)... -
11:56 Bug #790: RingDistrMPolyInlFpPPImpl::mySummandPool frees ZERO PTR many times
- Now I am slightly undecided which implementation I prefer:
Impl *(A)*:... -
14:04 Support #791 (New): Clean code for DistrMPolyClean
- There is quite a lot of cruft in @DistrMPolyClean.C@.
Remove everything that is no longer needed.
Perhaps also chec... -
14:02 Bug #680 (Resolved): DistrMPolyClean does not use MemPool for summands?
- I have now revised the code so that it uses its @MemPool@ for summands; essentially I had to "steal" the idea of @New...
28 Oct 2015
-
18:29 Design #789: NumTheory: behaviour of InvMod when inverse does not exist
- John Abbott wrote:
>
> Making @InvMod@ throw an exception is an interface change, so it could in principle break... -
15:25 Bug #790 (Resolved): RingDistrMPolyInlFpPPImpl::mySummandPool frees ZERO PTR many times
- The problem was a missing pair of curly brackets around a "then" clause comprising two commands (location @DistrMPoly...
-
11:15 Bug #790: RingDistrMPolyInlFpPPImpl::mySummandPool frees ZERO PTR many times
- I compiled CoCoALib with the @MemPool@ debugging options active.
In @test-SparsePolyRing1.C@ I inserted the followin... -
11:12 Bug #790 (Closed): RingDistrMPolyInlFpPPImpl::mySummandPool frees ZERO PTR many times
- I have run @test-SparsePolyRing1@ with @MemPool@ verbose active, and there were lots of warnings about freeing @ZERO ...
26 Oct 2015
-
11:54 Design #789 (In Progress): NumTheory: behaviour of InvMod when inverse does not exist
- Currently @InvMod(r,m)@ returns 0 if no inverse exists. This is simple to implement, and can easily be used by the c...
-
11:43 Design #789 (Closed): NumTheory: behaviour of InvMod when inverse does not exist
- Currently @InvMod(r,m)@ returns 0 if there is no inverse of @r@ modulo @m@.
Should it throw an exception (presumab...
22 Oct 2015
-
15:54 Bug #680: DistrMPolyClean does not use MemPool for summands?
- John Abbott wrote:
> I was a bit surprised to find that @DistrMPolyClean@ is not as clean as I had expected.
oops. I... -
15:37 Bug #680 (In Progress): DistrMPolyClean does not use MemPool for summands?
- I have mimicked the idea of @NewSummandPtr@ from @DistrMPolyInlFpPP@. It all compiles, and the tests pass (miracle?)...
-
15:14 Design #649: Make SmallFpImpl safer to use
- I think this is a good choice: it is exactly what we do for @ring@, so the code is overall more coherent
-
12:15 Design #649: Make SmallFpImpl safer to use
- After speaking to Anna, I have added @IsZero@ and @IsOne@, and also the new calls @zero(SmallFp)@ and @one(SmallFp)@....
-
13:49 Support #788 (New): No doc for DistrMPolyInlFpPP
- There is no documentation for @DistrMPolyInlFpPP@.
The documentation for @DistrMPolyInlPP@ is quite scant.
20 Oct 2015
-
17:37 Design #649: Make SmallFpImpl safer to use
- Why did I interfere with working code? Well, it's not working now; it's not even compiling! :-(
Well, @SmallFpImpl@... -
14:55 Feature #735: Convert a PPMonoidElem to RingElem with coefficient one
- Hi Anna. Could you finish this issue, and take it to "feedback"? Thanks, J
-
14:33 Feature #482 (In Progress): Unique copies of rings -- smart ctor
- Continuing with the assumption that rings in the registry will be destroyed (in reverse) order when the @GlobalManage...
19 Oct 2015
-
17:08 Design #787: Remove refcounts from RingElem?
- The comment about memory consumption is partly related to issue #786; if the "waste" per ring is small enough, it may...
-
16:53 Feature #180 (Resolved): GlobalManager: registration of global variables
- I've added some doc to @GlobalManager.txt@; it's probably not the best place, but no other place springs to mind.
... -
15:08 Feature #180: GlobalManager: registration of global variables
- I wonder whether the possibility to register the pair ptr+dtor should be removed later on. At the moment it is used ...
-
14:54 Feature #180: GlobalManager: registration of global variables
- I have implemented the clean version; the "nifty" version can be kept for later if it turns out that the stack of dto...
16 Oct 2015
-
16:19 Design #787: Remove refcounts from RingElem?
- So far we've been creating rings for temporary computations without worrying too much (indeed: starting every time wi...
-
14:07 Design #787 (New): Remove refcounts from RingElem?
- Ref counts tend to work badly in multithreaded environments (since the incr/decr operations have to be atomic, and/or...
-
14:34 Feature #180: GlobalManager: registration of global variables
- It seems that C++ STL provides no guarantees about the order of destruction of elements in a container: see @http://s...
-
14:20 Feature #180: GlobalManager: registration of global variables
- Here is a "trick" which could work:
define a function @void CallDtor(void* dtor) { dtor(); }@ and then
to register an... -
12:11 Feature #180 (In Progress): GlobalManager: registration of global variables
- I discovered yesterday that this has already been implemented (at least partly).
Furthermore the implementation wa... -
12:27 Feature #482: Unique copies of rings -- smart ctor
- I am considering as a "first step" towards possibly implementing unique copies of (some) rings to implement a global ...
15 Oct 2015
-
17:27 Design #785: finite fields: global register of fields already created?
- John Abbott wrote:
> and the rings must be destroyed in the correct order (reverse order of construction).
> THIS ... -
16:36 Design #785: finite fields: global register of fields already created?
- I modified my prototype so that it registered the @std::map@ for global destruction, then realised that the order of ...
-
15:49 Feature #142: Improve threadsafety
- After looking around on internet it seems that C++98 has no portable way of dealing with threadsafety, but C++11 (and...
14 Oct 2015
-
15:04 Design #786: MemPool: review min and max loaf sizes
- Thanks, Anna, for volunteering!
The relevant lines are in @MemPool.C@ around line 100.
Change @MinLoafBytes@ to... -
09:21 Design #786: MemPool: review min and max loaf sizes
- I think that @implicit@ could be a good test.
I can do it, could you give me indications on the first tests to try?... -
09:03 Feature #664: Impl small non-prime finite fields (using logs)
- If we construct a @F_p[x]/(f)@ would it be possible to convert it internally to your @F_q@? (I'm very ignorant on th...
13 Oct 2015
-
17:35 Design #785: finite fields: global register of fields already created?
- John Abbott wrote:
> Presumably the global register will comprise two @std::map@ objects: one for characteristics wh...
12 Oct 2015
-
17:13 Feature #664: Impl small non-prime finite fields (using logs)
- If CoCoALib offers a function which creates a (non-prime?) finite field given just its cardinality (or maybe characte...
-
16:58 Design #785: finite fields: global register of fields already created?
- Presumably the global register will comprise two @std::map@ objects: one for characteristics which fit into @long@, a...
-
16:14 Design #785: finite fields: global register of fields already created?
- JAA and Renzo discussed the idea of automatically creating all small, prime finite fields (up to size 32767, say) dur...
-
11:49 Design #785: finite fields: global register of fields already created?
- A global register of finite fields would imply that once a field has been created it cannot later be destroyed (unles...
-
11:44 Design #785 (New): finite fields: global register of fields already created?
- The rings @ZZ@ and @QQ@ are global and unique -- you cannot (any more) create two copies of @ZZ@ or of @QQ@.
The s... -
16:36 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Here's an example of what Meyers suggests:...
-
11:17 Bug #784: threadsafety: Scott Meyers's advice about cached values
- We definitely want CoCoALib to be threadsafe. It mostly is when compiled with @-DCoCoA_THREADSAFE_HACK@, but some se...
-
11:13 Bug #784 (In Progress): threadsafety: Scott Meyers's advice about cached values
- The first 17 mins of the video @EffectiveModernCpart6.mp4@ by Scott Meyers are about correct threadsafe design of cod...
-
16:01 Design #786: MemPool: review min and max loaf sizes
- Someone should do some benchmarking to see if changing the lower/upper limits for loaf size has any measurable effect...
-
15:58 Design #786: MemPool: review min and max loaf sizes
- The problem arose when I experimented creating all (prime) finite fields up to characteristic 32767. There are about...
-
15:50 Design #786: MemPool: review min and max loaf sizes
- I am reasonably sure that the upper limit is far too large: as it currently stands it can ask the system for 64M of c...
-
15:44 Design #786 (Closed): MemPool: review min and max loaf sizes
- Currently each @MemPool@ has a minimum and maximum loaf size set to 64K and 64M respectively.
Review these values;...
Also available in: Atom