|
Boost : |
From: Pavol Droba (droba_at_[hidden])
Date: 2004-06-04 13:00:33
Hi,
On Fri, Jun 04, 2004 at 11:01:38AM -0500, David B. Held wrote:
> "Mattias Flodin" <flodin_at_[hidden]> wrote in message
> news:1086354003.5749.68.camel_at_katran...
[snip]
> You might. But if you're buying 100 hours of time on a supercomputer
> at $100/hr. (not sure what going rates are), 10% could mean the
> difference between $10,000 and $9,000. If we're talking $1,000/hr.
> or many more hours (like a month), then the absolute savings is
> obviously much greater. If we aren't targeting the high-end
> computing market, then perhaps this is all irrelevant. But if you want
> the best mathematicians in the world to take these libraries seriously,
> then perhaps we do want to target the high-performance computing
> market.
>
I have followed the discussion here for a while. I think, that the reasoning
here is missing one important point.
If the mathematical library will be implemented somehow, it will not be
used solely by mathematicians. There is a lot of application software out there
that needs to do some math. Boost mathematical library would fill a very
important gasp. Since most of the programmers are not math scientist,
this library would provide a great help.
For a math scientist it does not realy matter which language to use for a particular
problem. On the other hand, an application programmer is often tied by strong
constraints since the math part is usualy only a small piece of whole.
I'm pretty sure that for such an application the slight decrease in performance
compared to fortran for example, would have marginal importance when compared
to simplicity of integration and usage.
So I think, that implementing a mathematical library in boost is very good idea.
Because of the reasons I stated, full C++ implementaion might be better than a
wrapper over some fortran libraries. Every mathematician have fortran installed,
but this is not true for an application programmers.
Thats my 0.5SKK
Regards,
Pavol
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk