oldk1331 wrote:
>
> (1) -> f x == x::FR POLY INT
> Type: Void
> (2) -> factorList f(x^2-1)
> Compiling function f with type Polynomial(Integer) -> Factored(
> Polynomial(Integer))
>
> 2
> (2) [[flg = "sqfr",fctr = x - 1,xpnt = 1]]
> Type: List(Record(flg: Union("nil","sqfr","irred","prime"),fctr:
> Polynomial(Integer),xpnt: Integer))
> (3) -> factorList ((x^2-1)::FR POLY INT)
>
> (3)
> [[flg = "prime",fctr = x - 1,xpnt = 1],[flg = "prime",fctr = x + 1,xpnt =
> 1]]
> Type: List(Record(flg: Union("nil","sqfr","irred","prime"),fctr:
> Polynomial(Integer),xpnt: Integer))
>
>
> Simply wrap this type conversion into a function causes
> different result, I think this is a bug.
>
> In "f x == x::FR POLY INT", f seems to call 'coerce:R->%'
> from FR POLY INT. Is the conversion in interpreter a special
> treatment?
Yes. See 'i-coerce.boot'. There is rather involved code
responsible for interpreter coercions. Interpreter has
two modes of operation: one to generate a value (nomal
for command line) and another to generate code.
Corecion code takes advantage of value (if known) and
in such case can do more.
Given that command line version is doing more than
compiled version differences are unavidable. I am
not sure if view such design decision as a bug or not:
coercions are very important for command line use
and interpreter code is "tuned" (read: there are various
special cases) to give resonable results in common
cases. For use from compiled code speed and
consistency are more important, so coercions called
from code are much less agressive than command
line coercions.
Concerning special case of coercion to factored:
arguably coresion should produce "nil" factor
(that is the simples possible coercion) and
factoring should be explicit. But apparently
somebody felt that on command line factoring
during coercion is nicer. And somewhat libary
author felt need to factor:
if R has IntegerNumberSystem
then
coerce(r : R) : % ==
factor(r)$IntegerFactorizationPackage(R) pretend %
else
if R has UniqueFactorizationDomain
then
coerce(r : R) : % ==
zero? r => 0
unit? r => mkFF(r, empty())
R has Field => error "zero divisor in a field"
unitNormalize(squareFree(r) pretend %)
else
coerce(r : R) : % ==
-- one? r => 1
(r = 1) => 1
unitNormalize mkFF(1, [["nil", r, 1]$FF])
I must admit that this looks strange. For integers one can
argue that squarefree factorization is essentially as expensive
as full factorization, so using 'factor' gives more information
at the same cost. OTOH polynomial factorization works well
for polynomials of rather high degree, while integer factorization
is hopeless for large integers.
--
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.
