ortogonalizzare [] funziona come previsto solo se applicato due volte

Question

Applicando Orthogonalize[] una volta:

v1 = PolyhedronData["Dodecahedron", "VertexCoordinates"][[1]]; 
Graphics3D[Line[{{0, 0, 0}, #}] & /@ 
    Orthogonalize[{a, b, c} /. 
    FindInstance[{a, b, c}.v1 == 0 && (Chop@a != 0.||Chop@b != 0.||Chop@c != 0.), 
    {a, b, c}, Reals, 4]], Boxed -> False] 

E ora due volte:

Graphics3D[Line[{{0, 0, 0}, #}] & /@ 
    Orthogonalize@Orthogonalize[{a, b, c} /. 
    FindInstance[{a, b, c}.v1 == 0 && (Chop@a != 0.||Chop@b != 0.||Chop@c != 0.), 
    {a, b, c}, Reals, 4]], Boxed -> False] 

Errr ... Perché ?

Answer 1

Ho anche pensato che sarebbe un errore di numerico, ma non riusciva a capire il motivo per cui , così ho cercato di implementare Gram-Schmidt orthogonalization me stesso, sperando di capire il problema sulla strada:

(* projects onto a unit vector *) 
proj[u_][v_] := (u.v) u 

Clear[gm, gramSchmidt] 

gm[finished_, {next_, rest___}] := 
With[{v = next - Plus @@ Through[(proj /@ finished)[next]]}, 
    gm[Append[finished, Normalize@Chop[v]], {rest}] 
] 

gm[finished_, {}] := finished 

gramSchmidt[vectors_] := gm[{}, vectors] 

^{(incluso a scopo puramente illustrativo, ho semplicemente potuto non del tutto a capire cosa sta succedendo prima di reimplementato io stesso.)}

un passaggio fondamentale qui, che non mi rendevo conto prima, è decidere se un vettore che otteniamo è azzerare o meno prima del il passo di normalizzazione (vedere Chop nel mio codice). Altrimenti potremmo ottenere qualcosa di minuscolo, forse un semplice errore numerico, che viene poi normalizzato in un grande valore.

Questo sembra essere controllato dall'opzione Tolerance di Orthogonalize, e infatti, aumentando la tolleranza, e costringendolo a scartare piccoli vettori risolve il problema che si descrive. Orthogonalize[ ... , Tolerance -> 1*^-10] funziona in un unico passaggio.

Answer 2

Forse è una caratteristica del metodo GramSchmidt predefinito?

Prova: Method -> "Reorthogonalization" o Method -> "Householder".

Answer 3

ritengo il primo risultato è causa di errore numerico, prendendo

sys = {a,b,c}/.FindInstance[ 
      {a, b, c}.v1 == 0 && (Chop@a != 0. || Chop@b != 0. || Chop@c !=0.), 
      {a, b, c}, Reals, 4]; 

quindi MatrixRank@sys restituisce 2, per esso il sistema stesso è solo bidimensionale. Per me, questo implica che la prima istanza di Orthogonalize stia generando un errore numerico e che la seconda istanza stia usando l'errore fuori piano per fornire i tre vettori. Rimozione dei Chop condizioni corregge questo,

Orthogonalize[{a, b, c} /. 
    N@FindInstance[{a, b, c}.v1 == 0,{a, b, c}, Reals, 4]] 

dove N è necessario per sbarazzarsi del Root termini che compaiono. Questo ti dà un sistema bidimensionale, ma puoi ottenerne un terzo prendendo il prodotto incrociato.

Modifica: Ecco ulteriori prove che il suo errore numerico dovuto a Chop.

Con Chop, FindInstance mi dà

{{64., 3.6, 335.108}, {-67., -4.3, -350.817}, {0, 176., 0}, 
{-2., -4.3, -10.4721}} 

Senza Chop, ottengo

{{-16.8, 3.9, -87.9659}, {6.6, -1.7, 34.558}, {13.4, -4.3, 70.1633}, 
{19.9, -4.3, 104.198}} 

che è una differenza significativa tra i due.