Activity
From 24 Oct 2015 to 22 Nov 2015
21 Nov 2015
- 20:19 Feature #811: Add new fn SimplestBinaryRatBetween
- Checked in. Should be OK, but I do have some other files "pending", so it is possible I missed something -- can you ...
- 14:49 Feature #811 (Feedback): Add new fn SimplestBinaryRatBetween
- Implemented; documented (also C5); added test (NumTheory3)
- 14:48 Feature #811 (Closed): Add new fn SimplestBinaryRatBetween
- In some applications it is helpful to use "binary rationals" (denom is a power of 2).
Add a new fn *@SimplestBinaryR... - 15:09 Feature #440: Port RealRoots to C++
- After the SC^2 meeting it is clear that several people would like @RealRoots@ to be ported into C++. If the project ...
- 11:27 Design #786 (In Progress): MemPool: review min and max loaf sizes
- Did you also try tests which create lots of ring elements? Maybe a non-trivial GBasis?
20 Nov 2015
- 17:26 Design #786: MemPool: review min and max loaf sizes
- John Abbott wrote:
> Change @MinLoafBytes@ to 4*1024. Maybe you could also try 1024.
> Change @MaxLoafBytes@ to 64... - 15:01 Design #786: MemPool: review min and max loaf sizes
- John Abbott wrote:
> Are the problems my fault? Or some problem with the interface of @MemPool@? :-(
no, my pro... - 14:38 Design #786: MemPool: review min and max loaf sizes
- Are the problems my fault? Or some problem with the interface of @MemPool@? :-(
- 14:36 Support #810: ILogBase: change name?
- Personally I think that *@FloorLogBase@* is too long. Anyway, the fn should expect two args (of which the second is ...
- 14:34 Support #810 (Closed): ILogBase: change name?
- I was wondering about using a better name for @ILogbase@.
I used it recently in a new function, and couldn't remembe...
19 Nov 2015
- 15:06 Design #786: MemPool: review min and max loaf sizes
- about to try..
(some compilation problems...) - 06:50 Design #809 (New): FastCmp for degree -- useful?
- Is the function @FastCmp@ for @degree@ actually useful?
Check whether it is perceptibly faster than @cmp@; if so, ...
18 Nov 2015
- 23:29 Bug #808: Alg Extn by non-zero dim ideal
- The following variant works OK:...
- 23:28 Bug #808 (New): Alg Extn by non-zero dim ideal
- The following produces an NYI error for the reciprocal:...
14 Nov 2015
- 22:14 Design #592: Review design of ConstMatrixView
- I've still got problems with the new (internal) design for @BlockMat2x2@. While investigating I was quite surprised ...
- 20:34 Bug #807: DiagMat: mySetEntry checks the entry is writable only if debugging active
- As a general rule we say that mem fns do not perform arg sanity checks because such checks are the responsibility of ...
- 20:28 Bug #807 (Rejected): DiagMat: mySetEntry checks the entry is writable only if debugging active
- The mem fn @mySetEntry@ for @DiagMat@ checks that the indices indicate a diagonal element only if @CoCoA_DEBUG@ has b...
- 20:24 Design #806: AssignZero for matrix
- In some ways it would be nice to have a default impl of @AssignZero@; presumably as the mem fn @MatrixView::myAssignZ...
- 20:16 Design #806 (In Progress): AssignZero for matrix
- Before spending too much time deciding the exact semantics, we should also decide if the procedure is even useful -- ...
- 20:08 Design #806 (Closed): AssignZero for matrix
- There is a procedure @AssignZero@ for a matrix; it calls the mem fn @myAssignZero@.
What should these fns do? - 14:50 Design #311: XelMat, StdDegRevLexMat, ... should be MatrixView
- I've implemented the other defn of @StdDegRevLexMat@; we can decide later which impl will remain "active".
13 Nov 2015
- 14:51 Design #805: New type for "constant" matrices?
- As predicted in comment 1, there is a problem with @BlockMat2x2@. Not yet sure how to deal with it :-/
- 13:45 Design #805: New type for "constant" matrices?
- In principle the concrete classes for @IdentityMat@ and so on could derive from @matrix@ but then they have to impl l...
- 11:19 Design #805 (In Progress): New type for "constant" matrices?
- I believe that @ConstMatrixView@ is not the right type, because a matrix "view" is a way of looking at another object...
- 10:49 Design #805 (Closed): New type for "constant" matrices?
- I believe that implementing @IdentityMat@, @StdDegRevLexMat@ and so on as objects of type @ConstMatrixView@ is not co...
- 13:01 Design #311: XelMat, StdDegRevLexMat, ... should be MatrixView
- What do we want the @StdDegRevLexMat@ to be?
There are two obvious candidiates: here are 3x3 instances...
12 Nov 2015
- 14:51 Bug #804 (In Progress): ZeroMat and IdentityMat should produce a matrix not a ConstMatrixView
- Rather to my surprise I have failed to create an example where @ZeroMat@ (or @IdentityMat@) misbehaves -- no idea why...
- 14:22 Bug #804 (Closed): ZeroMat and IdentityMat should produce a matrix not a ConstMatrixView
- I think that @ZeroMat@ and @IdentityMat@ should produce a result of type @matrix@ and not one of type @ConstMatrixVie...
11 Nov 2015
- 18:19 Design #311: XelMat, StdDegRevLexMat, ... should be MatrixView
- After some hasty cut-and-paste work I have some code which compiles :-)
I'm not so foolish as to try running it... t... - 17:30 Design #311: XelMat, StdDegRevLexMat, ... should be MatrixView
- JAA is convinced that this is a good idea.
To get it finished quickly I shall ignore issue #592; it probably shoul... - 16:35 Design #602: OrdMat: should it be a reference to a MatrixView in all PPOrderings?
- JAA now thinks that there is an example (see issue #803) where it could be useful to have the order matrix(view) quic...
- 13:35 Design #602: OrdMat: should it be a reference to a MatrixView in all PPOrderings?
- How important is it that @OrdMat@ is fast? Is there a good example where we would want to compute repeatedly the @Or...
- 14:19 Feature #803 (In Progress): PPOrdering: use it to compute WDeg?
- The main task I want to simplify is that of implementing @myWDeg@, @myCmpWDeg@ and @myCmpWDegPartial@ for @PPMonoidSp...
- 13:43 Feature #803 (In Progress): PPOrdering: use it to compute WDeg?
- Should objects of type @PPOrdering@ be able to compute WDeg vectors and/or individual components of WDeg vectors?
... - 13:47 Slug #799: vector of "indets" in each PPMonoid?
- I have lowered the priority of this issue because it will take some time to complete, and the resulting improvement w...
- 10:01 Slug #799 (In Progress): vector of "indets" in each PPMonoid?
- As far as I can tell @PPMonoidBase::myIndets@ is used only once, in the (inefficient) fn @PPMonoidBase::mySymbolValue...
- 12:15 Feature #802: DivMask: extend interface?
- John Abbott wrote:
> I think updating would mean replacing the div-mask with that for the LCM of the old value and t...
10 Nov 2015
- 18:39 Feature #800: PPMonoidSparse: impl of sparse PPs
- John Abbott wrote:
> Might it be important to store the @StdDeg@ along with the list of (index, exp) pairs? If it i... - 16:45 Feature #800: PPMonoidSparse: impl of sparse PPs
- For @Wdeg@ I am inclined to compute it "on the fly" every time it is needed. If someone reports poor execution speed...
- 15:16 Feature #800: PPMonoidSparse: impl of sparse PPs
- The currently missing functions are: @myCmp@, @myWDeg@ and @myCmpWDeg@ (& a partial version). Also @myComputeDivMask...
- 14:49 Feature #800 (In Progress): PPMonoidSparse: impl of sparse PPs
- There was a very incomplete impl in @PPMonoidSparse.C@, which was already recognized by @Makefile@.
Apparently the... - 18:38 Feature #802: DivMask: extend interface?
- I think updating would mean replacing the div-mask with that for the LCM of the old value and the new indet-power. T...
- 18:33 Feature #802: DivMask: extend interface?
- John Abbott wrote:
> If we do extend the interface of @DivMask@ to accommodate the sparse repr, what should the exte... - 16:15 Feature #802: DivMask: extend interface?
- If we do extend the interface of @DivMask@ to accommodate the sparse repr, what should the extended interface expect:...
- 16:09 Feature #802 (In Progress): DivMask: extend interface?
- Currently the only way to make a (non-trivial) @DivMask@ is to use the function @myAssignFromExpv@ which clearly suit...
- 15:57 Feature #802 (In Progress): DivMask: extend interface?
- The new @PPMonoidSparse@ impl needs to supply a @myComputeDivMask@ mem fn.
The current interface is well suited to... - 10:17 Feature #747: New function for making list of symbols (indeterminate names)
- That's fine by me -- less work for me :-)
Indeed @symbols("x[1..3,2..5]")@ is not really that much more readable tha...
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...
Also available in: Atom