Activity
From 26 Jun 2016 to 25 Jul 2016
22 Jul 2016
-
13:21 CoCoA-5 Slug #907: ApproxSolve very slow on this example
- Do you really need lex? I vaguely recall using several eliminations to compute the various polynomials of the form @...
-
12:17 CoCoA-5 Slug #907: ApproxSolve very slow on this example
- John Abbott wrote:
> OK. @ApproxSolve2@ solves the problem in about 0.8s (on my old MacBook... it'll be faster on t... -
- OK. @ApproxSolve2@ solves the problem in about 0.8s (on my old MacBook... it'll be faster on the new computer, if De...
-
- A simple quick test passed: @ReadExpr(P, "1.2*x");@ produced the expected result.
JAA notes that there is a minor ...
21 Jul 2016
-
- John Abbott wrote:
> I have just tried the examples again (after Anna revised @ApproxSolve@ yesterday or this mornin... -
- I have just tried the examples again (after Anna revised @ApproxSolve@ yesterday or this morning). It still seems to...
-
- I have made the necessary (small) changes to @RingElemInput.C@.
Currently there is no specific test for @ReadExpr@, ... -
- Anna pointed out that CoCoA-4 has always converted "decimal" numbers into exact rationals; CoCoA-5 does so too. So i...
-
- I have cleaned the code and checked in. It's a bit ugly :-(
-
- I now have a first impl (with test suite). I implemented *(A)* and *(B)*, but it is easy to restrict to just *(A)*. ...
-
- John Abbott wrote:
> Exactly what syntax do we want for decimal fractions?
> * *(A)* <optional-sign><unsigned-integ... -
- I have clarified (and made more stringent) the syntax for rational numbers. There are two possibilities:
* <optiona... -
- I have looked quickly at the code for @operator>>@ for @BigRat@, and it probably contains a "small bug". The usual r...
19 Jul 2016
-
- How about the name @BinaryRatApprox@?
Mmm, well, that is exactly what @FloatApprox@ does in other cases, but it's ca... -
- My argument that creating a @MantExp2@ structure makes evident the precision is correct, but there are several occasi...
-
- The functions which need to be considered are: @operator>>@ and @ConvertTo@.
JAA observes that CoCoA-5 (and older ... -
- Currently @operator>>@ for @BigRat@ expects the input to be of the form: integer or integer "/" integer.
Should it... -
- The current code simply uses @operator>>@ for a @BigInt@.
We could replace it with @operator>>@ for @BigRat@, but th... -
- The function @ReadExpr@ should also read the decimal point...
-
- I've added the improvements we talked about at ICMS Berlin.
Now this example is almost instant :-) :-)
There are a ...
14 Jul 2016
-
- The current strategy is that the generators of the sum is the concatenation of the generators of the two ideals. Is ...
-
- On my old MacBook with CoCoA-5.1.5 this computation took more than 1 hour (then I stopped it).
-
- While "playing" with a demo of sparse squares, I noticed that @ApproxSolve@ is strangely slow on this example (while ...
13 Jul 2016
-
-
- We should keep copies of external libraries guaranteed compatible with cocoalib.
(also useful for compiling old ver...
07 Jul 2016
-
- I had a quick look at the txt2tags website. It seems likely that a "filter" can solve the problem, but I don't know ...
-
- txt2tags does not correctly handle double quotes when generating LaTeX.
The end result is that the PDF generated h...
04 Jul 2016
-
- The source code for @SmallFpDoubleImpl@ includes its own impl of @InvMod@ which uses @double@ rather than an integral...
-
- The function @GFanIdeals@ (was @AllReducedGroebnerBases@) has a very big output.
Usually one needs to run a function...
30 Jun 2016
-
- I am still a bit perplexed by this issue.
Having @InvMod@ always throw seems to me to be the cleanest and safest s...
29 Jun 2016
-
- Perhaps the best approach is not to worry about @noexcept@ at the moment since we have no experience of the feature. ...
-
- If we do adopt the idea of different signatures for throwing and non-throwing versions, which approach is better:
* ... -
- I have just thought of an argument in favour of Anna's proposed design (namely, different signatures).
In C++11 ther... -
- John Abbott wrote:
> Currently the @enum ErrorActionIndicator@ is defined inside @NumTheory.H@;
May we call it @e... -
- Currently the @enum ErrorActionIndicator@ is defined inside @NumTheory.H@; probably it should be moved to @utils.H@ s...
-
- I have just checked in my impl. Perhaps Anna could have a look at it, and decide whether she thinks it is comprehens...
-
- John Abbott wrote:
> Your approach requires me to add 5 new signatures (for a total of 10);
good point!
-
- @Anna: your approach is quite possible but it is more awkward than what I have implemented.
My approach has an opt... -
- I'd rather have (as I said in comment #10)...
-
- I have implemented @enum ErrorActionIndicator { ThrowOnError, NoThrow };@
And the functions now have a 3rd arg @co...
28 Jun 2016
-
- John Abbott wrote:
> Perhaps the @NoThrow@ arg as suggested in comment 9 is clearer?
clearer
-
- Here is another proposal for the interface:
* @InvMod(r,m)@ throws if the inverse does not exist
* @InvMod(r,m, fla... -
- John Abbott wrote:
> Another possible interface is an optional 3rd arg to say not to throw: _e.g._ @InvMod(res,mod,N...
27 Jun 2016
-
- Another possible interface is an optional 3rd arg to say not to throw: _e.g._ @InvMod(res,mod,NoThrow)@. This avoids...
-
- We can indeed supply two (or more?) fns.
I like @InvMod@ as it currently is: it can be used conveniently inside a fo... -
- The documentation was already updated to say that @ERR:DivByZero@ is thrown if the inverse does not exist.
Note th... -
- Thinking about it: I would prefer to have 0 if it is relatively costly to determine if it is divisible.
We also ha... -
- The actual implementations in @NumTheory.C@ do throw rather than return 0 -- I do not know when the code was changed....
-
- *@ExtensionDeg@* is certainly clearer than *@ExtnDeg@*. Right now I cannot think of any good reason to push for succ...
-
- John Abbott wrote:
> I think it makes most sense to change @LogCardinality@ to @ExtnDeg@ (any other candidate names?... -
- I think it makes most sense to change *@LogCardinality@* to *@ExtnDeg@* (any other candidate names?), and then to rej...
-
- John Abbott wrote:
> I'm not enthusiastic about a function for computing the cardinality.
> * As Anna recalled, the... -
- I'm not enthusiastic about a function for computing the cardinality.
* As Anna recalled, there is already *@LogCardi... -
- JAA wrote in issue #107
> JAA wonders whether *@ExtnDeg@* may not be a better name for *@LogCardinality@*. The name ... -
- We currently have the function @LogCardinality@ for a finite field.
Should we also have @cardinality@?
Should it wo... -
- done, cvs-ed.
Needs proper testing -
- Convert code from CoCoA-5
-
- From existing functions in CoCoA-5
-
- Convert code from CoCoA-5
-
- Convert code from CoCoA-5
-
- Implemented, need proper testing.
-
- *2017-11*: actual setting of flags is discussed in #924
-
- Implementation of @IsMaximal@ for multivariate rings now allows working non-simple extensions.
Also available in: Atom