Discussion :

[Ulath0]

Bonjour,

La minuscule fonction suivante semble poser des problèmes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
truc = function(b) {
	inData = as.matrix(read.table("inputs.txt"))
	outData = as.matrix(read.table("outputs.txt"))
 
	if (b) {
		s = svd(outData) ; basis = s$v[,1:3]
		embedding = outData %*% basis
		#write(t(embedding),"embedding.txt",ncolumns=3)
	}
	else embedding = as.matrix(read.table("embedding.txt"))
 
	testInds = c(5,2,16)
	trainInds = c(8, 4, 22, 3, 21, 11, 12, 23, 26, 27, 20, 17, 15, 24, 19, 29, 33, 18, 25, 30, 14, 9, 6, 32, 28, 10, 31, 7, 13, 1)
	p = ppr( inData[trainInds,],embedding[trainInds,1],nterms=6 ) ; p
}

Résultats :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
> truc(F)
Call:
ppr(x = inData[trainInds, ], y = embedding[trainInds, 1], nterms = 6)
 
Goodness of fit:
  6 terms 
0.1178330 
 
> truc(T)
 
 *** caught segfault ***
address 0x41ab000, cause 'memory not mapped'
Erreur de segmentation

Après plusieurs heures de débuggage en obtenant ces résultats, je me dis "comment une SVD peut "perturber" la fonction ppr ?!". ça semble ridicule =/

Note 1 : inputs.txt, outputs.txt et embedding.txt sont des matrices à 33 rangées, et respectivement 3, 200 et 3 colonnes.
Note 2 : il y a un paquet de trucs sans intérêt dans mon .RData, dont peut-être des choses conflictuelles.. j'essaye en effaçant tout ça pour voir.
[EDIT : c'est exactement le même bug avec .RData et .Rhistory vides ! J'y comprends rien]

Et c'est pas fini : le bug semble dépendant de la machine ; au bureau j'obtiens le même plantage, mais pour un jeu de données légèrement différent. Youpi..

Si vous avez une idée, merci d'avance :-)

[Ulath0]

Parfois j'ai droit à un backtrace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
> truc(T)
 
 *** caught segfault ***
address 0x3b61000, cause 'memory not mapped'
 
Traceback:
 1: .Fortran(R_smart, as.integer(ml), as.integer(mu), as.integer(p),     as.integer(q), as.integer(n), as.double(weights), as.double(t(x)),     as.double(t(y)), as.double(ww), smod = double(msmod), as.integer(msmod),     double(nsp), as.integer(nsp), double(ndp), as.integer(ndp),     edf = double(ml))
 2: ppr.default(inData[trainInds, ], embedding[trainInds, 1], nterms = 6)
 3: ppr(inData[trainInds, ], embedding[trainInds, 1], nterms = 6)
 4: truc(T)

..mais n'ai guère envie d'aller fouiller le code Fortran :-)

Parfois aussi c'est un bus error ..etc. Que du bonheur. même après vidage de .RData .Rhistory et reboot. J'ai également vérifié les fichiers de matrices : ils contiennent bien de bonnes vieilles matrices numériques. Très bizarre tout ça =/

[Ulath0]

Je me sens un peu seul mais ai peut-être une piste :
"This code is extremely sensitive to the compiler used" (dans les détails de l'aide help(ppr) ).

D'ailleurs en utilisant les SVR (support vector regression) le code - global, pas juste l'exemple ci-dessus - ne segfault pas. Je vais finir par réimplémenter ppr() ?! =/ Enfin ça m'intéresse de le coder, mais ce sera jamais aussi rapide que le ppr Fortran codé quasi exclusivement avec des if et des goto, avec 3 lignes de commentaires pour 300 lignes de codes