Nick Sabalausky wrote:
"Justin Johansson" <n...@spam.com> wrote in message
news:haavf1$2gs...@digitalmars.com...
It's a difficult challenge to get high performance, readable and
maintainable code out of complex number
intensive algorithms. Use of library types for complex numbers has, in
my experience been problematic.
Complex numbers should be first class value types I say.
There's been discussion before (I can't find it now, or remember the name
for it) of type systems that allow for proper handling of things like m/s
vs. m/(s*s) vs inch/min etc. I haven't actually worked with such a feature
or with complex/imaginary numbers in any actual code, so I can't be sure,
but I've been wondering if a type system like that would be an appropriate
(or even ideal) way to handle real/complex/imaginary numbers.
It better be. Complex numbers aren't that complicated of a notion.
What's lost in pulling them out of the language is the ability to define
literals. Now please name five remarkable complex literals.
The feature you're referring to is called dimensional analysis.
(I've also
been wondering if it might be a huge benefit for distinguishing between
strings that represent a filename vs file content vs file-extention-only vs
relative-path+filename, vs absolute-path-only, etc. I've been really wanting
a better way to handle that than just a variable naming convention.)
I don't quite think so. In fact I don't think so at all. Pathnames of
various flavors evolve quite a bit in many programs, and having to worry
about tracking their type throughout is too much aggravation to be
worthwhile. Last thing I'd want when manipulating pathnames would be a
sticker of a library slapping my wrist anytime I misuse one of its six
dedicated types.
Andrei
