Equations/contraintes

Marc Boyer

13/11/2006 à 09:23

Le 13-11-2006, Fabien LE LEZ a écrit :

J'ai une équation à n+2 inconnues, de la forme :

x[0] + x[1] + ... + x[n] = y

Ben, il me semble que la solution classique, c'est
une matrice. M qui encode
M.X = Y
avec X = (x[0]...x[n])
Y = (y[0]...y[n])

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Michel Decima

13/11/2006 à 09:27

Bonjour,

J'ai une équation à n+2 inconnues, de la forme :

x[0] + x[1] + ... + x[n] = y

Je dois écrire une fonction qui résoud cette équation avec un ensemble
de contraintes. (Ce solveur renvoie un objet opaque contenant les x[i]
et y, objet passé directement à d'autres fonctions de la
bibliothèque.)

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

Mon problème : sous quelle forme puis-je passer ces contraintes (ou
équations secondaires) à la fonction, de telle sorte que :
- le solveur soit assez rapide, et raisonnablement facile à
implémenter et à maintenir ;
- les appels à cette fonction soient relativement élégants et
faciles à lire, quel que soit le cas de figure ?

Ce que tu demandes ressemble fortement a l'API de Ilog CPLEX pour
la description de programmes linéaires. En (tres) gros, ton premier
exemple ressemblerait a ca dans cette API:

Model m;
VarArray x(m);
RangeArray c(m);

