lecrabe Posté(e) le 5 juillet 2013 Posté(e) le 5 juillet 2013 Hello Je tiens a signaler ces tests fort interessants : http://www.capcpo.com/index.php?lang=fr&which=assoc_matrice Merci a l'auteur ! ;; Benjamin L.G. Torno - Contact{à}capcpo.com lecrabe Autodesk Expert Elite Team
ZWCAD-France Posté(e) le 19 juillet 2013 Posté(e) le 19 juillet 2013 Bonjour, oui, je confirme, Benjamin Torno est un développeur LISP de haut vol qui a également écrit un livre sur le B.A. BA du LISP (en vente sur son site), et nous en faisons aussi la promo sur notre site (zwcad). Il confirme que derriere AutoCad, Bricscad et ZWCAD sont aujourd'hui plus que crédibles. En terme de performances pures, BricsCad est très rapide, mais la différence est parfois minime ( 10^-5 s !!) mais sur des gros traitement ça peut jouer (mais rarement).Je précise que la plupart des LISP de (Gile), Patrick_35 dispo sur CadXp passent sans problème sur un ZWCAD de base y compris les Vlax et autres. Du coup, AutoFluide (écrit surtout en Lisp) fonctionne depuis Mars sur Zwcad+ avec la même interface qu'AutoCad ( ce n'est pas trop le cas de BrisCad) Coté ZWCAD (là je prêche pour ma chapelle !) nous insistons aussi sur la fiabilité, la similitude de l'interface et le suivit local avec la HotLine gratuite illimitée. Coté développement, nous disposons désormais surtout du .Net et nous attendons d'ici qq mois des applis complètes qui ne marchaient que sur AutoCad. Cordialement Patrick MiaultZW FranceDistributeur exclusif de ZWCADwww.zw-cad.fr ZW France est le distributeur de ZWCAD, ZW3D et ARCHLine en France, Belgique francophone, Suisse francophone, et Afrique francophone. www.zwfrance.fr
(gile) Posté(e) le 19 juillet 2013 Posté(e) le 19 juillet 2013 Salut, Sans entrer dans les détails pour savoir si tel logiciel est plus rapide qu'un autre, les différences sont minimes, ce que je trouve intéressant dans cet article, c'est qu'il illustre bien ce qui est, à mon avis le principal défaut d'AutoLISP (langage que je trouve génial par ailleurs). La liste chaînée immuable, chère aux langages fonctionnels, est la seule structure de données existante en pur AutoLISP. Ce type de collection n'est efficient que pour l'accès depuis la tête de la liste à cause du chaînage et toute modification d'un élément dans une liste (avec subst par exemple) entraine la création d'une nouvelle liste, du moins depuis la tête jusqu'à l'élément modifié (le lien vers la queue est réutilisé) du fait de l'immuabilité. Les listes chaînées sont, par contre, tout à fait adaptées à la récursivité ainsi qu'aux représentations d'arborescences (listes de sous-listes). Les tableaux indexés, aux quels on peut accéder en Visual LISP via les objets safearray, sont des structures de tout autre nature. Chaque "case" d'un tableau fait référence à une cellule en mémoire. L'accès à la cellule par son indice (vlax-safearray-get-element) est direct (alors qu'un (nth n lst) parcourt les n éléments depuis la tête pour accéder au n-ième élément).La modification d'un élément (vlax-safearray-put-element) n'affecte aucunement le reste du tableau.Les tableaux sont donc des collections bien plus efficaces que les listes en ce qui concerne l'accès et la modification d'éléments.Ceci est d'autant plus vrai que la collection est grande, bien sûr, mais est à relativiser avec les tableaux à plus d'une dimension.Mais, en LISP, les objets safearray sont moins commodes à construire / manipuler et nécessitent un code plus verbeux. Les tests concernant les "matrices" illustrent assez bien ceci. Sont comparés ici d'un côté un tableau à deux dimension, et de l'autre une liste de sous-listes, plus semblable à ce qu'on appelle un "tableau déchiqueté" (tableau à une dimension de tableaux à une dimension).Si l'accès et la modification d'éléments sera toujours plus rapide avec le tableau, pour les opérations de calcul matriciel (transposition, multiplication, ...) les listes de sous-listes AutoLISP sont efficaces puisqu'elles ramènent ces opérations à des opérations sur des listes (les sous-listes). Pour ces dernières opérations, l'avantage d'AutoLISP aurait été encore plus marqué, tant du point de vue de la concision du code que des performances, en utilisant les fonctions suivantes : ;; TRP ;; Transpose une matrice -Doug Wilson- ;; ;; Argument ;; m : une matrice (defun trp (m) (apply 'mapcar (cons 'list m))) ;; MXV ;; Applique une matrice de transformation à un vecteur -Vladimir Nesterovsky- ;; ;; Arguments ;; m : une matrice ;; v : un vecteur (defun mxv (m v) (mapcar (function (lambda (r) (apply '+ (mapcar '* r v)))) m)) ) ;; MXM ;; Multiplie (combine) deux matrices -Vladimir Nesterovsky- ;; ;; Arguments ;; m : une matrice ;; q : une matrice (defun mxm (m q) (mapcar (function (lambda (r) (mxv (trp q) r))) m) ) Gilles Chanteau - gileCAD - GitHub Développements sur mesure pour AutoCAD
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant