On 09/15/2017 08:58 AM, oldk1331 wrote: > A bigger concern is, to avoid unnecessarily alloc memory, > I do the '<' or 'subtractIfCan' computation twice. I wonder > if it's a good tradeoff in general. It is good tradeoff in this case.
Yes. Interestingly, when I rewrote your initial patch by using list comprehension, I thought that it translates into code that builds the list from head to the end by always keeping one variable pointing to the end of the current list. But no, if one looks up what lisp code is produced for [x for x in somelist | odd? x] one sees that an intermediate result list is constructed (in the wrong order) using cons and at the end it is (destructively) reversed. Thinking a bit about this... It's not all that bad. Yes, it goes through the list twice, but the overhead of keeping and updating an additional variable pointing to the end of the list (in the algorithm I described above) is probably also a factor of 2. So, doing something twice is not always that bad. The question is how good is the memory management of FriCAS. Clearly, if (in the trunk-version of subtractIfCan) the allocated w := new(dim, 0)$Vector(R) is not returned (i.e. it fails), the vector should immediately be released back to the memory manager so that almost no time is needed if the next subtractIfCan creates a new vector. Well, currently FriCAS is pretty much sequential. So one could make a preallocation of a couple of vectors during domain instantiation and use them as a temporary store. It would, however, become a problem, if FriCAS is able to use more than one processor. I could imaging the following, though. DirectProduct(n, T) has a (local) variable allocatedVectors: List % which collects such vectors like the w from above if subtractIfCan ends in "failed". The function "new" would have to be reprogrammed to first inspect allocatedVectors an take the vector from there. Well, that requires a bit of discipline from the programmer to correctly "release" unused vectors to "allocatedVectors". No idea whether that is a good suggestion. Correct me if I'm wrong, but Aldor's memory management was divided in several parts. If memory was given back, it was collected according to its size, so a new allocation wouldn't have the need to claim memory from the operating system, but rather use the old data allocation. I'm not sure that there was something for arrays, but I guess, somthing similar would help. However, that's not so easy to program, because only the garbage collector in FriCAS knows when a vector is not referenced anymore. Otherwise, one would have to introduce a "releaseMemoryOfVariable(...)" and that would certainly add another pain to programmers. >> In fact, for the most common Groebner computations R is NNI, so I guess, >> it even makes sense to have specialized code for it. So then > Yes, for NNI to specialized so that it can be inlined. > >> map(subtractIfCan2$R, u, v) simply becomes something like u-v. > There's no u-v for NNI, there's no 'subtract' as you suggested, > so I use 'subtractIfCan2'. (bad name, I know) Oh, you had a "2" here. I overlooked this and wondered why your code didn't compile. > I noticed that too, so I suggest to add 'subtractIfCan2' for > CancellationAbelianMonoid, with signature (%,%)->%, > one should only use it when one can make sure it will > success, for example, z=sup(x,y);subtractIfCan2(z,x). > > About the name, I think 'subtractCan' is better? Oh, I would suggest "subtract: (%, %) -> %" so that subtract(x,y) returns z such that x = y + z if such a z exists (maybe one should require that the z is unique?). Otherwise it does whatever it likes (for example, delete the harddisk) or simply return an error, i.e. subtract should (by specification) only be applied if it is known that subtractIfCan does not return "failed". Why "subtract" and not "subtractIfCan2"? Well search for "IfCan" in the sources. I have the impression that for "fooIfCan" functions with signature Union(T, "failed") there is often a function foo with return type T. Best example is retract/retractIfCan. I wouldn't call such function "-", because one pretty much expects that "-" never fails. But that's not a very convinced opinion, only that subtract and subtractIf can better fits into the existing pattern. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
