> > > 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.
Ok. Thanks for explaining your view. > 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'. I'm not sure if this is a good idea as mrv is powerful but limited to a (although large) class of functions where top-level "limit" could switch between several algorithms covering different classes of functions. (F.e. mrv can not really handle oscillatory expressions.) > 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. Right, for some special functions we are never allowed to change the name. Depending on the source [1], there is a "Si" and a "si" which are different functions! [1]: http://en.wikipedia.org/wiki/Trigonometric_integral > Given that we will have exceptions anyway, when I noticed > 'Pfaffian' some time ago I decided that changing it > is not worth the trouble. Ok. Then let's forget about this. > > 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. Maybe one should interface to other libraries for numerics. AFAIK Axiom can use GMP and related libraries for arbitrary precision computations. There is a really nice new library for ball arithmetics: http://fredrikj.net/arb/ http://fredrikj.net/blog/ The most interesting point (beside being one of the fastest libraries of its kind) is the rigorous error control. > > 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. That can be and I'd be surprised too because I did never consider this. The wideness of use depends on how often one needs to compute the sort + parity. I do not claim anything on this. > 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 I only need sort + parity, right. This is the best and easiest way to compute that. At least I have no better idea to come up with. For the moment, I'll factor out the new code into an own package. This way VectorAlgebra can depend on it but it need not to be part of Fricas and we could review this point later. For VectorAlgebra any way to compute sort + parity easily would be enough. (Maybe I should review the proposals on wrapping around SortPackage.) > Concerning merge sort: the default sort is merge > sort, so we already have one implementation. Sure, but not a counting one. > 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. Well, this might be true but I think that Axiom definitely should include generic sorting algorithms. So SortPackage is a valid component in my view. -- 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.
