On 03/01/2017 10:39 AM, oldk1331 wrote:
> I think the "correct" way to do this is to write sylvesterMatrix's
> signature to sylvesterMatrix:(UP, UP)-> Maybe M (or Union("failed",
> M)).

Why a Maybe? Only because FriCAS can somehow handle that? But it would
still be an overhead. The Maybe(M) must somehow tag the failing case. So
there is a (non-zero-cost) runtime conversion from Maybe M to M.

Let me explain with the simpler division. More correct would be
something like

  /: (Integer, NonZeroInteger) -> Fraction(Integer)

with a domain NonZeroInteger that contains all elements from Integer
except 0.

Now the programmer must make sure to call / with the correct type, i.e.,
even without reading the specification, one cannot write code that comes
with a 0 argument.

Of course that would lead to an explosion of domains and is probably not
feasable currently in FriCAS, but now suppose we had a way to say
something like

  /: (Integer, Integer minus Zero) -> Fraction Integer

where the "minus Zero" is my fancy ad hoc way to tell the compiler that
there is no 0 in the second argument. Then the compiler would have a
chance to either generate code that checks the arguments or to just
generate efficient code that relys on the second argument being nonzero.

Similar to adding (as in Aldor's case) some assert statment

https://github.com/pippijn/aldor/blob/master/aldor/lib/algebra/src/basic/sit_complex.as#L106

                quotient(a:%, b:%):% == {
                        import from Boolean;
                        assert(~zero? b);
                        zero? a or one? b => a;
                        r := real a * real b + imag a * imag b;
                        i := imag a * real b - real a * imag b;
                        assert(zero? imag norm b);
                        one?(d := real norm b) => complex(r, i);
                        complex(quotient(r, d), quotient(i, d));
                }

but assert is a runtime check. I would rather like something that (as
with NonZeroInteger) prevents failing code by forcing correct input
types (but of course something a lighter version than creating a new
domain for every small condition).

> That way, people without reading documentation

I'm not a big fan of people who don't read specifications. But I must
admit specifications should be as "natural" as possible so that reading
them is only necessary to make sure what happens in the few exceptional
cases.

> Yes, "zero?" should be better, but I don't know why: there are lots
> of code containing "one?(x)" got replaced by "x=1", and there are
> still usage of "one?".

History. IIRC, this change was introduced by Tim Daly before FriCAS
forked. Example...

https://github.com/fricas/fricas/blob/master/src/algebra/intfact.spad#L273

    approxNthRoot(a, n) ==   -- complexity (log log n) (log n)^2
      zero? n => error "invalid arguments"
--      one? n => a
      (n = 1) => a
      n = 2 => approxSqrt a
      negative? a =>
        odd? n => - approxNthRoot(-a, n)
        0
      zero? a => 0
--      one? a => 1
      (a = 1) => 1
      ...

I'd actually like to revert this patch.

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.

Reply via email to