Activity
From 08 Jun 2020 to 07 Jul 2020
26 Jun 2020
- 17:28 Design #1462: Change CoCoA_ERROR into CoCoA_THROW_ERROR
- Upon Anna's request I have put back @CoCoA_ERROR@, hopefully in such a way that it gives useful error mesgs if someon...
- 17:26 Feature #1466 (Resolved): Ops += *= etc for Matrices?
- I have put in an obvious impl in *@MatrixOps.H@* (all defns are @inline@).
Everything compiles fine, but I have done...
25 Jun 2020
- 09:51 Feature #1470: Get indexed indets from a polyring
- As usual, indexes should be of type @long@ (no need for @BigInt@).
It seems reasonable to allow a "short-cut" for ... - 09:48 Feature #1470 (New): Get indexed indets from a polyring
- Make a class so that indexed indets from a polyring can be used with their "natural" indexes (rather than, say, c++ v...
- 05:33 Feature #1468: Adjoin indets to a poly ring
- Description above is incomplete:
* what term ord on @QQ[x,y,a,b]@? For impl, it would be nice if the orderings were... - 05:25 Feature #1468 (In Progress): Adjoin indets to a poly ring
- Make it easy to "adjoin" indets to a poly ring.
JAA thinks this means: given polyring @QQ[x,y]@ and new indets @a,...
22 Jun 2020
- 10:54 Design #1467 (In Progress): Change syntax apply(phi,M) into phi(M)?
- We could permit both syntaxes, perhaps making *@apply(...)@* obsolescent?
[JAA does not much like having two differe... - 10:44 Design #1467: Change syntax apply(phi,M) into phi(M)?
- I noticed this while making a prototype impl for automatic ringelem promotion. In particular for ringelem times matr...
- 10:39 Design #1467 (Closed): Change syntax apply(phi,M) into phi(M)?
- Currently to apply a RingHom to the entries of a matrix or a C++ vector we must use the fn *@apply@*.
Is it better... - 10:34 Feature #1150: New fn: transform ideal with ring hom
- What is this supposed to mean? Does it mean the ideal generated by @{phi(f) | f in I}@? What else could it mean?
W... - 10:26 Feature #1466 (In Progress): Ops += *= etc for Matrices?
- It is not _necessary_ to make these operators, but anyone used to C++ might expect them to work.
I suggest:
* mak...
21 Jun 2020
- 11:11 Feature #1466 (Closed): Ops += *= etc for Matrices?
- Should we make "assign-op" operators for matrices?
20 Jun 2020
- 21:42 Design #1465 (In Progress): mul(MAT,MAT,MAT)
- I have commented out the fn, and modified *@power(MAT,n)@*.
Everything compiles and runs fine.
I suggest eliminat... - 21:40 Design #1465 (In Progress): mul(MAT,MAT,MAT)
- There is a fn *@mul(MAT,MAT,MAT)@*
Is it any use?
The impl is exception-safe, so internally it creates a new mat,...
19 Jun 2020
- 20:27 Design #1462: Change CoCoA_ERROR into CoCoA_THROW_ERROR
- I have removed the macro *@CoCoA_THROW@* for the following reasons:
* a macro is an ugly implementation trick
* it ... - 09:41 Design #1464 (New): What is the difference between InterruptReceived and InterruptedBySignal
- It seems to be superfluous to have both *@InterruptReceived@* and *@InterruptedBySignal@*.
Review the design/impl; a...
17 Jun 2020
- 21:02 Design #1462 (Feedback): Change CoCoA_ERROR into CoCoA_THROW_ERROR
- I have updated doc too. Also checked that everything works with debugging active.
- 20:08 Design #1462: Change CoCoA_ERROR into CoCoA_THROW_ERROR
- I have changed all calls to @CoCoA_ERROR@ into @CoCoA_THROW_ERROR@; I do think the code is a bit more readable with @...
- 20:19 Design #1463 (In Progress): SmoothFactor: use FactorMultiplicity
- The current implementation of @FactorMultiplicity@ makes it hard to use inside @SmoothFactor@ (because it returns onl...
16 Jun 2020
- 20:03 Design #1462 (In Progress): Change CoCoA_ERROR into CoCoA_THROW_ERROR
- I have started. Defined the new macros @CoCoA_THROW_ERROR@ (drop in replacement for current @CoCoA_ERROR@).
Also de... - 16:55 Design #1462 (Closed): Change CoCoA_ERROR into CoCoA_THROW_ERROR
- I suggest changing name of the macro to *@CoCoA_THROW_ERROR@* so that it i obvious to the reader that the error objec...
- 20:01 Feature #1457 (Feedback): Make SmoothFactor interruptible
- Speed test was OK. Also improved impl of @SmoothFactor@, but see #1463.
Checked in.
- 16:29 Feature #1457 (Resolved): Make SmoothFactor interruptible
- The problem is that @SmoothFactor@ has two (nested) loops either of which can be slow; but I had inserted a call to @...
- 19:56 Design #1463 (Closed): SmoothFactor: use FactorMultiplicity
- @SmoothFactor@ contains almost a duplicate implementation of @FactorMultiplicity@.
Tidy up: Make @SmoothFactor@ ca... - 19:54 Slug #1170: SmoothFactor: slow when a factor is found
- The given example is no longer slow.
The trick of testing for primality is used only when @RemainingFactor@ is not t... - 16:45 Bug #1458 (Rejected): Redesign interrupt mechanism?
- What I wrote in comment 5 was perhaps once correct, but not any longer.
This bug did not exist where I thought it ex...
Also available in: Atom