On 03/01/2017 02:50 PM, Waldek Hebisch wrote: > Ralf Hemmecke wrote: >> >> I don't like this. If you specify that p and q have to be non-zero, >> then checking in code is just a safety check that supports either >> users that do not want to read the specification or you want to add >> a security meassure for cases when sylvesterMatrix is used as a >> sub-routine and is called with zero arguments. That's, of course a >> bug, but not a bug in sylvesterMatrix, but in the calling program. > > I am surprised by your critique.
Interesting. ;-) > Bugs happen Unfortunately, we live in an imperfect world. > and normal policy is to have checks like this. We may skip checks > if restrictions are due to called operations and called operations > check their arguments. Well, exactly here lies an overhead. Who is going to check? If the specification says, that an argument must be nonzero, then the caller has to check, if in this case also the program checks for 0, then that's an unnecessary double check that could have been prevented by reading the specification properly while implementing the function. In each case the program has to abort, since the definition for the zero case is not there from the theory. Without check the program might abort later and it's usually quite hard to localise the place where something starts to go wrong. I am for implementing a given specification and not what the programmer thinks that the specification is. If the specification says that zero input is not allowed, why should the implementer check for a case that never happens? Yes, we live in an imperfect world, but I'd rather like to have two programs, one without the unnecessary checks and (by compiler option) one with checks. That is why I would favour something like Aldor's assert statements instead of hardcoding (double) checks. > Well, I find 'p = 0' clearer and more readable than 'zero?(p)'. Oh, I actually agree with that and unfortunately, I don't have an example where zero?(p) would be dramatically more efficient than p=0. > So there are reasons to have 'zero?' and 'one?' but naturaly their > use should be limited. Concerning efficiency, using 'not(a = b)' > frequently gives speed gain compared to 'a ~= b'. That surprises me. If there is a domain that has this property then why not rewriting its implemention of ~= to a~=b == not(a=b) ? This could at most be one additional (indirect) function call (which might even be inlined away). Do you have an example, where this "problem" occurs? 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.
