my conclusion: speed is not the only key point.
I don't buy this, if that means: we don't have to care about speed. For
research, flexibility is good, but if it is at the cost of significantly
lower speed when doing simulations, than something's wrong.
The complex art of finding the good compromise...
I remember a few years ago when I was thinking about optimizing the code
a little bit (e.g. by replacing dynamic_casts by static_), I felt like
nobody was concerned about it. I'm glad to see it is a high priority now! :)
I'm sure keeping speed in mind should influence ANY stage of the
development. But still, Luc's statement was true to : speed is not the
ONLY key point.
Another key point, not always mentionned here, is the complexity of the
code for end-users. Currently in 3Sr, I estimate the average time of
students to be able to understand Yade's code between 6 and 12 months,
which is a lot (they are not experienced with c++ when they come - that
counts to).
I know how Yade compare with pfc on that point (pfc is not that easy to
use, and has a crap command langage called "fish", but still easier than
Yade). I don't know how it compares with esys and Lamms, but they were
invented - not here - by very smart guys, so they are probably way more
complex. ;)
Bruno
--
_______________
Chareyre Bruno
Maître de Conférences
Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : 33 4 56 52 86 21
Fax : 33 4 76 82 70 43
________________
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp
