[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).


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!
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!


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/