x.add( Var(m), 0.0, 100.0 );
x.add( Var(m) );
x.add( Var(m) );
x.add( Var(m) );
m.add( Maximize(m, x[0] + x[1] + x[2] + x[3] + x[4] );

c.add( x[0] == 42 );
c.add( x[1] - 2 * x[2] == 0);
c.add( x[3] - x[4] == 10);
m.add(c);

m.solve();

Dans la realite ca doit etre un peu different, je cite de memoire parce
que je n'ai plus acces a la documentation ici, et je ne sais pas si elle
est disponible en ligne.

Toute l'astuce consiste a construire des expressions a partir des
variables et des operateurs surchargés, et ensuite donner ca au moteur
de calcul caché derriere la variable Model, apres avoir fait la
traduction pour qu'il puisse comprendre.
(et quand tu connais l'ancienne API CPLEX en C, tu apprecie vraiment la
nouvelle)

Mes quelques essais sont fonctionnels mais décevants : soit j'obtiens
un système trop rigide, soit chaque appel est une usine à gaz.

En gros, j'aimerais pouvoir écrire :

Résoudre ("y0 ; il existe un z tel que x[0]=1.5*z, x[1]=2.6*z, et
tous les autres x[i] sont égaux à z")

ou bien

Résoudre ("x[0]=4 ; x[1]=8")

Je ne sais pas si tu vas considerer ce que je presente au dessus, mais
tu est sur que tu veux toujours exprimer le probleme dans une chaine de
caracteres ?

Bonjour,

J'ai une équation à n+2 inconnues, de la forme :

x[0] + x[1] + ... + x[n] = y

Je dois écrire une fonction qui résoud cette équation avec un ensemble
de contraintes. (Ce solveur renvoie un objet opaque contenant les x[i]
et y, objet passé directement à d'autres fonctions de la
bibliothèque.)

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

Mon problème : sous quelle forme puis-je passer ces contraintes (ou
équations secondaires) à la fonction, de telle sorte que :
- le solveur soit assez rapide, et raisonnablement facile à
implémenter et à maintenir ;
- les appels à cette fonction soient relativement élégants et
faciles à lire, quel que soit le cas de figure ?

Ce que tu demandes ressemble fortement a l'API de Ilog CPLEX pour
la description de programmes linéaires. En (tres) gros, ton premier
exemple ressemblerait a ca dans cette API:

Model m;
VarArray x(m);
RangeArray c(m);

x.add( Var(m), 0.0, 100.0 );
x.add( Var(m) );
x.add( Var(m) );
x.add( Var(m) );
m.add( Maximize(m, x[0] + x[1] + x[2] + x[3] + x[4] );

c.add( x[0] == 42 );
c.add( x[1] - 2 * x[2] == 0);
c.add( x[3] - x[4] == 10);
m.add(c);

m.solve();

Dans la realite ca doit etre un peu different, je cite de memoire parce
que je n'ai plus acces a la documentation ici, et je ne sais pas si elle
est disponible en ligne.

Toute l'astuce consiste a construire des expressions a partir des
variables et des operateurs surchargés, et ensuite donner ca au moteur
de calcul caché derriere la variable Model, apres avoir fait la
traduction pour qu'il puisse comprendre.
(et quand tu connais l'ancienne API CPLEX en C, tu apprecie vraiment la
nouvelle)

Mes quelques essais sont fonctionnels mais décevants : soit j'obtiens
un système trop rigide, soit chaque appel est une usine à gaz.

En gros, j'aimerais pouvoir écrire :

Résoudre ("y0 ; il existe un z tel que x[0]=1.5*z, x[1]=2.6*z, et
tous les autres x[i] sont égaux à z")

ou bien

Résoudre ("x[0]=4 ; x[1]=8")

Je ne sais pas si tu vas considerer ce que je presente au dessus, mais
tu est sur que tu veux toujours exprimer le probleme dans une chaine de
caracteres ?

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

J'ai une équation à n+2 inconnues, de la forme :

x[0] + x[1] + ... + x[n] = y

Je dois écrire une fonction qui résoud cette équation avec un ensemble
de contraintes. (Ce solveur renvoie un objet opaque contenant les x[i]
et y, objet passé directement à d'autres fonctions de la
bibliothèque.)

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

Mon problème : sous quelle forme puis-je passer ces contraintes (ou
équations secondaires) à la fonction, de telle sorte que :
- le solveur soit assez rapide, et raisonnablement facile à
implémenter et à maintenir ;
- les appels à cette fonction soient relativement élégants et
faciles à lire, quel que soit le cas de figure ?

Ce que tu demandes ressemble fortement a l'API de Ilog CPLEX pour
la description de programmes linéaires. En (tres) gros, ton premier
exemple ressemblerait a ca dans cette API:

Model m;
VarArray x(m);
RangeArray c(m);

x.add( Var(m), 0.0, 100.0 );
x.add( Var(m) );
x.add( Var(m) );
x.add( Var(m) );
m.add( Maximize(m, x[0] + x[1] + x[2] + x[3] + x[4] );

c.add( x[0] == 42 );
c.add( x[1] - 2 * x[2] == 0);
c.add( x[3] - x[4] == 10);
m.add(c);

m.solve();

Dans la realite ca doit etre un peu different, je cite de memoire parce
que je n'ai plus acces a la documentation ici, et je ne sais pas si elle
est disponible en ligne.

Toute l'astuce consiste a construire des expressions a partir des
variables et des operateurs surchargés, et ensuite donner ca au moteur
de calcul caché derriere la variable Model, apres avoir fait la
traduction pour qu'il puisse comprendre.
(et quand tu connais l'ancienne API CPLEX en C, tu apprecie vraiment la
nouvelle)

Mes quelques essais sont fonctionnels mais décevants : soit j'obtiens
un système trop rigide, soit chaque appel est une usine à gaz.

En gros, j'aimerais pouvoir écrire :

Résoudre ("y0 ; il existe un z tel que x[0]=1.5*z, x[1]=2.6*z, et
tous les autres x[i] sont égaux à z")

ou bien

Résoudre ("x[0]=4 ; x[1]=8")

Je ne sais pas si tu vas considerer ce que je presente au dessus, mais
tu est sur que tu veux toujours exprimer le probleme dans une chaine de
caracteres ?

Fabien LE LEZ

13/11/2006 à 16:03

On Mon, 13 Nov 2006 09:27:34 +0100, Michel Decima
:

mais
tu est sur que tu veux toujours exprimer le probleme dans une chaine de
caracteres ?

Absolument pas. Je veux juste une syntaxe simple et lisible.

Fabien LE LEZ

13/11/2006 à 16:17

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Ben, il me semble que la solution classique, c'est
une matrice.

Note que la résolution en elle-même ne me pose pas vraiment de
problème.

Là où je coince, c'est la définition d'une syntaxe agréable pour que
le code client puisse indiquer les contraintes.

Sylvain

13/11/2006 à 22:33

Fabien LE LEZ wrote on 13/11/2006 16:17:

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pour que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de résoudre un
système vaguement mathématique, autant parler vaguement mathématique (le
fait que C/C++ indexe à partir de zéro n'a rien à voir avec le pb).

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe -- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

(en ne considérant que des entiers) si on introduis 'Operand' comme:

struct Operand {
long value; // a déterminer ou fixée
long factor; // facteur multiplicatif appliqué à cette inconnue
long power; // exposant appliqué à cette inconnue

Operand(); // operande sans relation de dépendance et sans valeur
connue, tel x2 et x4
Operand(long); // operande constant, tel x0
Operand(Equation&); operande avec relation de dépendance, tel x1
};

on définira alors qlq opérations comme:

Equation operator* (Operand&, long);
Equation operator* (long, Operand&);
Equation operator+ (Operand&, Operand&);
Equation operator+ (Operand&, long);
Equation operator+ (Equation&, Operand&);
Equation operator+ (Equation&, long);

avec:

struct Equation {
vector<Operand> operandes; // list des operandes non const
bool operator== (long z); // résoud Equation==z, retourne true si
sol° trouvée

}
Equation offrira une fonction cout (gérée par un arbre qui évalue les
Operand) qui devra égaler 'z'.

on écrira alors:

Operand c, e;
Operand a = 42;
Equation b = 2 * c;
Equation d = e + 10;

if ((a + b + c + d + e) == 100){
cout << a << b << ...;
}

ou plus volontiers

if ((3 * c + 2 * e + 52) == 100){
// généralement insoluble le nb d'inconnues étant > à nb d'équations.
}

Sylvain.

Fabien LE LEZ wrote on 13/11/2006 16:17:

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pour que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de résoudre un
système vaguement mathématique, autant parler vaguement mathématique (le
fait que C/C++ indexe à partir de zéro n'a rien à voir avec le pb).

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe -- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

(en ne considérant que des entiers) si on introduis 'Operand' comme:

struct Operand {
long value; // a déterminer ou fixée
long factor; // facteur multiplicatif appliqué à cette inconnue
long power; // exposant appliqué à cette inconnue

Operand(); // operande sans relation de dépendance et sans valeur
connue, tel x2 et x4
Operand(long); // operande constant, tel x0
Operand(Equation&); operande avec relation de dépendance, tel x1
};

on définira alors qlq opérations comme:

Equation operator* (Operand&, long);
Equation operator* (long, Operand&);
Equation operator+ (Operand&, Operand&);
Equation operator+ (Operand&, long);
Equation operator+ (Equation&, Operand&);
Equation operator+ (Equation&, long);

avec:

struct Equation {
vector<Operand> operandes; // list des operandes non const
bool operator== (long z); // résoud Equation==z, retourne true si
sol° trouvée

}
Equation offrira une fonction cout (gérée par un arbre qui évalue les
Operand) qui devra égaler 'z'.

on écrira alors:

Operand c, e;
Operand a = 42;
Equation b = 2 * c;
Equation d = e + 10;

if ((a + b + c + d + e) == 100){
cout << a << b << ...;
}

ou plus volontiers

if ((3 * c + 2 * e + 52) == 100){
// généralement insoluble le nb d'inconnues étant > à nb d'équations.
}

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

Fabien LE LEZ wrote on 13/11/2006 16:17:

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pour que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de résoudre un
système vaguement mathématique, autant parler vaguement mathématique (le
fait que C/C++ indexe à partir de zéro n'a rien à voir avec le pb).

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe -- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

(en ne considérant que des entiers) si on introduis 'Operand' comme:

struct Operand {
long value; // a déterminer ou fixée
long factor; // facteur multiplicatif appliqué à cette inconnue
long power; // exposant appliqué à cette inconnue

Operand(); // operande sans relation de dépendance et sans valeur
connue, tel x2 et x4
Operand(long); // operande constant, tel x0
Operand(Equation&); operande avec relation de dépendance, tel x1
};

on définira alors qlq opérations comme:

Equation operator* (Operand&, long);
Equation operator* (long, Operand&);
Equation operator+ (Operand&, Operand&);
Equation operator+ (Operand&, long);
Equation operator+ (Equation&, Operand&);
Equation operator+ (Equation&, long);

avec:

struct Equation {
vector<Operand> operandes; // list des operandes non const
bool operator== (long z); // résoud Equation==z, retourne true si
sol° trouvée

}
Equation offrira une fonction cout (gérée par un arbre qui évalue les
Operand) qui devra égaler 'z'.

on écrira alors:

Operand c, e;
Operand a = 42;
Equation b = 2 * c;
Equation d = e + 10;

if ((a + b + c + d + e) == 100){
cout << a << b << ...;
}

ou plus volontiers

if ((3 * c + 2 * e + 52) == 100){
// généralement insoluble le nb d'inconnues étant > à nb d'équations.
}

Sylvain.

Marc Boyer

14/11/2006 à 10:36

Le 13-11-2006, Fabien LE LEZ a écrit :

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :
Ben, il me semble que la solution classique, c'est
une matrice.

Note que la résolution en elle-même ne me pose pas vraiment de
problème.

Là où je coince, c'est la définition d'une syntaxe agréable pour que
le code client puisse indiquer les contraintes.

Ben, ça dépend des utilisateurs, ça...
La solution de Sylvain à base de surcharge des opérateurs
C++ est tentante, à condition que les utilisateurs acceptent
les messages d'erreur du compilateur.
Sinon, une string et un bête parseur...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

James Kanze

15/11/2006 à 09:32

Sylvain wrote:

Fabien LE LEZ wrote on 13/11/2006 16:17:
On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pou r que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.
Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ». Je ne vois pas
pourquoi une formulation du problème serait moins valide que
l'autre. La seule contrainte, c'est que « dernière indice + 2 =
nombre d'inconnus ».

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit. Il
aurait pu aussi bien utiliser la notation TeX (c-à-d
« x_0... »), sans rien changer. Si je me basais sur le C++,
j'écrirais :
x[0] + x[1] + ... + x[n-1] = y
et « une équation de n+1 inconnues ». n était, évidemment, la
taille du vector x.

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mai s une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste ),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

[solution supprimée...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation. Pour un système plus dynamique, je ne vois
pratiquement que la possibilité d'une arbrescence d'expressions
à base des classes polymorphiques comme représentation interne.
Le problème de comment permettre à l'utilisateur de le
construire facilement reste, mais pour celà, il faudrait savoir
qui sont les utilisateurs. (S'il sont des programmeurs, et le
projet de Fabien est une bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.
S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sylvain wrote:

Fabien LE LEZ wrote on 13/11/2006 16:17:

On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pou r que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.
Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ». Je ne vois pas
pourquoi une formulation du problème serait moins valide que
l'autre. La seule contrainte, c'est que « dernière indice + 2 =
nombre d'inconnus ».

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit. Il
aurait pu aussi bien utiliser la notation TeX (c-à-d
« x_0... »), sans rien changer. Si je me basais sur le C++,
j'écrirais :
x[0] + x[1] + ... + x[n-1] = y
et « une équation de n+1 inconnues ». n était, évidemment, la
taille du vector x.

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mai s une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste ),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

[solution supprimée...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation. Pour un système plus dynamique, je ne vois
pratiquement que la possibilité d'une arbrescence d'expressions
à base des classes polymorphiques comme représentation interne.
Le problème de comment permettre à l'utilisateur de le
construire facilement reste, mais pour celà, il faudrait savoir
qui sont les utilisateurs. (S'il sont des programmeurs, et le
projet de Fabien est une bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.
S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

Fabien LE LEZ wrote on 13/11/2006 16:17:
On Mon, 13 Nov 2006 08:23:57 +0000 (UTC), Marc Boyer :

Là où je coince, c'est la définition d'une syntaxe agréable pou r que
le code client puisse indiquer les contraintes.

là où je ne suis pas sur de comprendre est sur la définition d'une
*contrainte* ...

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.
Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ». Je ne vois pas
pourquoi une formulation du problème serait moins valide que
l'autre. La seule contrainte, c'est que « dernière indice + 2 =
nombre d'inconnus ».

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit. Il
aurait pu aussi bien utiliser la notation TeX (c-à-d
« x_0... »), sans rien changer. Si je me basais sur le C++,
j'écrirais :
x[0] + x[1] + ... + x[n-1] = y
et « une équation de n+1 inconnues ». n était, évidemment, la
taille du vector x.

Par exemple :
x[0] = 42
x[1] = 2*x[2]
x[3] = x[4]+10
y = 100

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mai s une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste ),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

[solution supprimée...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation. Pour un système plus dynamique, je ne vois
pratiquement que la possibilité d'une arbrescence d'expressions
à base des classes polymorphiques comme représentation interne.
Le problème de comment permettre à l'utilisateur de le
construire facilement reste, mais pour celà, il faudrait savoir
qui sont les utilisateurs. (S'il sont des programmeurs, et le
projet de Fabien est une bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.
S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Fabien LE LEZ

15/11/2006 à 14:50

On 15 Nov 2006 00:32:07 -0800, "James Kanze" :

mais pour celà, il faudrait savoir
qui sont les utilisateurs.

C'est moi.

Je veux définir la syntaxe de telle sorte que je puisse utiliser la
bibliothèque que j'aurai construite, de façon lisible et pas trop
verbeuse.

Sylvain

15/11/2006 à 23:17

James Kanze wrote on 15/11/2006 09:32:

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

oui enfin, ici, il cause au forum, pas à des utilisateurs à qui il faut
laisser le maximum de liberté toussa ...

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

il serait aussi inapproprié de dire système à (m - 3) inconnues, où "par
convention" (!) (m = nb de valeurs à déterminer + on-sait-pas-combien).

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

et quitte à rappeler des vrais basiques, je reprends mes termes:
"a x + b = y" est une 'équation', par exemple, puisque la banque t'es
familière, le taux de rendement d'un placement donné est défini par une
telle équation (du 1ier degré): rendement = a * capital + b

en physique, plus qu'en math., et moins que dans la vie quotidienne, on
parle de condition initiale, ici: si ton capital est nul, ton rendement
est nul, donc b = 0 (un matheux verra cela comme une des solutions
particulières satisfaisant l'équation, ie le couple (x,y)={0,0}

peuvent venir des "contraintes" (pas comme elles ont été introduites
ici, tous les exemples étaient des dépendances sous forme d'équation),
par exemple: tel a doit être positif non nul (si tu veux vraiment un
rendement) ou encore a doit avoir une borne supérieure de 5% (le reste
allant directement dans la poche du banquier).

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

ce que je vois est plutôt deux problèmes distincts:
- la nécessité de requérir à un module de simplification de
l'expression, ayant:
x0 = 42
x1 = 2 . x2
x2 = inconnu

et puisque les opérations semblent porter sur un groupe associatif et
commutatif, l'expression

x0 + x1 + x2

doit être réévaluée en

3 . x2 + 42

premier point à résoudre.

- la nécessité de requérir le bon solveur, le type Equation que j'ai
donné n'est évidemment qu'une facade: son opérateur == a des chances de
répondre qu'à un seul type de problème: quel est /a/ dans y = a . x,
sachant que le couple (x,y)={10000,250} satisfait l'équation ...

si j'écris

x0 + x1 * x2

je ne peux plus utiliser le même solveur bêtement parce que j'ai une
équation du 2nd degré.

et btw, le gros travail d'une feuille de calcul (mapple, mathematica,
...) est justement de 1) simplifier intelligemment, 2) de trouver quel
solveur peut traiter l'équation(s) restantes.

pour conclure sur les "contraintes", celles-ci ne doivent inclure que
des conditions auto-contenues (non des dépendances) sur les variables à
déterminer (comme par exemple des condition de domaines de définition).

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

non, c'est écrire une des équations qui forment le système à résoudre.

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écrire
/une/ implémentation pour un code gérant différents types de données
(entiers, complexes, matrices, ...) avec la même algorithmie.

reste justement à choisir cette algorithmie, ie quels type systèmes (n
eq. à 1 inconnue -> régression linéaire; n éq. à n inconnues -> pivot;
...) sont supportés ... et il ""suffira"" de piocher (avec ou sans
template) dans les Numerical Recipies ensuite.

[] mais pour celà, il faudrait savoir
qui sont les utilisateurs.

oui, en effet.

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de données
pouvant être traitée de manière unique.

S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le moyen d'écrire
du script (et non du code!); il y a une nuance entre les 2.

Sylvain.

James Kanze wrote on 15/11/2006 09:32:

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

oui enfin, ici, il cause au forum, pas à des utilisateurs à qui il faut
laisser le maximum de liberté toussa ...

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

il serait aussi inapproprié de dire système à (m - 3) inconnues, où "par
convention" (!) (m = nb de valeurs à déterminer + on-sait-pas-combien).

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

et quitte à rappeler des vrais basiques, je reprends mes termes:
"a x + b = y" est une 'équation', par exemple, puisque la banque t'es
familière, le taux de rendement d'un placement donné est défini par une
telle équation (du 1ier degré): rendement = a * capital + b

en physique, plus qu'en math., et moins que dans la vie quotidienne, on
parle de condition initiale, ici: si ton capital est nul, ton rendement
est nul, donc b = 0 (un matheux verra cela comme une des solutions
particulières satisfaisant l'équation, ie le couple (x,y)={0,0}

peuvent venir des "contraintes" (pas comme elles ont été introduites
ici, tous les exemples étaient des dépendances sous forme d'équation),
par exemple: tel a doit être positif non nul (si tu veux vraiment un
rendement) ou encore a doit avoir une borne supérieure de 5% (le reste
allant directement dans la poche du banquier).

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

ce que je vois est plutôt deux problèmes distincts:
- la nécessité de requérir à un module de simplification de
l'expression, ayant:
x0 = 42
x1 = 2 . x2
x2 = inconnu

et puisque les opérations semblent porter sur un groupe associatif et
commutatif, l'expression

x0 + x1 + x2

doit être réévaluée en

3 . x2 + 42

premier point à résoudre.

- la nécessité de requérir le bon solveur, le type Equation que j'ai
donné n'est évidemment qu'une facade: son opérateur == a des chances de
répondre qu'à un seul type de problème: quel est /a/ dans y = a . x,
sachant que le couple (x,y)={10000,250} satisfait l'équation ...

si j'écris

x0 + x1 * x2

je ne peux plus utiliser le même solveur bêtement parce que j'ai une
équation du 2nd degré.

et btw, le gros travail d'une feuille de calcul (mapple, mathematica,
...) est justement de 1) simplifier intelligemment, 2) de trouver quel
solveur peut traiter l'équation(s) restantes.

pour conclure sur les "contraintes", celles-ci ne doivent inclure que
des conditions auto-contenues (non des dépendances) sur les variables à
déterminer (comme par exemple des condition de domaines de définition).

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

non, c'est écrire une des équations qui forment le système à résoudre.

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écrire
/une/ implémentation pour un code gérant différents types de données
(entiers, complexes, matrices, ...) avec la même algorithmie.

reste justement à choisir cette algorithmie, ie quels type systèmes (n
eq. à 1 inconnue -> régression linéaire; n éq. à n inconnues -> pivot;
...) sont supportés ... et il ""suffira"" de piocher (avec ou sans
template) dans les Numerical Recipies ensuite.

[] mais pour celà, il faudrait savoir
qui sont les utilisateurs.

oui, en effet.

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de données
pouvant être traitée de manière unique.

S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le moyen d'écrire
du script (et non du code!); il y a une nuance entre les 2.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze wrote on 15/11/2006 09:32:

une équation à satisfaire je connais, une condition initiale ou une
règle d'inférence aussi, mais contrainte est ici très vague !

C'est peut-être vague exprès, avec l'idée de laisser un maximum
de liberté à l'utilisateur. (Mais c'est sûr que ça ne facilite
ni la réalisation, ni même la définition d'une syntaxe pour
spécifier les contraintes.)

oui enfin, ici, il cause au forum, pas à des utilisateurs à qui il faut
laisser le maximum de liberté toussa ...

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

il serait aussi inapproprié de dire système à (m - 3) inconnues, où "par
convention" (!) (m = nb de valeurs à déterminer + on-sait-pas-combien).

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

et quitte à rappeler des vrais basiques, je reprends mes termes:
"a x + b = y" est une 'équation', par exemple, puisque la banque t'es
familière, le taux de rendement d'un placement donné est défini par une
telle équation (du 1ier degré): rendement = a * capital + b

en physique, plus qu'en math., et moins que dans la vie quotidienne, on
parle de condition initiale, ici: si ton capital est nul, ton rendement
est nul, donc b = 0 (un matheux verra cela comme une des solutions
particulières satisfaisant l'équation, ie le couple (x,y)={0,0}

peuvent venir des "contraintes" (pas comme elles ont été introduites
ici, tous les exemples étaient des dépendances sous forme d'équation),
par exemple: tel a doit être positif non nul (si tu veux vraiment un
rendement) ou encore a doit avoir une borne supérieure de 5% (le reste
allant directement dans la poche du banquier).

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

où x[0] = 42 est une condition initiale, elle fait que x0 n'est plus une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

ce que je vois est plutôt deux problèmes distincts:
- la nécessité de requérir à un module de simplification de
l'expression, ayant:
x0 = 42
x1 = 2 . x2
x2 = inconnu

et puisque les opérations semblent porter sur un groupe associatif et
commutatif, l'expression

x0 + x1 + x2

doit être réévaluée en

3 . x2 + 42

premier point à résoudre.

- la nécessité de requérir le bon solveur, le type Equation que j'ai
donné n'est évidemment qu'une facade: son opérateur == a des chances de
répondre qu'à un seul type de problème: quel est /a/ dans y = a . x,
sachant que le couple (x,y)={10000,250} satisfait l'équation ...

si j'écris

x0 + x1 * x2

je ne peux plus utiliser le même solveur bêtement parce que j'ai une
équation du 2nd degré.

et btw, le gros travail d'une feuille de calcul (mapple, mathematica,
...) est justement de 1) simplifier intelligemment, 2) de trouver quel
solveur peut traiter l'équation(s) restantes.

pour conclure sur les "contraintes", celles-ci ne doivent inclure que
des conditions auto-contenues (non des dépendances) sur les variables à
déterminer (comme par exemple des condition de domaines de définition).

-- les opérandes à modéliser devront donc avoir un statut
'valeur indéfinie' (et le solveur devra la trouver) ou 'définie', mais
dans le même temps cette représentation est surfaite (vue de
l'extérieur) puisque c'est une cste.

x1 = 2 * x0, ça c'est une relation (donnant ici une autre valeur cste),
s'agit-il de traduire cela en inférence ?

Imposer une rélation, c'est bien une contrainte, non.

non, c'est écrire une des équations qui forment le système à résoudre.

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écrire
/une/ implémentation pour un code gérant différents types de données
(entiers, complexes, matrices, ...) avec la même algorithmie.

reste justement à choisir cette algorithmie, ie quels type systèmes (n
eq. à 1 inconnue -> régression linéaire; n éq. à n inconnues -> pivot;
...) sont supportés ... et il ""suffira"" de piocher (avec ou sans
template) dans les Numerical Recipies ensuite.

[] mais pour celà, il faudrait savoir
qui sont les utilisateurs.

oui, en effet.

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de données
pouvant être traitée de manière unique.

S'il s'agit des utilisateurs externes, en revanche, il lui faut
un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le moyen d'écrire
du script (et non du code!); il y a une nuance entre les 2.

Sylvain.

James Kanze

16/11/2006 à 10:23

Sylvain wrote:

James Kanze wrote on 15/11/2006 09:32:

[...]

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

Il n'y a pas question d'être d'accord ou non. Tu peux arguer que
ce n'est pas bien formulé ; qu'il faut formuler l'expression en
termes de n inconnues, mais tu as deux déclarations, et n n'est
pas une variable indépendante dans les deux. Si tu dis « à n
inconnues », les indices doivent varier de 0 à n-2 (ou de 1 à
n-1). Sinon, il y a une contradiction.

il serait aussi inapproprié de dire système à (m - 3)
inconnues, où "par convention" (!) (m = nb de valeurs à
déterminer + on-sait-pas-combien).

Ce qui signifierait tout au plus qu'il faudrait faire parcourir
les indices de 0 à n-2. Personnellement, je n'ai jamais entendu
parler de cette règle, mais ça ne veut pas dire qu'elle n'existe
pas, au moins dans certains milieux mathématiques.

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

C'est vrai que la convention veut que des noms en fin de
l'alphabet soient des variables, et ceux au début soit des
constantes. Mais quel rapport avec l'énoncé de Fabien ? Ses
inconnues s'appelaient bien x et y, comme le veut la convention.

[...]

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Certes, sa valeur peut varier. Mais il doit bien avoir la même
valeur dans les deux parties de l'énoncé. Sinon, ça prète à la
confusion, et il vaudrait mieux prendre des noms différents.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

OK. Là, n'étant pas mathématicien, je ne prononcerai pas. Disons
simplement que sa formulation ne m'a pas choqué.

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

S'il avait écrit avec la notation TeX « x_0+x_1+...+x_n=y »,
il aurait aussi n+1 variables x et une variable y. Aucun rapport
avec le C++.

où x[0] = 42 est une condition initiale, elle fait que x0 n'est pl us une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

En effet. Ce qu'il cherche, c'est un système de résolution des
contraintes. On a une équation de base, avec une infinité de
solutions, et des contraintes, qui font écarter des solutions.

[...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écr ire
/une/ implémentation pour un code gérant différents types de donn ées
(entiers, complexes, matrices, ...) avec la même algorithmie.

C'est sans doute leur raison d'être. Mais il s'avère que les
templates, en C++, font un langage de programmation
Turing-complet, qui s'exécute lors de la compilation, pour
générer le code (des instantiations) qui fait partie ensuite du
programme. À premier abord, c'est un outil merveilleux pour
l'obfuscation, mais il en existe certaines utilisations dont les
avantages dépassent (parfois de loin) le coût en perte de
lisibilité.

À cet égard, je conseillerais vivement le livre « C++
Templates -- the Complete Guide », de Vandevoorde et Josuttis.
Non seulement il traite le problème en détail aussi bien du côté
théorique que du côté pratique, il est éminemment lisible,
qualité assez rare dans des livres techniques. Si tu
t'intéresses un peu dans le calcul numérique, tu aurais intérêt
aussi à jeter un coup d'oeil sur la bibliothèque Blitz++ de
Todd Veldhuizen, qui fait une utilisation intense de ces
techniques.

[...]

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de donné es
pouvant être traitée de manière unique.

Ce n'est pas là le problème auquel s'adresse des expressions
templatées. C'est vraiment un programme évalué par le
compilateur, pour générer du code. À la limite, Fabien décrit
ces contraintes, et le compilateur génère des constantes
immédiates pour chaque utilisation de x[i] ou de y.

Mais puisqu'il s'agit d'un calcul fait par le compilateur, il
faut évidemment que les contraintes soient constante, et connues
lors de la compilation.

S'il s'agit des utilisateurs externes, en revanche, il lui
faut un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le
moyen d'écrire du script (et non du code!); il y a une nuance
entre les 2.

S'il lui faut un langage de script, il lui faut un langage de
script. Pour l'instant, je ne sais pas assez ce qu'il veut faire
réelement pour prononcer.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sylvain wrote:

James Kanze wrote on 15/11/2006 09:32:

[...]

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

Il n'y a pas question d'être d'accord ou non. Tu peux arguer que
ce n'est pas bien formulé ; qu'il faut formuler l'expression en
termes de n inconnues, mais tu as deux déclarations, et n n'est
pas une variable indépendante dans les deux. Si tu dis « à n
inconnues », les indices doivent varier de 0 à n-2 (ou de 1 à
n-1). Sinon, il y a une contradiction.

il serait aussi inapproprié de dire système à (m - 3)
inconnues, où "par convention" (!) (m = nb de valeurs à
déterminer + on-sait-pas-combien).

Ce qui signifierait tout au plus qu'il faudrait faire parcourir
les indices de 0 à n-2. Personnellement, je n'ai jamais entendu
parler de cette règle, mais ça ne veut pas dire qu'elle n'existe
pas, au moins dans certains milieux mathématiques.

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

C'est vrai que la convention veut que des noms en fin de
l'alphabet soient des variables, et ceux au début soit des
constantes. Mais quel rapport avec l'énoncé de Fabien ? Ses
inconnues s'appelaient bien x et y, comme le veut la convention.

[...]

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Certes, sa valeur peut varier. Mais il doit bien avoir la même
valeur dans les deux parties de l'énoncé. Sinon, ça prète à la
confusion, et il vaudrait mieux prendre des noms différents.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

OK. Là, n'étant pas mathématicien, je ne prononcerai pas. Disons
simplement que sa formulation ne m'a pas choqué.

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

S'il avait écrit avec la notation TeX « x_0+x_1+...+x_n=y »,
il aurait aussi n+1 variables x et une variable y. Aucun rapport
avec le C++.

où x[0] = 42 est une condition initiale, elle fait que x0 n'est pl us une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

En effet. Ce qu'il cherche, c'est un système de résolution des
contraintes. On a une équation de base, avec une infinité de
solutions, et des contraintes, qui font écarter des solutions.

[...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écr ire
/une/ implémentation pour un code gérant différents types de donn ées
(entiers, complexes, matrices, ...) avec la même algorithmie.

C'est sans doute leur raison d'être. Mais il s'avère que les
templates, en C++, font un langage de programmation
Turing-complet, qui s'exécute lors de la compilation, pour
générer le code (des instantiations) qui fait partie ensuite du
programme. À premier abord, c'est un outil merveilleux pour
l'obfuscation, mais il en existe certaines utilisations dont les
avantages dépassent (parfois de loin) le coût en perte de
lisibilité.

À cet égard, je conseillerais vivement le livre « C++
Templates -- the Complete Guide », de Vandevoorde et Josuttis.
Non seulement il traite le problème en détail aussi bien du côté
théorique que du côté pratique, il est éminemment lisible,
qualité assez rare dans des livres techniques. Si tu
t'intéresses un peu dans le calcul numérique, tu aurais intérêt
aussi à jeter un coup d'oeil sur la bibliothèque Blitz++ de
Todd Veldhuizen, qui fait une utilisation intense de ces
techniques.

[...]

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de donné es
pouvant être traitée de manière unique.

Ce n'est pas là le problème auquel s'adresse des expressions
templatées. C'est vraiment un programme évalué par le
compilateur, pour générer du code. À la limite, Fabien décrit
ces contraintes, et le compilateur génère des constantes
immédiates pour chaque utilisation de x[i] ou de y.

Mais puisqu'il s'agit d'un calcul fait par le compilateur, il
faut évidemment que les contraintes soient constante, et connues
lors de la compilation.

S'il s'agit des utilisateurs externes, en revanche, il lui
faut un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le
moyen d'écrire du script (et non du code!); il y a une nuance
entre les 2.

S'il lui faut un langage de script, il lui faut un langage de
script. Pour l'instant, je ne sais pas assez ce qu'il veut faire
réelement pour prononcer.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

James Kanze wrote on 15/11/2006 09:32:

[...]

J'ai une équation à n+2 inconnues, de la forme :
x[0] + x[1] + ... + x[n] = y

non, tu as un système à n inconnues (point), si on parle de
résoudre un système vaguement mathématique, autant parler
vaguement mathématique.

S'il a une équation « x[0] + x[1] + ... + x[n] = y », ou tous
les x et le y sont inconnu, il a bien un système à n+2 inconnus.

non, je ne suis pas d'accord avec cette description!

Il n'y a pas question d'être d'accord ou non. Tu peux arguer que
ce n'est pas bien formulé ; qu'il faut formuler l'expression en
termes de n inconnues, mais tu as deux déclarations, et n n'est
pas une variable indépendante dans les deux. Si tu dis « à n
inconnues », les indices doivent varier de 0 à n-2 (ou de 1 à
n-1). Sinon, il y a une contradiction.

il serait aussi inapproprié de dire système à (m - 3)
inconnues, où "par convention" (!) (m = nb de valeurs à
déterminer + on-sait-pas-combien).

Ce qui signifierait tout au plus qu'il faudrait faire parcourir
les indices de 0 à n-2. Personnellement, je n'ai jamais entendu
parler de cette règle, mais ça ne veut pas dire qu'elle n'existe
pas, au moins dans certains milieux mathématiques.

pour descendre assez bas, si j'écris:

a . x + b = y

j'ai par convention (vrai ici) un système à 2 inconnues, pas 4!
'y' est le résultat de l'équation, pas inconnue, résultat.
'x' est la variable de l'équation, pas inconnue, variable.

C'est vrai que la convention veut que des noms en fin de
l'alphabet soient des variables, et ceux au début soit des
constantes. Mais quel rapport avec l'énoncé de Fabien ? Ses
inconnues s'appelaient bien x et y, comme le veut la convention.

[...]

Pour avoir un système à n inconnus, il faudrait que l'expression
se lise « x[0] + x[1] + ... + x[n-2] = y ».

re-non, un "syst. à /n/ variables" est une description mathématique,
ilse fout de ton /n/ vrai, et en particulier de ton n (variable max.
dans un code particulier); pose n' = n - 2 dans le texte initial et on
parle d'un syst. à n(') variables.

Certes, sa valeur peut varier. Mais il doit bien avoir la même
valeur dans les deux parties de l'énoncé. Sinon, ça prète à la
confusion, et il vaudrait mieux prendre des noms différents.

Je ne vois pas pourquoi une formulation du problème serait
moins valide que l'autre. La seule contrainte, c'est que
« dernière indice + 2 =nombre d'inconnus ».

je n'ai pas dit "moins valide" j'ai insinué "mal décrit".

OK. Là, n'étant pas mathématicien, je ne prononcerai pas. Disons
simplement que sa formulation ne m'a pas choqué.

(le fait que C/C++ indexe à partir de
zéro n'a rien à voir avec le pb).

Je ne vois pas de rapport avec le C++ dans ce qu'il a écrit.

moi je le vois, l'écriture C++ montre n+1 variables 'x' indexées et un
y, résultat "n + 2" (écriture non descriptive, donc pénalisante et de
plus erronée, 'y' n'est pas une inconnue).

S'il avait écrit avec la notation TeX « x_0+x_1+...+x_n=y »,
il aurait aussi n+1 variables x et une variable y. Aucun rapport
avec le C++.

où x[0] = 42 est une condition initiale, elle fait que x0 n'est pl us une
inconnue du système (soit on peux continuer à dire paramètre) mais une
constante fixe

Sauf qu'il a dit que c'est une contrainte. C'est sûr qu'une fois
toutes les contraintes précisées, et la solution trouvée, il ne
doit plus y avoir d'inconnues. Mais si l'utilisateur dit :
voici mon équation (std::vector<double> x, double y), et voici
mes contraintes (à définir -- c'était la question de Fabien, si
je ne me trompe pas), tout ce qui se trouve dans la deuxième
partie est une contrainte.

si on s'en tient à cela, on peut dire amen; y-a-plus-qu'à traiter les
contraintes alors ...

En effet. Ce qu'il cherche, c'est un système de résolution des
contraintes. On a une équation de base, avec une infinité de
solutions, et des contraintes, qui font écarter des solutions.

[...]

La véritable question, c'est la degrée de souplesse que veut
donner Fabien. Une solution à base des templates (basée sur des
idées développées par Todd Veldhuizen et David Vandevoorde, mais
plus anciennement, on se servait d'une technique semblable basée
sur des fonctions virtuelles) pourrait être très intéressants
dans le cas où les contraintes sont fixées déjà lors de la
compilation.

je ne connais pas les idées auxquelles tu fais référence; mais, ma
compréhension est que des fonctions templates ne serviront qu'à écr ire
/une/ implémentation pour un code gérant différents types de donn ées
(entiers, complexes, matrices, ...) avec la même algorithmie.

C'est sans doute leur raison d'être. Mais il s'avère que les
templates, en C++, font un langage de programmation
Turing-complet, qui s'exécute lors de la compilation, pour
générer le code (des instantiations) qui fait partie ensuite du
programme. À premier abord, c'est un outil merveilleux pour
l'obfuscation, mais il en existe certaines utilisations dont les
avantages dépassent (parfois de loin) le coût en perte de
lisibilité.

À cet égard, je conseillerais vivement le livre « C++
Templates -- the Complete Guide », de Vandevoorde et Josuttis.
Non seulement il traite le problème en détail aussi bien du côté
théorique que du côté pratique, il est éminemment lisible,
qualité assez rare dans des livres techniques. Si tu
t'intéresses un peu dans le calcul numérique, tu aurais intérêt
aussi à jeter un coup d'oeil sur la bibliothèque Blitz++ de
Todd Veldhuizen, qui fait une utilisation intense de ces
techniques.

[...]

[] bibliothèque dont ils se servent, une
solution à base des expressions templatées s'impose prèsque.

non, elle s'impose que s'il (doit) existe(r) différents type de donné es
pouvant être traitée de manière unique.

Ce n'est pas là le problème auquel s'adresse des expressions
templatées. C'est vraiment un programme évalué par le
compilateur, pour générer du code. À la limite, Fabien décrit
ces contraintes, et le compilateur génère des constantes
immédiates pour chaque utilisation de x[i] ou de y.

Mais puisqu'il s'agit d'un calcul fait par le compilateur, il
faut évidemment que les contraintes soient constante, et connues
lors de la compilation.

S'il s'agit des utilisateurs externes, en revanche, il lui
faut un parseur.)

l'idée qui me gêne ici et que "l'outil" cherché serait le
moyen d'écrire du script (et non du code!); il y a une nuance
entre les 2.

S'il lui faut un langage de script, il lui faut un langage de
script. Pour l'instant, je ne sais pas assez ce qu'il veut faire
réelement pour prononcer.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Equations/contraintes

10 réponses

Veuillez sélectionner un problème