Salut a tous, je voudrais faire une appli client/serveur pour effectuer des calculs sur des matrices en langage C.  
J'ai déja fais mes sockets de communication et j'arrive a echanger des messages mais j'aimerais des conseils pour envoyer et recevoir mes matrices.
 
Ma premiere idée était d'envoyer une premier message en indiquant le nombre de lignes et de colonnes et dans les messages suivant chaque ligne de la matrice(donc chaque ligne du tableau qui sera crée pour les calculs).
 
Voila j'attends vos idées.
Merci  a tous.

tu peux tout faire en un seul message dans un format fixe : [N][M][contenu] à toi de choisir si tu veux faire des échanges textes ou binaire. Si tes matrices sont grandes et que tu te fous de la portabilité, alors le format binaire est meilleur car sans doute plus compacte.

et plus facile à lire/écrire

Tu peux préciser le but de la chose ?
 
Si tu as vraiment besoin / envie de tout faire à la main (i.e. si le but de ton projet est de faire des échanges de matrices), fais comme dit Taz.
Sinon, si ton projet est plus global et que l'échange de messages n'est qu'une fonctionnalité (et pas une fin en soi), il vaudrait mieux utiliser des outils qui existent déjà, comme par exemple MPI.

en C# ca se fait tout seul, tu sérialises ton objet et hop, t'envoie le flux xml dans le toyo

osef

ben ca dépend, l'informatique doit etre un outil au service de l'homme, et pas le contraire

Lorsque la contrainte c'est "utilisation du langage C", conseiller au mec d'utiliser C# ça va l'aider énormément
"Ecrivez nous ce dont vous avez besoin, on vous expliquera comment vous en passer" © Coluche

Au passage, s'il fait du full xml, ca risque d'être efficace sur des grosses matrices...

j'ai pas vu que le langage C était absolument obligatoire. Où l'a t'il écrit dans son message

 
Il demande une réponse en langage C.
Bon sang, quand je demande l'itinéraire pour aller quelque part en voiture, c'est pas pour qu'on m'explique comment y aller en train hein

il le demande en C parce qu'il ne connait surement rien d'autres
 
Nous avons le devoir d'éclairer sa route et de l'évangéliser.

On pourrait peut-être attendre qu'il revienne et nous explique son problème, plutôt que de spéculer sur ce qu'il veut vraiment

je crois que vous l'avez fait fuir
 
sinon, euh... pour le coup du "ouin c'est mal le xml c'est torp gros beurk prout caca boudin"...
 
euh...
 
un bête smiley de ce genre : ça pèse 3389 octets.
 
c'est à dire, en XML, en prenant ce format :
 

 
=> On peut transporter une matrice d'environ 15x15 nombres pour le même poids, ce qui représente déjà une belle bestiole non ?
 
Que je sâche, le forum ne met pas 2 heures à charger chaque page. En clair, si son serveur est un serveur toute dernière génération, avec un modem 56k au cul, et qu'il demande une une rotation sur une telle matrice, le serveur va mettre plus de temps à calculer la matrice qu'à la transférer sur le réseau.
 
Enfin, ce que j'en dit
 
Sinon, je suis d'accord que le format binaire est une idée toute aussi bonne. Mais absolument pas vitale.

15 x 15, c'est tout petit pour une matrice
 

Euh, t'es sûr que c'est pas l'inverse que tu voulais dire ?
 
