> 1. I prefer to have fewer "error" in library, it's hard > to handle error in SPAD, and it makes function not "total" > (it doesn't return a value for certain inputs), that's a > bad property.
In general I don't care whether we have non-total function as long as it is clear from the specification what the function does for such special cases like "children empty()". Basically the specification must make clear whether the function itself checks for the special cases or whether the caller is simply not allowed to call the function with such special cases. In the latter case it would (theoretically) be fine if the function crashes the whole system. Now the question is whether it's a good idea for FriCAS to include such undefined behaviour (instead of a defined call of "error"). What I find definitely bad is to give the burden of checking to both the function and the caller, by letting the specification be unclear about special cases. http://fricas.github.io/api/GcdDomain.html#l-gcd-domain-gcd gcd(x, y) returns the greatest common divisor of x and y. What will gcd(0,0) return in FriCAS? That it returns 0 is OK with the definition: d=gcd(a,b) if and only if for all c: c|a and c|b ⟹ c|d. where x|y stands for "there exists an integer k such that k*x=y". I guess most people expect gcd(0,0) to be undefined. See also https://math.stackexchange.com/questions/495119/what-is-gcd0-0 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.
