Dear Michael Contrast sage: A=matrix(QQ,[[1, 2], [3,4]]) sage: G,M=M.gram_schmidt() sage: A=matrix(QQ,[[1, 2], [3,4]]) sage: G,M=A.gram_schmidt() sage: M*G==A True
with sage: Ar=matrix(RDF,[[1, 2], [3,4]]) sage: Gr,Mr=Ar.gram_schmidt() sage: Mr*Gr==Ar False sage: Mr*Gr-A [-1.1102230246251565e-16 -2.220446049250313e-16] [-1.3322676295501878e-15 0.0] Writing *correctly* this decomposition is, IIRC, a numerical analysis bitch... You are, IIRC, led to compute differences of large products, where underflows can easily slip into... Definitely not an amateur's problem. While I agree in principle with Simon, actually *doing* it isn't easy. Le jeudi 24 octobre 2019 18:20:36 UTC+2, Simon King a écrit : > > Hi Michael, > > On 2019-10-24, Michael Jung <mic...@uni-potsdam.de <javascript:>> wrote: > > Maybe, I did get something wrong. But what's the problem about > Gram-Schmidt > > on SR? There are just sums and divisions (and probably roots to > normalize) > > in Gram-Schmidt which should not lead to problems in SR. > > > > By the way, what does "exact" actually mean? > > It means that arithmetics is not affected by rounding/approximations. > And some methods (apparently Gram-Schmidt is one of them) is only "safe" > when no rounding occurs. > > That said, I'd appreciate to add an option that forces such methods > even in an inexact ring. > > Best regards, > Simon > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/f23d7ca4-6ea9-46ae-b559-c2b5c2f82af5%40googlegroups.com.
