Activity
From 08 Dec 2019 to 06 Jan 2020
06 Jan 2020
-
06:46 CoCoALib Feature #1381 (In Progress): Type ideal for ZZ[x[1..n]]
- Is it possible to add the type ideal for the ring ZZ[x[1..n]]?
28 Dec 2019
-
19:03 CoCoALib Bug #1379: Fails to recognize zero-dim ideal
- I have added two new tests to *@CoCoA-5/tests/exbugs.cocoa5@* for this issue.
-
- Anna revised the code for *@GBasisByHomog@* (so that the resulting basis is interreduced).
Anna made a new version... -
-
- I have made a new version of @IamZeroDim@ which works with any GB -- no longer needs a minGB.
All tests pass. Check...
27 Dec 2019
-
19:20 CoCoALib Feature #1212: New function: GBasisByHomog
- checked-in. Made new pre-release for Mac.
-
- The trick didn't work ... they usually don't.
Fixed interreduction -
- I had implemented a _trick_ which I believed would be enough for interreducing (compute the GB twice).
But it is not... -
- I have written a first impl; with this impl, the problem case in issue #1379 works (well, it does not give NYI).
I... -
- Currently *@IsZeroDim@* and the impl via *@IamZeroDim@* require the original ideal to have a minimal GB.
However, ... -
- I'd like the @IamZeroDim@ impl to be more robust; _i.e._ it should work with any GB not just a minGB.
-
- John Abbott wrote:
> Here is an example where @GBasisByHomog@ returns a non-minGB
> [...]
ahhhh!! clue city!!
t... -
- John Abbott wrote:
> I have put a print command in the loop inside @IamZeroDim@ around line 530 in @SparsePolyOps-id... -
- Here is an example where @GBasisByHomog@ returns a non-minGB...
-
- With GDB, the problem seems to be from a call to @IsPrimary@ on line 735 of @SparsePolyOps-ideal-ZeroDim.C@ inside fn...
-
- I have put a print command in the loop inside @IamZeroDim@ around line 530 in @SparsePolyOps-ideal.C@.
It reports ... -
- What is the comment on line 528 about?
What happens if the GB is not a RGB? 8-O
Or is that impossible?
-
- JAA and Anna have confirmed the bug (with current CVS version).
The problem seems to be that the ideal is not recogn... -
- Robbiano reports (via email) that CoCoA incorrectly produces "error NYI" with the following input...
21 Dec 2019
-
- John Abbott wrote:
> I have just spent quite a while trying to work out where I could insert a time-out check inside... -
- I have just spent quite a while trying to work out where I could insert a time-out check inside the reduction code.
...
20 Dec 2019
-
- Proposal: create two functions for computing radicals
* *@radical@* which also tries hard to compute a GB for the r... -
- I propose doing an experiment along the following lines.
We create a collection of test ideals (perhaps as many a... -
- I have checked in the code (even though it is not quite finished yet). It worked tolerably well in my two tests.
-
- I have an improved impl, which I hope to check in fairly soon (later today?).
A problem with the description in co... -
- The main problem with checking for timeout during GB computation is that the times for each single reduction can vary...
17 Dec 2019
-
- I have changed *@configure@* so that it sets a flag saying whether to build the Qt GUI; this is determined by a comma...
16 Dec 2019
-
- Ulrich reported that the GUI fails to compile now that we are using *@nullptr@*.
I had a quick search online, and fo...
14 Dec 2019
-
- Now I'm thinking it may be simpler to use an approach like this:
measure actual @CpuTime@ difference over the last... -
- Reply to comment 6:
yes, @CpuTimeLimit@ does already attempt to adapt automatically. I'm discussing (with myself?) ...
13 Dec 2019
-
- The experimental results above suggest that approach *(B)* is probably too simplistic if there is any risk of a @CpuT...
-
- Here are the results of an extreme speed test for option *(B)* in the previous comment.
The simplistic test progra... -
- My current suggestions:
* *(A)* let the creator of the @CpuTimeLimit@ object specify a maximum interval between genu... -
- In the current CVS version, intervals between genuine checks can be as long as 1000000 calls.
*Quick reminder*: is... -
- A *@CpuTimeLimit@* object actually genuinely checks the time limit only every @N@ calls to the check function. The v...
-
- I was thinking of an alternative approach since the timeout mechanism is applied in so different cases:
The interval... -
- An important point to note is that the design of @CpuTimeLimit@ works best when the times between successive calls to...
-
- Instead of guessing, do this ;-)...
12 Dec 2019
-
- It seems that my guess was good.
In @CpuTimeLimit.C@ around line 67, the code allowed the interval between full ch... -
- I noticed the problem while using a simple program to look for ideals where it was costly to compute the RGB of the r...
-
- It seems that sometimes @GBasisTimeout@ does not timeout as one would expect.
I have just interrupted (via C-c C-c... -
- I have modified my program to call @GBasisTimeout@, and I specified 30s as the time-out.
I was a bit surprised to fi... -
- Here are some more examples where it takes a long time to compute RGB after computing radical:...
-
- The current solution (increasing the "increment" to 0.5) works well on the small examples I have tried: sometimes the...
-
- As reported in the previous comment, example 1 was still a problem. I increased the extra time (to 2.5s), then the c...
-
- After the change mentioned in issue #1375, the examples in comment 13 are now satisfactorily quick. The example in c...
11 Dec 2019
-
- Anna Maria Bigatti wrote:
> John Abbott wrote:
> > My simple idea was just to add say 0.1 to the actual measured ti... -
- Following Anna's suggestion I moved @t0 := CpuTime();@ to just before the computation of the radical; so the time dif...
10 Dec 2019
-
- Sometimes radical is computed with the GBasis, sometimes not: this depends on a timeout, which probably is a very cri...
-
- I have done more testing. The timings really do vary from run to run.
I wrote a shell script which took exactly t... -
- This getting more puzzling!
Here is another example: essentially the same code as in the original description but
...
09 Dec 2019
-
- I wanted to show the students an example where it is much better to use @IsInRadical@ than compute the radical (with ...
-
- I have observed some strange variations in timings when computing the RGB of a radical:...
-
- John Abbott wrote:
> I am inclined to say that there is not much point in writing any tests for @power@. What do yo... -
- I am inclined to say that there is not much point in writing any tests for @power@. What do you think?
-
- John Abbott wrote:
> If you are convinced that my approach is better, then, yes, please undo your CVS update.
ok
... -
- Should the function be documented?
If so, we should probably state that it exists just to increase compatibility b... -
- If you are convinced that my approach is better, then, yes, please undo your CVS update.
I am not certain whether ... -
- ooops, we overlapped and made incompatible changes.
But I think you had a better idea.
Should I undo my cvs?
-
- I have just checked in a @power@ function defined in @cocolib.cpkg5@.
My approach means that @power@ works for any t... -
- Implemented for RingElem (in OneLiners)
-
- In CoCoA we can write @g^4@, but in CoCoALib we have to write @power(g,4)@ (because of incompatible priority of @oper...
-
- Just for the record...
With the exponent pair (3,4), my computer takes about 2.4s whereas with the pair (4,5) it t... -
- Instant on my computer. I wonder how it was improved....
Also available in: Atom