someone wrote: > > > I am planning new release. It would be nice to release > > before Easter, but I would also like to looks at open > > bugs and fix some so beginning of April is more realistic. > > Some open questions or tasks for the new release: > > 1.) What about these renamings: > - "mrv_limit" -> "mrvLimit" or even "limit" (And many more inside the > package) > - "Pfaffian" -> "pfaffian" > > I sent to the list an (incomplete) Patch for these two some time ago.
I do not want to change 'mrv_limit' to 'mrvLimit'. In my experince it is easier to work with code if names are always spelled the same way. The 'mrvLimit' leads to varied spelling of 'limit': when alone it is 'limit' while in compounds it is 'Limit'. For this reason I adopted 'mrv_limit' convention for "implementation" names. I consider 'mrv_limit' as part of implementation of 'limit'. In the future 'mrv_limit' may replace current 'limit' and then we will probably change 'mrv_limit' to 'limit'. Concerning "Pfaffian", I am not sure how much we want to enforce convention on exported names. For example changing 'Gamma' to 'gamma' would be misleading and I would be stringly against such change. Given that we will have exceptions anyway, when I noticed 'Pfaffian' some time ago I decided that changing it is not worth the trouble. > > 2.) Which fix do we use for the wrong values of "Shi" and "Chi"? > I think you wanted to try another solution that what I suggested > first. What is the state of this? AFAICS the "wrong" examples posted on the list are actually OK, that is difference between true and computed result is within error bounds (see my last message in the thread). We should increase accuracy of those functions because for some other arguments error is slightly larger than promised. > > 3.) What did we decide about the counting sorting algorithms I wrote? > >From my point of view they should be ready. > > https://github.com/raoulb/fricas/tree/bubblesort > As I wrote 'number of exchanges done by sort' is not well-defined and for this reason unlikely to be of wider use. There is well-definded length function on permutation group which is somewhat similar to what you compute, but I would be surprised if your code computes length. So ATM, what you do looks at attempt to optimize cases when we need sort + parity of permutation. More precisely, it looks like premature optimization Concerning merge sort: the default sort is merge sort, so we already have one implementation. BTW: AFAICS SortPackage is not used by any other part of algebra. It is included because it is used as an example in chapter 11.7 of the Axiom book. > 4.) Do we want to include the MatrixManipulation package into Fricas? > I discovered that it's already part of Axiom. I will look at it. My impression from your messages was that you want to work out some problems. -- Waldek Hebisch [email protected] -- 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 http://groups.google.com/group/fricas-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
