Activity
From 10 Jan 2016 to 08 Feb 2016
02 Feb 2016
- 14:13 Design #816 (Closed): Rename isqrt to FloorSqrt (following ilog renaming to FloorLog)
- Closing after 2 months in feedback.
- 12:36 Design #649 (Closed): Make SmallFpImpl safer to use
- I have just checked the documentation, and it seems to be complete. So I'm marking this issue as closed.
01 Feb 2016
- 14:23 Bug #776 (Closed): FloatStr prints a NUL character
- No problems have surfaced in the last 5 months, so closing.
- 14:21 Feature #747 (Closed): New function for making list of symbols (indeterminate names)
- There's no real point in keeping this issue open. I've added a reference to this issue in the doc for @symbol@, just...
- 13:38 Feature #747 (Feedback): New function for making list of symbols (indeterminate names)
- This new fn @symbols@ has been working fine for at least 3 months, so I have deleted the old ones (both from @symbol....
27 Jan 2016
- 22:57 Feature #664: Impl small non-prime finite fields (using logs)
- I quite understand the concern about possible confusion.
I am also concerned about creating a "shadow" polyring fo... - 22:27 Feature #664: Impl small non-prime finite fields (using logs)
- John Abbott wrote:
> However a user might find it strange that an element of @FFq@ which prints out as @12*sqrt2-17@... - 21:16 Feature #664: Impl small non-prime finite fields (using logs)
- Printing of elems of a (non-prime) finite field needs to be sorted out.
In fact the way an element of a (non-prime... - 16:14 Feature #664: Impl small non-prime finite fields (using logs)
- Currently elements of a @RingFq@ print in a non-standard way. I think it is quite easy to read, so am happy to leave...
- 16:12 Feature #664: Impl small non-prime finite fields (using logs)
- Aha! Now you have to click on @Edit@ to add a new progress message (previously it was @Update@, IIRC).
I have add...
23 Jan 2016
- 22:21 Design #841: NewPolyRing: tidy up the many different versions
- I have not checked the actual code, but I think we could have abstract implementations myNewPolyRing dealing with the...
- 20:48 Design #841 (In Progress): NewPolyRing: tidy up the many different versions
- [after speaking to Anna]
Here is a possible design:
there is a single "very general" pseudo-ctor which is the only wa...
21 Jan 2016
- 14:09 Design #841: NewPolyRing: tidy up the many different versions
- I now notice that there are also 6 fns called @NewPolyRing_DMPI@ and 5 fns called @NewPolyRing_DMPII@; this gives a t...
- 13:27 Design #841: NewPolyRing: tidy up the many different versions
- JAA thinks that the best design would have all @NewPolyRing@ fns pass through a single "base" fn; so there would be j...
- 13:09 Design #841 (In Progress): NewPolyRing: tidy up the many different versions
- Currently (Jan 2016) there are many different fns called @NewPolyRing@ offering the caller the possibility to specify...
20 Jan 2016
- 18:01 Feature #840: GINV: alex basis
- We shall also need a data structure in CoCoALib to represent the alex basis (or alex-GB basis). What should this str...
- 17:59 Feature #840: GINV: alex basis
- Mario has already done a quick comparison between his impl of Janet basis and that in GINV (by Gerdt and Blinkov) - G...
- 17:56 Feature #840 (In Progress): GINV: alex basis
- Let some fns form GINV be callable from CoCoALib; in ptic "alex" basis.
18 Jan 2016
- 18:12 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Following on from the previous comment... here is how we can test whether the value has already been computed:...
- 15:54 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Below is what I think would be the solution using @async@ and @shared_future@. It requires a single data-member of t...
- 13:23 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Mario and I are reading about some of the new features in C++ (v.11 and v.14). To me it seems that a "deferred" @fut...
13 Jan 2016
- 15:41 Feature #839: SparsePolyIter: make more compatible with STL
- interesting syntax :-)
looks quite horribly complicated to implement though :-( - 14:26 Feature #839: SparsePolyIter: make more compatible with STL
- Another idea is to have separate iterator types for the coeffs and the PPs; but the problem of not being able to refe...
- 14:23 Feature #839: SparsePolyIter: make more compatible with STL
- A possible solution would be to return an "index" which can be converted into a usable value via a memfn of the polyn...
- 14:19 Feature #839: SparsePolyIter: make more compatible with STL
- As a quick reminder: the new @for@-loop syntax is like this:...
- 14:11 Feature #839 (In Progress): SparsePolyIter: make more compatible with STL
- Mario has suggesting making @SparsePolyIter@ more compatible with C++ (and STL); for instance this would allow use of...
11 Jan 2016
- 15:05 Feature #838: Differential algebra
- Werner pointed out that it is (or "can be"?) useful to have an ordering on the derivatives, and that the interesting ...
- 15:00 Feature #838: Differential algebra
- More details. My understanding is that there are two types of "variable": independent variables (@x[1]@ to @x[n]@) a...
- 14:16 Feature #838: Differential algebra
- Here are some notes following a discussion I had with Werner last week... there may be some mistakes if I have not un...
- 13:43 Feature #838 (In Progress): Differential algebra
- Werner has suggested that CoCoA could offer differential algebras.
If I have understood correctly, these are a bit...
Also available in: Atom