DirectProduct?
Ralf Hemmecke
I would have accepted, if it fails. (Actually it shouldn't since
coercing to Fraction(...) should have been easy. But I agree, it's
inside the argument of a type (SquareMatrix), so a bit tricky.)
Anyway, the interpreter seems to use
*: (DirectProduct(2, R), %) -> DirectProduct(2,R)
So it converts
(101) -> ((20 + 97*%i)*x + 4*%i)::
DirectProduct(2,Fraction(Polynomial(Complex(Integer))))
(101) [(20 + 97%i)x + 4%i,(20 + 97%i)x + 4%i]
Why does the interpreter consider that to be easier than converting my
element just to Fraction(Polynomial(Complex(Integer))) and do the right
thing?
Strange...
Ralf
(98) -> p::SquareMatrix(2, Fraction Polynomial(Complex Integer))
+(5 + 12%i)x + %i (- 21 - 14%i)x+
(98) | |
+ (- 21 - 14%i)x 49x + 4 +
Type:
SquareMatrix(2,Fraction(Polynomial(Complex(Integer))))
(99) -> inverse(%)
+ 49x + 4 (21 + 14%i)x +
|------------------ ------------------|
|(20 + 97%i)x + 4%i (20 + 97%i)x + 4%i|
(99) | |
| (21 + 14%i)x (5 + 12%i)x + %i |
|------------------ ------------------|
+(20 + 97%i)x + 4%i (20 + 97%i)x + 4%i+
Type:
Union(SquareMatrix(2,Fraction(Polynomial(Complex(Integer)))),...)
(97) -> (((20 + 97*%i)*x + 4*%i)::Fraction(Polynomial(Complex Integer)))*%
+ 49x + 4 (21 + 14%i)x +
(97) | |
+(21 + 14%i)x (5 + 12%i)x + %i+
Type:
SquareMatrix(2,Fraction(Polynomial(Complex(Integer))))
(100) -> ((20 + 97*%i)*x + 4*%i) * %
(100) [(70 + 14%i)x + 4,(26 + 26%i)x + %i]
Type:
DirectProduct(2,Fraction(Polynomial(Complex(Integer))))
Bill Page
I think that the map
coerce : Fraction Polynomial Complex Integer -> %
which is apparently x+-> [x,x]
in
)sh DirectProduct(2,Fraction Polynomial Complex Integer)
should not be called a coercion.
I think it would be unusual to want the interpreter to apply this map
automatically that way it apparently does now.
I think it would be worth trying to remove it (or renaming it) and see
what impact it has on the regression tests.
Regards,
Bill Page.
> --
> 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 fricas...@googlegroups.com.
> To unsubscribe from this group, send email to fricas-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
>
>
Gabriel Dos Reis
Sounds familiar:
http://sourceforge.net/mailarchive/message.php?msg_name=877hmdxxmu.fsf%40gauss.cs.tamu.edu
Ralf Hemmecke
> Ralf,
>
> I think that the map
>
> coerce : Fraction Polynomial Complex Integer -> %
>
> which is apparently x+-> [x,x]
>
> in
>
> )sh DirectProduct(2,Fraction Polynomial Complex Integer)
>
> should not be called a coercion.
From DirectProduct ...
if R has Monoid then
1 == new(dim, 1)$Vector(R) pretend %
u : % * r : R == map(x +-> x*r, u)
r : R * u : % == map(x +-> r*x, u)
x:% * y:% == [x.i * y.i for i in 1..dim]$Vector(R) pretend %
That makes sense.
Well... automatic coercion cannot always be right.
Ralf
Bill Page
What does the following have to do with Monoid?
There is such a thing as being too automatic - especially when the
results are unintuitive and of limited utility.
Regards,
Bill Page.
Ralf Hemmecke
> Ralf,
>
> What does the following have to do with Monoid?
>
>
> On Thu, Jun 10, 2010 at 1:06 PM, Ralf Hemmecke <ra...@hemmecke.de> wrote:
>> On 06/10/2010 06:33 PM, Bill Page wrote:
>>> Ralf,
>>>
>>> I think that the map
>>>
>>> coerce : Fraction Polynomial Complex Integer -> %
>>>
>>> which is apparently x+-> [x,x]
>>>
>>> in
>>>
>>> )sh DirectProduct(2,Fraction Polynomial Complex Integer)
>>>
>>> should not be called a coercion.
If R is a Monoid then DirectProduct(2,R) is and the natural 1 in this
monoid is (1,1) since the multiplication is component-wise.
So x -> [x,x] looks like quite a natural lift. No?
As I said, automatic choice of the coercion without giving a hint that
there are also other options is the problem.
I'd rather like my first example to fail with an error message that
there is an ambiguity instead of returning me an unwanted DirectProduct.
If it fails, and gives me the possible sigatures, I know that I have
(for example) to specify the return type more precisely. Without any
hint and just being left with DirectProduct, I guess any user will be
confused.
I consider this a bug in the sense of leaving the user clueless.
Well, you all know my (non-)preference of automatic coercion. ;-)
Ralf
Bill Page
In another thread Gaby observed that for a Field F SquareMatrix(n,F)
should satisfy VectorSpace(F), but unfortunately at present it does
not:
(1) -> SquareMatrix(2,Fraction Integer) has VectorSpace(Fraction Integer)
(1) false
Or perhaps even better if every SquareMatrix(n,R) satisfied Module(R).
If it did, then I think the question of coercion would be moot.
Regards,
Bill Page.
Ralf Hemmecke
> Ralf,
>
> should satisfy VectorSpace(F), but unfortunately at present it does
> not:
>
> (1) -> SquareMatrix(2,Fraction Integer) has VectorSpace(Fraction Integer)
>
> (1) false
It probably could if it somebody adds VectorSpace(R) into
SquareMatrixCategory(ndim,R,Row,Col): Category == Definition where
...
Definition ==>
...
if R has Field then
VectorSpace(R)
...
So why hesitate?
> Or perhaps even better if every SquareMatrix(n,R) satisfied Module(R).
With the definition of
Module(R:CommutativeRing): Category == BiModule(R,R)
add
if not(R is %) then x:%*r:R == r*x
I think, it is quite sufficient when
SquareMatrixCategory(ndim,R,Row,Col): Category == Definition where
Definition ==> Join(DifferentialExtension R, BiModule(R, R),_
...
which is the current definition.
> If it did, then I think the question of coercion would be moot.
But note, my question was about looking for an appropriate operation *
(or rather an appropriate coercion) so that
R and SquareMatrix(2,Fraction R)
can be connected.
As written in
http://groups.google.com/group/fricas-devel/browse_thread/thread/63f43b33d26ecb6d
, Fraction R and SquareMatrix(2, Fraction R) is not a problem.
Ralf
Bill Page
On Thu, Jun 10, 2010 at 6:40 PM, Ralf Hemmecke <ra...@hemmecke.de> wrote:
> ...
> With the definition of
>
> Module(R:CommutativeRing): Category == BiModule(R,R)
> add
> if not(R is %) then x:%*r:R == r*x
>
> I think, it is quite sufficient when
>
> SquareMatrixCategory(ndim,R,Row,Col): Category == Definition where
> Definition ==> Join(DifferentialExtension R, BiModule(R, R),_
> ...
>
> which is the current definition.
>
Ok.
>> If it did, then I think the question of coercion would be moot.
>
> But note, my question was about looking for an appropriate operation *
> (or rather an appropriate coercion) so that
>
> R and SquareMatrix(2,Fraction R)
>
> can be connected.
>
That was not clear to me. And in fact such a coercion does seem to be
applied in the case R = Integer.
> As written in
> http://groups.google.com/group/fricas-devel/browse_thread/thread/63f43b33d26ecb6d
> , Fraction R and SquareMatrix(2, Fraction R) is not a problem.
>
Sorry I did not notice when you originally pointed this out. Now I
see the difference between (97) and (100) but the computation seems
oddly out of order. So I guess I must go back and try to understand
again why the result is a DirectProduct in your example.
Why is there no automatic coercion when R = Polynomial(Complex
Integer))? Is this some limitation of Fraction?
Regards,
Bill Page.
Ralf Hemmecke
>> (or rather an appropriate coercion) so that
>>
>> R and SquareMatrix(2,Fraction R)
>>
>> can be connected.
> Why is there no automatic coercion when R = Polynomial(Complex
> Integer))? Is this some limitation of Fraction?
Oh, that's easy. Then for F = Fraction(R) I ask for a multiplication
*: (F, SquareMatrix(2, F) -> something
And the probably easiest * that can be found, is the one from
BiModule(F, F).
Best regards
Ralf
Bill Page
No. I asked why
*: (R, SquareMatrix(2, F) -> something
is easy when R = Integer. But it is not "easy" when R =
Polynomial(Complex Integer))?
Regards,
Bill Page.
Bill Page
Here is a test example:
(1) -> )sys cat test-coerce1.input
-- test-coerce1.input
)cl co
R:=Integer
F:=Fraction R
M:=SquareMatrix(2,F)
m:M:=[[1,1],[1,1]]
f:F:=1
r:R:=1
f*m
r*m
--
)cl co
R:=Polynomial Integer
F:=Fraction R
M:=SquareMatrix(2,F)
m:M:=[[1,1],[1,1]]
f:F:=1
r:R:=1
f*m
r*m
--
(1) -> )r test-coerce1.input
-- test-coerce1.input
)cl co
All user variables and function definitions have been cleared.
All )browse facility databases have been cleared.
Internally cached functions and constructors have been cleared.
)clear completely is finished.
R:=Integer
(1) Integer
Type: Type
F:=Fraction R
(2) Fraction Integer
Type: Type
M:=SquareMatrix(2,F)
(3) SquareMatrix(2,Fraction Integer)
Type: Type
m:M:=[[1,1],[1,1]]
+1 1+
(4) | |
+1 1+
Type: SquareMatrix(2,Fraction Integer)
f:F:=1
(5) 1
Type: Fraction Integer
r:R:=1
(6) 1
Type: Integer
f*m
+1 1+
(7) | |
+1 1+
Type: SquareMatrix(2,Fraction Integer)
r*m
+1 1+
(8) | |
+1 1+
Type: SquareMatrix(2,Fraction Integer)
--
)cl co
All user variables and function definitions have been cleared.
All )browse facility databases have been cleared.
Internally cached functions and constructors have been cleared.
)clear completely is finished.
R:=Polynomial Integer
(1) Polynomial Integer
Type: Type
F:=Fraction R
(2) Fraction Polynomial Integer
Type: Type
M:=SquareMatrix(2,F)
(3) SquareMatrix(2,Fraction Polynomial Integer)
Type: Type
m:M:=[[1,1],[1,1]]
+1 1+
(4) | |
+1 1+
Type: SquareMatrix(2,Fraction Polynomial Integer)
f:F:=1
(5) 1
Type: Fraction Polynomial Integer
r:R:=1
(6) 1
Type: Polynomial Integer
f*m
+1 1+
(7) | |
+1 1+
Type: SquareMatrix(2,Fraction Polynomial Integer)
r*m
(8) [2,2]
Type: DirectProduct(2,Fraction Polynomial Integer)
(9) ->
----
Why is this 2nd result for (8) not of the same form as the first
result for (8)? The only difference is
R:=Polynomial Integer
instead of
R:=Integer
Regards,
Bill Page.
Ralf Hemmecke
> Ralf,
>
> No. I asked why
>
> *: (R, SquareMatrix(2, F) -> something
>
> is easy when R = Integer. But it is not "easy" when R =
> Polynomial(Complex Integer))?
Oh, your example reveals quite confusing behaviour. :-(
It seems that the interpreter treats Integer in a very special way. But
you know probably better than me how the interpreter decides.
I'm actually not interested currently in anything that guesses types for
me. A good coercion strategy might be fine, but if there is a choice
then the user should be informed and *the user* should have the last word.
Currently, the user is left in a state that doesn't help him much to
find out why the result is different than expected and how he could get
a better answer.
Ralf
Waldek Hebisch
> Ralf,
>
> I think that the map
>
> coerce : Fraction Polynomial Complex Integer -> %
>
> which is apparently x+-> [x,x]
>
> in
>
> )sh DirectProduct(2,Fraction Polynomial Complex Integer)
>
> should not be called a coercion.
Good spot. AFAICS that coercion is defined because we have
if R has SetCategory then FullyRetractableTo R
in DirectProductCategory. IMHO this does not make sense.
But before removing it one have to fix a few places in algebra
(at least retract in SquareMatrix) where the retraction from direct
product to scalars is used.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
Waldek,
what exactly is the problem?
coerce: R -> %
or
retract % -> R
for % being DirectProduct(ndim, R)?
Bill and me discussed the coercion. If you check hyperdoc for
DirectProduct and click on "origin" for the function "coerce", then you
see that coerce: R -> % comes from Algebra(R). It just needs that R is a
CommutativeRing. Thus, removing FullyRetractableTo R will probably have
no effect on my original problem.
As for 'retract'. I think that this is not realy dangerous. It is
implemented as
if R has SetCategory then
same?: % -> Boolean
same? z == every?(x +-> x = z(minIndex z), z)
retract(z:%):R ==
same? z => z(minIndex z)
error "Not retractable"
So why do you think that it doesn't make sense?
I would have thought that one would naturally perhaps rather ask
if R has CommutativeRing then ...
in order to be in some sense the inverse for the coerce function, but I
cannot currently see that "R has SetCategory" is much of a problem.
Ralf
Bill Page
Although as I said, I do not like to call the map x+->[x,x] a
"coercion" (and it's associated "retraction") I have problems
justifying denying it formally. It seems to satisfy all the
requirements as I understand them. (We've discussed the requirements
previously and there are some relevant pages on the Axiom wiki.) I
think that
if R has SetCategory then FullyRetractableTo R
is true under our normal understanding of these terms and
FullyRetractableTo(R) exports coerce:R->%. Also as Ralf points out
there are other reasons why this coercion appears when R has even more
structure (such as a Ring). I think it would be difficult to avoid
this.
Perhaps there should be something else to obstruct the formation of
this unexpected product.
Gaby commented in the OpenAxiom thread on this subject that he thought
the problem might be overloading of *. Does it make sense to use the
symbol * to denote mulitiplication of a Matrix by a row vector
(DirectProduct)?
Regards,
Bill Page.
Martin Rubey
Personally, I currently think (as Bill pointed out) that
?*? : (DirectProduct(ndim,R),%) -> DirectProduct(ndim,R)
?*? : (%,DirectProduct(ndim,R)) -> DirectProduct(ndim,R)
are "wrong". Or, rather: once we think of DIRPROD as a vector, once as
a diagonal matrix. Right?
Martin
(1) -> m:SQMATRIX(2, POLY INT) := squareMatrix matrix [[a, b], [c, d]]
+a b+
(1) | |
+c d+
Type: SquareMatrix(2,Polynomial(Integer))
(2) -> im := inverse m
+ d b +
| --------- - ---------|
| a d - b c a d - b c|
(2) | |
| c a |
|- --------- --------- |
+ a d - b c a d - b c +
Type: Union(SquareMatrix(2,Fraction(Polynomial(Integer))),...)
(3) -> (r::FRAC POLY INT)*inverse m
+ d r b r +
| --------- - ---------|
| a d - b c a d - b c|
(3) | |
| c r a r |
|- --------- --------- |
+ a d - b c a d - b c +
Type: SquareMatrix(2,Fraction(Polynomial(Integer)))
(4) -> (r::POLY INT)*inverse m
(d - c)r (- b + a)r
(4) [---------,----------]
a d - b c a d - b c
Type: DirectProduct(2,Fraction(Polynomial(Integer)))
(5) -> )tr SQMATRIX )ma
Packages traced:
SquareMatrix(2,Fraction(Polynomial(Integer))), SquareMatrix
(2,Polynomial(Integer))
Parameterized constructors traced:
SQMATRIX
(5) -> )tr DIRPROD )ma
Packages traced:
SquareMatrix(2,Fraction(Polynomial(Integer))), SquareMatrix
(2,Polynomial(Integer)), DirectProduct(2,Fraction(
Polynomial(Integer))), DirectProduct(2,Polynomial(
Integer))
Parameterized constructors traced:
SQMATRIX, DIRPROD
(5) -> r*inverse m
1<enter SquareMatrix.inverse,67
:
+a b+
arg1= | |
+c d+
1>exit SquareMatrix.inverse,67
:
+ d b +
| --------- - ---------|
| a d - b c a d - b c|
| |
| c a |
|- --------- --------- |
+ a d - b c a d - b c +
1<enter DirectProduct.coerce,11
:
arg1= r
1>exit DirectProduct.coerce,11
:
[r,r]
1<enter SquareMatrix.*,46
:
arg1= [r,r]
+ d b +
| --------- - ---------|
| a d - b c a d - b c|
arg2= | |
| c a |
|- --------- --------- |
+ a d - b c a d - b c +
1<enter DirectProduct.coerce,10
:
arg1= [r,r]
1>exit DirectProduct.coerce,10
:
[r,r]
1<enter DirectProduct.directProduct,17
:
(d - c)r (- b + a)r
arg1= [---------,----------]
a d - b c a d - b c
1<enter DirectProduct.size?,16
:
(d - c)r (- b + a)r
arg1= [---------,----------]
a d - b c a d - b c
arg2= 2
1>exit DirectProduct.size?,16
:
true
1>exit DirectProduct.directProduct,17
:
(d - c)r (- b + a)r
[---------,----------]
a d - b c a d - b c
1>exit SquareMatrix.*,46
:
(d - c)r (- b + a)r
[---------,----------]
a d - b c a d - b c
1<enter DirectProduct.parts,13
:
(d - c)r (- b + a)r
arg1= [---------,----------]
a d - b c a d - b c
1>exit DirectProduct.parts,13
:
(d - c)r (- b + a)r
[---------,----------]
a d - b c a d - b c
(d - c)r (- b + a)r
(5) [---------,----------]
a d - b c a d - b c
Type: DirectProduct(2,Fraction(Polynomial(Integer)))
Ralf Hemmecke
> the problem might be overloading of *. Does it make sense to use the
> symbol * to denote mulitiplication of a Matrix by a row vector
> (DirectProduct)?
Why should that be a problem? The only problem I can see is that for
multiplication left or right, the vector is considered as row or column
vector. So being co- or contravariant changes.
(1) -> v := vector [2,3]
(1) [2,3]
Type: Vector(PositiveInteger)
(2) -> m:= matrix [[3,4],[0,1]]
+3 4+
(2) | |
+0 1+
Type: Matrix(Integer)
(3) -> v*m
(3) [6,11]
Type: Vector(Integer)
(4) -> m*v
(4) [18,3]
Type: Vector(Integer)
And if you look at MatrixCategory, then you see (R, Row, Col) as
arguments. So, the authors actually thought about the co-/contravariance
and defined
"*": (%,Col) -> Col
++ \spad{x * c} is the product of the matrix x and the column
vector c.
++ Error: if the dimensions are incompatible.
"*": (Row,%) -> Row
++ \spad{r * x} is the product of the row vector r and the matrix x.
That makes perfect sense to me.
The problem is the interpreter not the library.
Ralf
Ralf Hemmecke
Execute
n: Integer := 2
P ==> Polynomial Integer
F ==> Fraction P
S ==> SquareMatrix(2, F)
p: P := n::P
m: S := squareMatrix matrix [[1,1/p],[1/p,1]]
z := (p::F)*m
p*m
in the interpreter and then try to compile
---rhxBEGIN dptest.spad
)abbrev domain DPTEST DPTest
DPTest(): with
mytest: Integer -> Integer
== add
mytest(n: Integer): Integer ==
P ==> Polynomial Integer
F ==> Fraction P
S ==> SquareMatrix(2, F)
p: P := n::P
m: S := squareMatrix matrix [[1,1/p],[1/p,1]]
z := (p::F)*m
--p*m
n
---rhxEND dptest.spad
and also try to remove the -- in front of p*m and compile again.
I would be more happy if the interpreter tells me similarly that there
is a problem instead of simply coercing to something I don't expect.
I know, it's only me... :-)
Ralf
Martin Rubey
> So, let's make even clearer that the problem is the interpreter.
OK, I "forgot" that the compiler is sufficiently strict. Makes me
happy, actually.
> I know, it's only me... :-)
Certainly not! Maybe you remember that some time ago I asked for help
writing a testsuite testing coercions.
Martin
Gabriel Dos Reis
| Waldek, Ralf,
|
| Although as I said, I do not like to call the map x+->[x,x] a
| "coercion" (and it's associated "retraction") I have problems
| justifying denying it formally. It seems to satisfy all the
| requirements as I understand them. (We've discussed the requirements
| previously and there are some relevant pages on the Axiom wiki.) I
| think that
|
| if R has SetCategory then FullyRetractableTo R
|
| is true under our normal understanding of these terms and
| FullyRetractableTo(R) exports coerce:R->%. Also as Ralf points out
| there are other reasons why this coercion appears when R has even more
| structure (such as a Ring). I think it would be difficult to avoid
| this.
|
| Perhaps there should be something else to obstruct the formation of
| this unexpected product.
|
| Gaby commented in the OpenAxiom thread on this subject that he thought
| the problem might be overloading of *.
No, that is not what I said.
What I said for THIS SPECIFIC problem is that the implicit coerciion
problem comes from
if R has SetCategory then FullyRetractableTo R
See the message I sent on June 05, 2010.
http://sourceforge.net/mailarchive/message.php?msg_name=877hmdxxmu.fsf%40gauss.cs.tamu.edu
which I'm quoting:
# I offered the data with no much analysis.
# Here it is. The multiplication
#
# %i*A
#
# isn't exactly the multiplication of a scalar by a 'vector' as from
# vector space, since A has entries from EXPR COMPLEX INT, whereas %i
# is COMPLEX INT. So, there is no direct match for '*'. Next, the
# interpreter tries to find one by doing some coercions. Among the
# available signatures, it finds out that it can left-multiply the square
# matrix A by a 'row' vector if it can coerce %i to that row-vector.
# Which it did because there a coerce function from a 'scalar' to a
# raw-vector (which I find misguided). This goes back to a comment I made
# a couple of days ago: strange things can happen when operations are
# overloaded just because one can, without much consideration for the
# semantics.
| Does it make sense to use the
| symbol * to denote mulitiplication of a Matrix by a row vector
| (DirectProduct)?
That was not my proposal.
-- Gaby
Gabriel Dos Reis
| > Gaby commented in the OpenAxiom thread on this subject that he thought
| > the problem might be overloading of *. Does it make sense to use the
| > symbol * to denote mulitiplication of a Matrix by a row vector
| > (DirectProduct)?
|
| Why should that be a problem?
It isn't THE source of the problem.
[...]
| The problem is the interpreter not the library.
From the message sent on June 05, 2010
http://sourceforge.net/mailarchive/message.php?msg_name=877hmdxxmu.fsf%40gauss.cs.tamu.edu
# Yes: why the interpreter should also have tried the second signature to
# find out that it can work, therefore at least report an ambiguity.
Gabriel Dos Reis
| I took a free minute to convert Ralf's example to something simpler.
|
| Personally, I currently think (as Bill pointed out) that
|
| ?*? : (DirectProduct(ndim,R),%) -> DirectProduct(ndim,R)
| ?*? : (%,DirectProduct(ndim,R)) -> DirectProduct(ndim,R)
|
| are "wrong".
One could argue that they are indeed wrong -- e can have that discussion
later. But, for the specific problem at hand, they are NOT the root
cause. The root cause is implicitly turning a scalar into a vector.
Bill Page
>
> What I said for THIS SPECIFIC problem is that the implicit coerciion
> problem comes from
>
> if R has SetCategory then FullyRetractableTo R
>
Bot note that the specific coercion also comes from Algebra? Do you
also want to deny that DirectProduct(n,R) satisfies Algebra(R)?
> See the message I sent on June 05, 2010.
>
> http://sourceforge.net/mailarchive/message.php?msg_name=877hmdxxmu.fsf%40gauss.cs.tamu.edu
>
> which I'm quoting:
> ...
> # ... This goes back to a comment I made
> # a couple of days ago: strange things can happen when operations are
> # overloaded just because one can, without much consideration for the
> # semantics.
>
Thanks Gaby.
> Bill Page wrote:
> | Does it make sense to use the
> | symbol * to denote mulitiplication of a Matrix by a row vector
> | (DirectProduct)?
>
> That was not my proposal.
>
No, that is how it works now. The question is: should it?
Regards,
Bill Page.
Gabriel Dos Reis
| On Sun, Jun 13, 2010 at 9:25 AM, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| >
| > What I said for THIS SPECIFIC problem is that the implicit coerciion
| > problem comes from
| >
| > if R has SetCategory then FullyRetractableTo R
| >
|
| Bot note that the specific coercion also comes from Algebra?
Why do you thin it comes from Algebra instead of FullyRetractableTo R?
| Do you also want to deny that DirectProduct(n,R) satisfies Algebra(R)?
'also want to deny'? I am having trouble understanding your question.
|
| > See the message I sent on June 05, 2010.
| >
| > http://sourceforge.net/mailarchive/message.php?msg_name=877hmdxxmu.fsf%40gauss.cs.tamu.edu
| >
| > which I'm quoting:
| > ...
| > # ... This goes back to a comment I made
| > # a couple of days ago: strange things can happen when operations are
| > # overloaded just because one can, without much consideration for the
| > # semantics.
| >
|
| Thanks Gaby.
And in this specific case, I was talking about the overload
coerce: R -> %
which tunrs a scalar into a vector.
|
| > Bill Page wrote:
| > | Does it make sense to use the
| > | symbol * to denote mulitiplication of a Matrix by a row vector
| > | (DirectProduct)?
| >
| > That was not my proposal.
| >
|
| No, that is how it works now. The question is: should it?
That isn't the ROOT cause of this specific problem. I think we are
getting side trackted.
Bill Page
> Bill Page <bill...@newsynthesis.org> writes:
>
> | On Sun, Jun 13, 2010 at 9:25 AM, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> | >
> | > What I said for THIS SPECIFIC problem is that the implicit coerciion
> | > problem comes from
> | >
> | > if R has SetCategory then FullyRetractableTo R
> | >
> |
> | Bot note that the specific coercion also comes from Algebra?
>
> Why do you thin it comes from Algebra instead of FullyRetractableTo R?
>
The signature for this function comes from multiple sources. In the
case which is the subject of this thread R is a CommutativeRing.
In src/algeba/vector.spad.pamphlet:
DirectProductCategory(dim:NonNegativeInteger, R:Type): Category ==
Join(IndexedAggregate(Integer, R), CoercibleTo Vector R, _
finiteAggregate) with
...
if R has CommutativeRing then
Algebra R
---
In src/algebra/catdef.spad.pamphlet
...
Algebra(R:CommutativeRing): Category ==
Join(Ring, Module R) with
--operations
coerce: R -> %
++ coerce(r) maps the ring element r to a member of the algebra.
add
coerce(x:R):% == x * 1$%
...
> | Do you also want to deny that DirectProduct(n,R) satisfies Algebra(R)?
>
> 'also want to deny'? I am having trouble understanding your question.
Do you want to remove the above code from DirectProductCategory?
> ...
> |
> | > Bill Page wrote:
> | > | Does it make sense to use the
> | > | symbol * to denote mulitiplication of a Matrix by a row vector
> | > | (DirectProduct)?
> | >
> | > That was not my proposal.
> | >
> |
> | No, that is how it works now. The question is: should it?
>
> That isn't the ROOT cause of this specific problem. I think we are
> getting side trackted.
>
I am especially interested in the reason for the difference between
the following two computations where the only difference is
R:=Integer
versus
R:=Polynomial Integer
(1) -> )sys cat test-coerce1.input
-- test-coerce1.input
)cl co
R:=Integer
F:=Fraction R
M:=SquareMatrix(2,F)
m:M:=[[1,1],[1,1]]
f:F:=1
r:R:=1
f*m
r*m
--
)cl co
R:=Polynomial Integer
F:=Fraction R
M:=SquareMatrix(2,F)
m:M:=[[1,1],[1,1]]
f:F:=1
r:R:=1
f*m
r*m
--
(1) -> )r test-coerce1.input
(See previous message in this thread.)
Regards,
Bill Page.
Gabriel Dos Reis
The coercion from a scalar to a DirectProduct is implemented as
coerce(r:R):% == per new(dim, r)$Vector(R)
(see vector.spad.pamphlet)
| ...
|
| > | Do you also want to deny that DirectProduct(n,R) satisfies Algebra(R)?
| >
| > 'also want to deny'? I am having trouble understanding your question.
|
| Do you want to remove the above code from DirectProductCategory?
I am concerned with the operations defined by DirectProduct and their
semantics. For the specific case at hand, I don't care about the
default implementation in Algebra since DirectProduct explicitly
overwrites it, saying that the scalar value 1 should be regarded the same
as the vecor [1,1,1,1], for example.
My contention is that many of the operations in DirectProduct have
fishy semantics.
coerce: R -> %
is one of them. Another one (I hope NOT under discussion at this point) is
*: (%,%) -> %
which multiplies the vector componentwise!
Gabriel Dos Reis
[...]
| I am concerned with the operations defined by DirectProduct and their
| semantics. For the specific case at hand, I don't care about the
| default implementation in Algebra since DirectProduct explicitly
| overwrites it, saying that the scalar value 1 should be regarded the same
| as the vecor [1,1,1,1], for example.
|
| My contention is that many of the operations in DirectProduct have
| fishy semantics.
|
| coerce: R -> %
|
| is one of them. Another one (I hope NOT under discussion at this point) is
|
| *: (%,%) -> %
|
| which multiplies the vector componentwise!
By the way, this category membership assertion in DirectProductCategory
if R has CancellationAbelianMonoid then CancellationAbelianMonoid
is clearly wrong with the implementation of multiplication in DirectProduct.
In DirectProduct(2,INT), take
a := [1,0]
b := [0,1]
c := [0,2]
you have a * b = a * c = [0,0], but you clearly don't have b = c
Many operations in DirectProduct just have the wrong semantics.
I will start fixing that in OpenAxiom.
Ralf Hemmecke
>
> if R has CancellationAbelianMonoid then CancellationAbelianMonoid
>
> is clearly wrong with the implementation of multiplication in DirectProduct.
>
> In DirectProduct(2,INT), take
>
> a := [1,0]
> b := [0,1]
> c := [0,2]
>
> you have a * b = a * c = [0,0], but you clearly don't have b = c
)abbrev category CABMON CancellationAbelianMonoid
...
++ Description:
++ This is an \spadtype{AbelianMonoid} with the cancellation property,
++ i.e. \spad{ a+b = a+c => b=c }.
++ This is formalised by the partial subtraction operator,
++ which satisfies the axioms listed below:
++
++ Axioms:
++ \spad{c = a+b <=> c-b = a}
CancellationAbelianMonoid(): Category == AbelianMonoid with
--operations
subtractIfCan: (%,%) -> Union(%,"failed")
++ subtractIfCan(x, y) returns an element z such that \spad{z+y=x}
++ or "failed" if no such element exists.
Gabriel Dos Reis
And the example
> In DirectProduct(2,INT), take
>
> a := [1,0]
> b := [0,1]
> c := [0,2]
>
> you have a * b = a * c = [0,0], but you clearly don't have b = c
from the message you were replying to is evidence that the operations in
DirectProduct do not honor what you were quoting.
Ralf Hemmecke
Of course not. I cannot distinguish between + and *. ;-)
Gabriel Dos Reis
Waldek Hebisch
> On 06/12/2010 01:50 PM, Waldek Hebisch wrote:
> > Bill Page wrote:
> >> Ralf,
> >>
> >> I think that the map
> >>
> >> coerce : Fraction Polynomial Complex Integer -> %
> >>
> >> which is apparently x+-> [x,x]
> >>
> >> in
> >>
> >> )sh DirectProduct(2,Fraction Polynomial Complex Integer)
> >>
> >> should not be called a coercion.
> >
> > Good spot. AFAICS that coercion is defined because we have
> >
> > if R has SetCategory then FullyRetractableTo R
> >
> > in DirectProductCategory. IMHO this does not make sense.
> > But before removing it one have to fix a few places in algebra
> > (at least retract in SquareMatrix) where the retraction from direct
> > product to scalars is used.
>
> Waldek,
>
> what exactly is the problem?
>
> coerce: R -> %
>
> or
>
> retract % -> R
>
> for % being DirectProduct(ndim, R)?
Your orignal problem is due to coerce. I think that
FullyRetractableTo is problematic because there are many
different reasonable definitions. OTOH if we put ring
structure on DirectProduct then only the current one
remains to be reasonable.
> Bill and me discussed the coercion. If you check hyperdoc for
> DirectProduct and click on "origin" for the function "coerce", then you
> see that coerce: R -> % comes from Algebra(R). It just needs that R is a
> CommutativeRing. Thus, removing FullyRetractableTo R will probably have
> no effect on my original problem.
Right, coerce also comes from Algebra(R). I would say that
retract and coerce make sense if we treat DirectProduct as
a ring. But when we multiply DirectProduct by an matrix
the ring structure of DirectProduct is irrelevant.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Ralf Hemmecke
> FullyRetractableTo is problematic because there are many different
> reasonable definitions.
I agree, but also consider that the original authors explicitly mention
this in DirectProductCategory.
++ Description:
++ This category represents a finite cartesian product of a given
++ type. Many categorical properties are preserved under this
++ construction.
> OTOH if we put ring structure on DirectProduct then only the current
> one remains to be reasonable.
I am happy with any definition/implementation as long as it fulfills the
specification. So currently, with the intention of a categorial lift
there is only one choice. But I agree, it is not really properly
specified to the point.
>> Bill and me discussed the coercion. If you check hyperdoc for
>> DirectProduct and click on "origin" for the function "coerce",
>> then you see that coerce: R -> % comes from Algebra(R). It just
>> needs that R is a CommutativeRing. Thus, removing
>> FullyRetractableTo R will probably have no effect on my original
>> problem.
> Right, coerce also comes from Algebra(R). I would say that retract
> and coerce make sense if we treat DirectProduct as a ring. But when
> we multiply DirectProduct by an matrix the ring structure of
> DirectProduct is irrelevant.
I agree to your last sentence, but I don't see how one can use that
information.
Originally I wanted for an integral domain R, F:=Fraction(R),
S:=SquareMatrix(2,F) to find appropriate matches for inserting coercions
so that
*: (R, S) -> X
can result. With your observation the coercion
coerce: R -> D
for D := DirectProduct(2, R) would be forbidden, because the respective
multiplication
*: (D, S) -> D
would be a "matrix multiplication that relies on the free module
structure of D rather than D being a ring.
Yes, it would be nice if that could be used, but I don't see how.
Anyway, I like your observation.
Ralf