Recent commit "Fix 'row' and 'column'" niecely illustrates
why 'it passes tests' in not enough and why 'no domain uses it'
is invalid when checking correctness. 'row' used:
v : Row := new(ncols m,NIL$Lisp)
and 'column' had similar code. It probably worked for all domains
existing when the code was written (sometimes in eighties).
However, it assumed that Lisp NIL is valid value to store in
array. With introduction of specialized arrays and vectors
like DoubleFloatVector this is no longer the case and the code
failed.
Code like above is a latent bug. Such things are sometimes
done to get the code "working" and win time for other issues.
Such practice is called technical debt and like real debt
may be serious trouble. Namely accumulated technical debt
means there are bugs and may encourage various workarounds
which create even more technical debt. The process may
easily get out of control and the project may collapse
because nobody is willing (or able) to clean up resulting
mess.
Our code is now much cleaner than original Axiom code. But
we still have a lot of bogus things and without enough
diligence code could easily deteriarate. That is why
we need to be strict about new code (and changes to old).
One big source of bogosity is '$Lisp' calls. Some are
valid because the call is access to a primitive operation
otherwise unavailable in Spad. Some are valid because
assumptions they make are are always satisified (like
Lisp EQ implaing equality). But there are buch of
bogus things. One is recently mentioned 'Factored'
issue: we can not assume that Lisp ordering predicate
will do something sensible (which essentially means
that the code should _not_ depend on order and
use quadratic algorithm). I also noticed uses of
'mathObject2String$Lisp'. This is fine for specific
things like strings, symbols or lists of them. But
it is invalid when applied to general FriCAS data.
In particular 'toString' in 'src/algebra/clifford.spad'
needs to be fixed (removed ???).
There is another source of bogosity, it seems that many
uses of EuclideanDomain (and related) are wrong. In
particular AFAICS there is no way to define euclidean
valuation on Complex. The current code works for
Integer and univariate polynomials over a field but
not in more general cases.
--
Waldek Hebisch
--
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.
