Activity
From 18 Sep 2015 to 17 Oct 2015
16 Oct 2015
-
16:19 Design #787: Remove refcounts from RingElem?
- So far we've been creating rings for temporary computations without worrying too much (indeed: starting every time wi...
-
14:07 Design #787 (New): Remove refcounts from RingElem?
- Ref counts tend to work badly in multithreaded environments (since the incr/decr operations have to be atomic, and/or...
-
14:34 Feature #180: GlobalManager: registration of global variables
- It seems that C++ STL provides no guarantees about the order of destruction of elements in a container: see @http://s...
-
14:20 Feature #180: GlobalManager: registration of global variables
- Here is a "trick" which could work:
define a function @void CallDtor(void* dtor) { dtor(); }@ and then
to register an... -
12:11 Feature #180 (In Progress): GlobalManager: registration of global variables
- I discovered yesterday that this has already been implemented (at least partly).
Furthermore the implementation wa... -
12:27 Feature #482: Unique copies of rings -- smart ctor
- I am considering as a "first step" towards possibly implementing unique copies of (some) rings to implement a global ...
15 Oct 2015
-
17:27 Design #785: finite fields: global register of fields already created?
- John Abbott wrote:
> and the rings must be destroyed in the correct order (reverse order of construction).
> THIS ... -
16:36 Design #785: finite fields: global register of fields already created?
- I modified my prototype so that it registered the @std::map@ for global destruction, then realised that the order of ...
-
15:49 Feature #142: Improve threadsafety
- After looking around on internet it seems that C++98 has no portable way of dealing with threadsafety, but C++11 (and...
14 Oct 2015
-
15:04 Design #786: MemPool: review min and max loaf sizes
- Thanks, Anna, for volunteering!
The relevant lines are in @MemPool.C@ around line 100.
Change @MinLoafBytes@ to... -
09:21 Design #786: MemPool: review min and max loaf sizes
- I think that @implicit@ could be a good test.
I can do it, could you give me indications on the first tests to try?... -
09:03 Feature #664: Impl small non-prime finite fields (using logs)
- If we construct a @F_p[x]/(f)@ would it be possible to convert it internally to your @F_q@? (I'm very ignorant on th...
13 Oct 2015
-
17:35 Design #785: finite fields: global register of fields already created?
- John Abbott wrote:
> Presumably the global register will comprise two @std::map@ objects: one for characteristics wh...
12 Oct 2015
-
17:13 Feature #664: Impl small non-prime finite fields (using logs)
- If CoCoALib offers a function which creates a (non-prime?) finite field given just its cardinality (or maybe characte...
-
16:58 Design #785: finite fields: global register of fields already created?
- Presumably the global register will comprise two @std::map@ objects: one for characteristics which fit into @long@, a...
-
16:14 Design #785: finite fields: global register of fields already created?
- JAA and Renzo discussed the idea of automatically creating all small, prime finite fields (up to size 32767, say) dur...
-
11:49 Design #785: finite fields: global register of fields already created?
- A global register of finite fields would imply that once a field has been created it cannot later be destroyed (unles...
-
11:44 Design #785 (New): finite fields: global register of fields already created?
- The rings @ZZ@ and @QQ@ are global and unique -- you cannot (any more) create two copies of @ZZ@ or of @QQ@.
The s... -
16:36 Bug #784: threadsafety: Scott Meyers's advice about cached values
- Here's an example of what Meyers suggests:...
-
11:17 Bug #784: threadsafety: Scott Meyers's advice about cached values
- We definitely want CoCoALib to be threadsafe. It mostly is when compiled with @-DCoCoA_THREADSAFE_HACK@, but some se...
-
11:13 Bug #784 (In Progress): threadsafety: Scott Meyers's advice about cached values
- The first 17 mins of the video @EffectiveModernCpart6.mp4@ by Scott Meyers are about correct threadsafe design of cod...
-
16:01 Design #786: MemPool: review min and max loaf sizes
- Someone should do some benchmarking to see if changing the lower/upper limits for loaf size has any measurable effect...
-
15:58 Design #786: MemPool: review min and max loaf sizes
- The problem arose when I experimented creating all (prime) finite fields up to characteristic 32767. There are about...
-
15:50 Design #786: MemPool: review min and max loaf sizes
- I am reasonably sure that the upper limit is far too large: as it currently stands it can ask the system for 64M of c...
-
15:44 Design #786 (Closed): MemPool: review min and max loaf sizes
- Currently each @MemPool@ has a minimum and maximum loaf size set to 64K and 64M respectively.
Review these values;...
09 Oct 2015
-
20:20 Bug #783 (Feedback): abs for MachineInt
- Checked in several files: new @MachineInt.H@ and several consequential changes.
I got the redmine reference wrong wh... -
13:49 Bug #783: abs for MachineInt
- The problem of @::std::abs@ being hidden (when inside @namespace CoCoA@) persists even after @abs(MachineInt)@ has be...
-
12:23 Bug #783: abs for MachineInt
- I have implemented the suggestion in comment 3 above. Also changed all files which need to be changed; now running a...
-
11:31 Bug #783: abs for MachineInt
- I have observed to uses for @abs(MachineInt)@:
* to obtain the absolute value (_e.g._ in some division/remainder fun... -
10:52 Bug #783 (In Progress): abs for MachineInt
- I think there are two possible approaches:
# rename @abs(MachineInt)@
# ensure that the standard library @abs@ fns ... -
10:50 Bug #783: abs for MachineInt
- I found the problem when trying to investigate why @test-NumTheory1.C@ produced warnings (about comparing @signed@ an...
-
10:46 Bug #783 (Closed): abs for MachineInt
- There is a fn called @abs@ for @MachineInt@; it works fine (and returns an @unsigned long@).
The problem is that i... -
20:18 Feature #586 (Rejected): BigInt ctor from a machine integer
- Checked in the commented out defns of ctors for @BigInt@ direct from machine integer types.
Marking as "Rejected" ... -
14:09 Feature #586: BigInt ctor from a machine integer
- @Christof:
Yes, I implemented 8 new ctors for @BigInt@ direct from the various C++ machine integer types; and yes, t... -
11:32 Feature #586: BigInt ctor from a machine integer
- So to make sure I got it right. You implemented the constructures @BigInt(long)@ and so on, and now get this ambiguit...
-
09:47 Feature #586: BigInt ctor from a machine integer
- I've decided for option *(A)* "undo"; the others seem to be too much hassle+risk.
I'll comment out the new BigInt ...
08 Oct 2015
-
17:53 Feature #586: BigInt ctor from a machine integer
- I'll think about it overnight, but suspect that "undo" is the best (=least bad) solution.
-
17:52 Feature #586: BigInt ctor from a machine integer
- There is an option *(C)* but it is not realistic: I could define @operator>@ between @BigInt@ and each of the actual ...
-
17:51 Feature #586: BigInt ctor from a machine integer
- John Abbott wrote:
> Right now I do not see any good way out of this:
> * *(A)* undo: _i.e._ no implicit coversion ... -
17:33 Feature #586: BigInt ctor from a machine integer
- I have just encountered a bigger problem...
Line 167 of @BigInt.C@ wants to evaluate the expression @N > 0@ where @N... -
16:58 Feature #586: BigInt ctor from a machine integer
- John Abbott wrote:
> However C++ allows only a single stage of conversion when doing automatic conversions.
well,... -
16:33 Feature #586: BigInt ctor from a machine integer
- I have found a catch...
If @a@ and @b@ are variables of type @int@, and the only signature for @lcm@ expects two @Bi... -
15:33 Feature #586: BigInt ctor from a machine integer
- Here are the fns which would benefit from having implicit conversion to @BigInt@:
* @ILogBase@ --> need just 1 signa... -
15:13 Feature #586: BigInt ctor from a machine integer
- On several occasions the design of CoCoALib has preferred the path of "ease of use" over that of "absolute speed". S...
-
12:18 Feature #586: BigInt ctor from a machine integer
- There could be some minor benefit to @NumTheory.H@ especially @PowerMod@ which has 8 different signatures to cover al...
-
12:04 Feature #586: BigInt ctor from a machine integer
- As a check I reinserted the @explicit@ keyword and tried to compile: two (minor) problems arose in @NumTheory.C@ wher...
-
11:02 Feature #586: BigInt ctor from a machine integer
- It seems that I had forgotten about this task. I will try to finish it now.
-
14:48 Support #621 (Closed): Release: CoCoALib-0.99536
-
14:47 Support #754 (Closed): Release: CoCoALib-0.99538 (together with CoCoA-5.1.2)
24 Sep 2015
-
18:23 Feature #762: ExternalLib-GFan: first prototype
- (Rudimentary) documentation is done.
-
18:11 Feature #762 (Closed): ExternalLib-GFan: first prototype
- First prototype is done and working!!
Current design is:
- cone functions are in CoCoALib
- GroebnerFan algorithm ... -
18:22 Feature #780 (In Progress): GroebnerFan/ExternalLib-GFan: improve package
- In the package there are lots of operations on integers and those would surely be faster in cocoalib (at some point)....
-
18:16 Feature #780 (In Progress): GroebnerFan/ExternalLib-GFan: improve package
- First prototype is working.
Investigate and improve it, and implement it in cocoalib.
22 Sep 2015
-
11:15 Slug #773: DMPZmerge: make non-recursive
- It does! Thanks for the fix!
*NOTE* phew! Thanks for the confirmation :-)
21 Sep 2015
-
14:20 Slug #773 (Feedback): DMPZmerge: make non-recursive
- I have checked in a cleaned up version of the new code.
I hope Christof will verify that this version is still fine.
-
13:48 Slug #773: DMPZmerge: make non-recursive
- I can confirm that it is working with your quickly hacked code!
18 Sep 2015
-
14:41 Slug #773: DMPZmerge: make non-recursive
- I have now rewritten the hacked code in a cleaner way, but shall still wait for confirmation from the Normaliz group ...
Also available in: Atom