Martin Rubey wrote:
> Ralf Hemmecke <[email protected]> writes:
>
> > This comment in catdef.spad says it all...
> >
> > -- Q-algebra is a lie, should be conditional on characteristic 0,
> > -- but knownInfo cannot handle the following commented
> > -- if % has CharacteristicZero then Algebra Fraction Integer
> >
> > Would have been a surprise to me if the original programmers wouldn't
> > have known. So the problem is the compiler? But somehow, I wouldn't
> > want to have the above if-statement in the category, because it's a
> > kind of "I am also of type X if I am of type Y". But type Y can live
> > far far away and becomes only apparent in an actual implementation of
> > a concrete domain.
> >
> > 1) Better would be to declare Algebra(Fraction Integer) at the time
> > of implementation of the domain.
> > 2) Or have additional categories DivisionRingCharacteristicZero and
> > DivisionRingCharacteristicNonZero.
> >
> > I'd prefer (1).
>
> I think you are right. I just remember a similar "problem" I had some
> time ago, described in the thread:
>
> exports of INTDOM, Ring, was: Nested functions in algebra
>
> Quoting:
>
> > Originally, I also wanted to have Ring export Algebra Integer.
> > However this is not possible, since it introduces a circular
> > dependency on the category level: Algebra exports Ring. However, as
> > (if I recall correctly) Ralf pointed out, we could/should simply
> > replace every occurrence where a domain or category exports "Ring" by
> > "Algebra Integer", and this would cure the problem without tricks. Of
> > course, it would make Ring almost synonymous with Algebra Integer, but
> > on the other hand, it is.
>
> (I'm not sure anymore whether I really want to get rid of Ring.)
>
IIRC tried to make 'Ring' into 'Algebra(Integer)' and it worked. I
probably have a patch somewhere (between hundreds of other patches),
but I did not work more on this as it looked as problem of little
practcal importance. Similarely, if we really want to make
sure that PrimeField does not export 'Algebra(Fraction(Integer))'
I am pretty sure we can work out problems with compiler.
But the problem is deeper: do we really want to insist that every
finction is total (and use someting like Union(X, "failed") to
turn partial functions into total ones)? If not where to draw
the line? I personally am convinced that functions should
always return correct results (that is returning garbage is
not acceptable). But raising errors causes no fundamental
problem. So for me there is question of possible user
confusion (if user sees error only at runtime) and question
of coding effort.
--
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.