De manière générale en calcul parallèle, on essaie au maximum de diminuer les temps de communication (parce que c'est ça qui te plombe l'efficacité de la parallélisation). Donc transférer 3 x plus de données que nécessaire pour mettre des balises xml, c'est pas forcément recommandé pour ce type d'application. (d'un autre côté, vu qu'on sait toujours pas ce que smithofmatrix veut, c'est effectivement pas dit que le temps de communication soit crucial pour lui...)

MPI me parait tout indiquer comme l'as dit franceso

franceso > en fait, à la base, l'imagine que s'il veut utiliser un serveur qui ne fournis que des services de calculs mathématiques, c'est pour faire des calculs particulièrement complexes sur ses matrices. je suppose donc que le temps nécessaire pour effectuer ces calculs est plus long que celui nécessaire au transfert des informations. ce serait pour constituer un datawarehouse ou un serveurs gérant la répartition des tâches entre serveurs, je suis d'accord que là, la vitesse de transmissions des informations est critique.
dans son cas, j'imagine ça comme faire un serveur de raytracing. genre t'envoie un scène de 200 ko, et il met 5 heures à pondre une frame d'animation. la scène pourrait faire 200 Mo, ça changerait "rien" au temps de traîtement.

Si les matrices sont grosses et utiles, il y a 9 chances sur 10 qu'elles soient creuses (>95% de zéro), et donc fortement compressibles.

ouais ben pour le coup, si c'est pour passer autant de temps à compresser/décompresser qu'à transmètre, je vois pas plus l'intérêt
 
(vivi, je suis très chiant )

A noter enfin qu'une trame IP sur internet, c'est 1000 octets, et 1500 pour une trame ethernet.
Quand on sait que la compression d'une donnée relativement petite (je vois pas trop une matrice de 1 Mo) est généralement faible (la taille des informations de décompression est significative par rapport au volume de données compressées), on peut aisément supposer qu'il y a de très faibles chances pour que la compression apporte un gain substanciel en ce qui concerne le nombre de trames. Et vu que les trames s'écoulent sur un réseau à vitesse constante, à nombre égal, quelque soit la taille des trames, on aura la même charge du réseau.
 
Bref, je ne suis clairement pas convaincu par la compression. Une représentation binaire de la matrice telle que proposé par Taz dès le début me semble donc tout particulièrement bien adaptée.

Une représentation RLE, ou liste de liste sur une matrice fortement creuse rapportera beaucoup, et si elle corresponds déja à celle en mémoire du serveur pour les calculs (ce qui arrive assez souvent), le coût de décompression est assez faible.

D'accord avec ça !
 
En fait, on en revient toujours au même problème : on en saura plus quand smithofmatrix sera revenu (mais j'ai l'impression qu'il n'est plus là )

Bonjour a tous merci pour toutes vos réponses. Je suis désolé de ne pas avoir pu revenir avant consulter mon topic.
Alors je vais completer mon post et répondre a vos interrogation
 
- je le fais en C non pas parce que je ne connait que ce langage, j'en connais d'autres mais c'est un projet scolaire et je suis obligé de la faire en C.
- L'appli devra faire des sommes, des produits et des transposée de matrice.
- Elle doit etre en C avec utilisation des primitives sockets avec envoie de chaines de caractéres donc pas de xml ou autre.
- Calcul en mode connecté TCP.
- Gestion des erreurs.
 
VOila je pense avoir données plus de precision.
 
J'ai un peu avancé dans mon projet : donc le client envoie un message en indiquand si il veut bosser sur une ou deux matrices auquel le serveur renvoie un acquitement. Le client indique ensuite l'opération a efectuer (somme ou produit si il a saisit "deux matrices" ) le serveur renvoie un acquitement.
 
Viens ensuite la saisie du nombre de ligne et de colonnes puis l'envoi des valeurs saisie dans une chaine de caractères. Chaque valeur est séparé par un caractère precis (slash, point virgule, pipe ....).
 
Voila je pense avoir répondu a vos question si vous avez de meilleures idées je veux bien.
MErci a tous

up

Des données fortement répétitives sont non seulement faciles à (dé)compresser, mais l'opération est très rapide. Typiquement, des logs d'un programme se compressent très bien.

On doit même arriver à les compresser en 1 bit.

On peut aussi pour faires des économies de taille, indiquer si c'est une matrice complete, dans ce cas on la décrit, ou alors si c'est une triangulaire, si oui quel type, on la décrit ( 45% gagnés ) si c'est une matrice diagonale, si oui quel quadran, on la décrit ( 85% gagnés ). Quitte a créer un dictionnaire dynamique de matrices usuelles... genre, le serveur se rend compte qu'on lui envoie souvent la meme matrice, il la sauvegarde qqpart, lui donne un ID, et informe régulièrement ses clients des nouvelles matrices connues... gain quasiment 95% mais chaud a implémenter, et couteux en terme de temps d'exec, stockage des matrices usuelles, etc... Ou sur le meme principe, créer un dico de matrices archi-usuelles, et permettre a un client de prévenir le serveur que la matrice qu'il va envoyer sera réutilisée, a voir.

Cdt

 
Si c'est pour du raytracing, les matrices-outils sont souvent les memes. L'idée du dictionnaire de matrices fixe prendrait alors tout son sens.