Activity

From 18 Jan 2016 to 16 Feb 2016

13:57 Slug #842: PPMonoidSparse: comparisons are VERY SLOW: I have created a temporary hack to the code for the special case of @lex@ ordering. Essentially I have written a new... John Abbott
13:54 Slug #842 (New): PPMonoidSparse: comparisons are VERY SLOW: I have just tried with Mario to use @PPMonoidSparse@ rather than a normal dense repr (for a PPM with about 100 indets... John Abbott

14:13 Design #816 (Closed): Rename isqrt to FloorSqrt (following ilog renaming to FloorLog): Closing after 2 months in feedback.
John Abbott
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. John Abbott

14:23 Bug #776 (Closed): FloatStr prints a NUL character: No problems have surfaced in the last 5 months, so closing. John Abbott
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... John Abbott
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.... John Abbott

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... John Abbott
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@... Anna Maria Bigatti
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... John Abbott
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... John Abbott
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... John Abbott

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... Anna Maria Bigatti
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... John Abbott

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... John Abbott
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... John Abbott
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... John Abbott

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... John Abbott
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... John Abbott
17:56 Feature #840 (In Progress): GINV: alex basis: Let some fns form GINV be callable from CoCoALib; in ptic "alex" basis.
John Abbott

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:... John Abbott
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... John Abbott
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... John Abbott

Also available in: Atom

CoCoA » CoCoALib