| [eigen] Re: tvmet: licensing question for a project based on tvmet source code |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
Hello Olaf,
Many thanks for your reply!
I am currently at a math conference, so I might take a long time to reply
to e-mail.
On Mon, 11 Jun 2007, Olaf Petzold wrote:
not fully wrong ;-) Developing has reached an end, that's right. This is
due to changes of my life concerning profession (now I have a PhD by
performing an active magnetic bearing) and family (my Son 1 years old
needs a lot of time).
Congratulations!
I'm interested in seeing the progress of your project, my contributions
would be very small due to the lack of time. Projects I would write
about some weeks earlier would need some month now ;-) This is a spare
time project!
Anyway, if problems will occur I like to help.
I´ll do my best to not waste your time ;)
yes, there could be an overflow on higher float values, e.g. near
FLOAT_MAX. blitz++, ublas and others use this!
[SNIP]
Maybe the user should decide by using an additional template parameter.
But beware, not all user know what they have to expect and to code ;-)
Overflows would result into heavily locatable bugs!
I see, so we have a dilemma between resistance against programming
mistakes, and performance. The philosophy of Eigen is to prefer
performance and simplicity over complicated safety mechanisms, so I´ll
remove this. I understand that different libraries may make different
design decisions.
char,short and unsigned types is used in embedded area, where tvmet used
prior (see stdint.h typedefs).
I see. Interesting; I think I remove them for now, and anyway there always
remains the original tvmet code to copy from in case this turns out to be
needed.
long long and long double should be
discarded. There are big number libraries ...
My thoughts exactly :)
using int could result into bugs again, e.g. the user wrote complicated
loops ... unsigned/size_t is used in STL code too for this reason. At
this time, you have to explicit cast from -1 to unsigned to make a bug
with negative ranges/borders. Anyway, how would you interpret an
negative range? An check could be performed only at runtime ...
Yes, but that can be put in an assert, so when performance matters the
packager defines NDEBUG and the check goes away. Even though the check is
at runtime, well-written code must never make that assert fail, whatever
the input data is. For instance, a well-implement matrix algorithm never
looks at row -1 ... so such errors can be catched by asserts.
On the other hand, if we use unsigned types, theoretically we can´t check
at all for positivity. Of course, in practice, zith tiny vectors, negative
numbers give such huge positive values that they are rejected as being
above the boundary; but now with sparse vectors having more than 2 billion
rows this fails...
Unsigned can also give strange bugs with code like
for( n = size-1; n >= 0; n-- ) { ... }
If n is unsigned, normally the compiler will complain about the infinite
loop, but I have seen cases where it didn´t and that took me a very long
time to debug....
So I think, unsigned types are only useful for low-level programming, or
as bitfields.
I know that the standard C++ library uses unsigned types, and I disagree
with them ;) not just with you ;)
Hope the answers will help you! BTW, for this letter I wrote about 1,5
hours ;-)
These answers were very useful, thanks !
I´m sorry it took you so long, but at least from my point of view it was
worth it!
Benoit