> To be more specific: choice of implementation of
> 'gcdPolynomial' depends on properties of base
> ring, so it makes sense that 'gcdPolynomial'
> is exported from base ring and not from polynomial
> rings. Thanks to this we can use domian inheritance
> to choose implementation.
I'm fine with cu
oldk1331 wrote:
>
> What do you think of moving gcdPolynomial into UPOLYC?
Well, there are issues of performance and correctness.
Current code is written in such way that computations
propagate from more complicated domains to simpler
ones. And it tries to choose most efficient
available impleme
What do you think of moving gcdPolynomial into UPOLYC?
--
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 fricas-devel+unsubscr...@googlegroups.
oldk1331 wrote:
>
> ")dis op gcdPolynomial" returns (SUP D, SUP D) -> SUP D
> for D has GCDDOM and D has PFECAT, but
> "PFECAT has GCDDOM", so the signature is duplicated.
>
> In catdef.spad, no need to export gcdPolynomial for PFECAT
> again.
Well, currently PFECAT implies UniqueFactorizationDo
")dis op gcdPolynomial" returns (SUP D, SUP D) -> SUP D
for D has GCDDOM and D has PFECAT, but
"PFECAT has GCDDOM", so the signature is duplicated.
In catdef.spad, no need to export gcdPolynomial for PFECAT
again.
diff --git a/src/algebra/catdef.spad b/src/algebra/catdef.spad
index 0358e04..ffa2b
