>> Daniel Goujot wrote:
>> [...] to compute the multiplication in a block wise fashion.
On Tue, 23 Mar 1999, E. Robert Tisdale wrote:
> No. This does not solve the striding problem. Striding is a problem
> because the memory system fetches two or more elements
> to fill the typical cache line but only one of them is used.
> The block decomposition strategy is effective
> when the footprint of a row of matrix M together with matrix N
> exceeds the size of the data cache.
> I believe that the block decomposition strategy should be
> even more effective with the dot product of two large matrices.
Sorry but I have too few knowledge to fully understand you.
Say, for a matrix multiplication, if a row R of the left matrix needs to
be used 45 times because the footprint of the corresponding row of the
product matrix has 45 elements, do you mean to load that row R 45 times in
cache lines ?
> The purpose of this mailing list is to discuss choices just like this.
> That's what standardization is all about. Amateur programmers
> have different priorities than professional programmers
> and perhaps there should be a separate standard for them.
I write it down in my mind. Sorry.
> But you are evaluating an expression containing left associative operators
> right to left which will usually yield a slightly different result
> and you will need to explain this to the programmer.
Isn't it what the programmer expects when he types things like :
const Vector vector_a((-3) * matrix_b * matrix_c * vector_d) ?
>> I have done an implementation of matrices and vectors
>> relative to algebra basis, to make easier
>> the implementation of wavelet transform
>> in Partial Differential Equation resolution.
>> Not yet stable. Not yet commented. Under GPL.
> Please tell us how to get it?
This is still in alpha state. There is lots of bad choices. Examples given :
- All is #included ;
- All identifiers are long but in french ;
- I have just commented the hacks ;
- In the vector and matrix structures, the unique iterator is still hard
included in the classes (because iterators have lots of functionnalities
to deal with the sparse state, due to the duality number/base element in
indices).
And I am now going to sit for an important examination. In fact I am quite
young (22 years old). You may understand why I cannot give it before
learning C++ deeper and fixing my things.
In October I should publish a better version. (would be at
http://ann.jussieu.fr/~goujot/, my future web page)
Daniel Goujot
The question of the day : why is it too difficult to use reference types
in STL template arguments ? [map<Vector const &, Vector const &> won't
compile : reference to reference type]
Quotes from my main :
typedef fl_template<double> fl8;
typedef Ondelette_sur_01<Chapeau_Schauder> O1c;
typedef Produit_isotrope2<O1c,O1c> O2c;
typedef Vecteur_inexact<fl8,O2c> Vc;
typedef Matrice_inexacte<fl8,O2c,O2c> Mc;
typedef pointeur<Espace<O2c>const> Ec;
[...]
Ec espace_inconnues_c = O2c::cree_espace(jmax, jmax, false, string("tube horizontal en ouverture dirichlet"));
Ec espace_dirichlet_c = O2c::cree_espace(jmax, jmax, false, string("bords tube horizontal"));
Ec espace_dirichlet_gauche_c = O2c::cree_espace(jmax, jmax, false, string("bord gauche tube horizontal"));
INFORMATION("Construction du système en base chapeaux")
Mc operateur_c (Matrice_DivKGrad<fl8,O2c>::de(arguments[1], jmax),0/*erreur*/);
Vc vecteur_moteur_c(espace_dirichlet_gauche_c);
vecteur_moteur_c += 1;
Vc vecteur_limite_c(espace_dirichlet_c);
vecteur_limite_c += vecteur_moteur_c;
Vc second_membre_c(espace_inconnues_c);
second_membre_c += (-1) * operateur_c.restreinte(espace_inconnues_c, espace_dirichlet_c) * vecteur_limite_c;