>
> All this discussion of divide by zero made me think of another similar
> case: 'subtractIfCan' in NonNegativeInteger. If might be surprising
> how often this is used in the Axiom code. In OpenAxiom Gaby has raised
> this sort of construction
>
> Union("failed",X)
>
> to the level of special support for the domain constructor
>
> Maybe(X)
>
> in the Spad language. I think this is a good thing! :) In a sense this
> allows the function
>
> f : A -> Maybe(B)
>
> to be "partial" but it goes much deeper than that.
>
> It occurs to me to ask the more "algebraic" question of: "What if we
> did the same thing to subtraction in NonNegativeIntegers as was
> proposed here for division?" I.e. Just make it equal to 0. How much
> algebra would that break?
Just to make thing clear: I do not see _logical_ problem with
defining 1/0 to be 0. I did not propose changes to existing domains,
and in fact I think that such change would be undesirable.
Namely, current behaviour catches errors reasonably early.
After change unitended division by 0 would be hard to detect.
If someone needs 1/0 to be 0, then _new_ user defined domain
can do this (and I posted code implementing this behaviour).
I consider the fact that such constructor is relatively easy
to write and should work reasonably well together with
rest of algebra as strength of original Axiom design.
OTOH I do not encourage usage of such code: there are
strong pragmatic reasons which make 1/0 being error
preferable to getting 0. However, pragmatic reasons
are related to user needs and specific needs may
change preffered result of 1/0.
> Currently we have
>
> (1) -> (1-2)$NNI
>
> The function - is not implemented in NonNegativeInteger .
>
> but that is rather inconvenient sometimes and results in non-compact
> coding styles such as
>
> (r:=substractIfCan(x,y)) case "failed" => z:=0; z:=r
>
> or worse! Of course the point is that often you migth want to do
> something else as a result of the boundary condition other than just
> setting the result to zero.
>
> In the interpreter we can write:
>
> (1) -> subtractIfCan(2,1)$NNI + 1
>
> (1) 2
> Type: PositiveInteger
>
> But there is some magic going on here.
The only magic is automatic coercion from union to integer:
(1) -> subtractIfCan(2,1)$NNI
(1) 1
Type: Union(NonNegativeInteger,...)
(2) -> subtractIfCan(1,2)$NNI
(2) "failed"
Type: Union("failed",...)
> If we try to do this in the
> compiler things are more difficult. One might argue: just as they
> should be! :)
>
> One potentially really good thing about the Maybe domain constructor
> in OpenAxiom is to try to have it both ways: for the most part we can
> operate on the domain Maybe(X) in almost the same way as the original
> domain X, i.e. have the special support for 'Maybe' try to make this
> (mostly) invisible.
>
> Anyway, what do you think of the proposal to implement '-' in
> NonNegativeInteger such that
>
> (1-2)$NNI
>
> would return 0? Does this mean then that NonNegativeInteger could be
> considered an AbelianGroup?
>
This variant is known as "saturating" operation. Since it is not
the inverse of addition you do not get a group. I think that
pragmatic reasons (error checking) go strongly against having
such '-' in NonNegativeInteger. Note that:
(3) -> 1$NNI - 2$NNI
(3) - 1
Type: Integer
works, that is you can use '-' for NonNegativeInteger, but
the result is of type Integer. If there is enough
need we could add saturationg subtraction to to NonNegativeInteger,
but under different name (but I think that it is used rarely and
when needed we can use equivalent code using 'max' and '::')
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
