>My point was that information on branch cuts should either A) be >publicly available or B) preferably available as an export option. >Mathematica and Maple both do A. Perhaps B is the better answer for >open systems. In any event I stand by my point that this is only an >issue because people have a tendency to ignore branch cuts; it is not >actually a flaw inherent in aggregating many systems, and there are no >technical reasons it couldn't be handled better.
Consider what you propose as mechanisms for "handled better". Systems are unlikely to allow you to dynamically change the chosen branch cuts ((B) above) since the assumption is "built in" to code, such as the integration routines and the simplification routines. Neither the authors of "System A" nor the authors of "System B" would consider a bug report valid since they are both internally consistent (one hopes), and thus not in error. But the subtle mistake made by the user (under an incorrect assumption) is very hard to track down. If Sage allows composing calls from System A with calls from System B, this is sure to be an issue. The OpenMath <http://www.openmath.org> project has been working on these kinds of standards. One hope is for the end user of the system to be able to look up such information when needed. For most systems I have no idea where to look for this. This requires good documentation but I'd be the last to suggest this :-) Another hope is to use a set of external test cases (the Computer Algebra Test Suite (CATS) idea) that consists of well chosen problem sets; in this case, problem sets that reveal the branch cuts. Each system would show that they got "the canonical answer" (e.g. that they agree with Schaum's Mathematical Handbook). In that way we could be sure that the systems were "plug replaceable" at the user level. Thus, a Mathematica or Maple user could be sure that Sage gave the same results for trigonometric branch cuts. (To practice what I preach I've been checking Axiom against published results from many different sources. See the mailing list and src/input files.) I feel that both the documentation and CATS approaches are both important and necessary. Clearly these fall into (A) above. Tim --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
