On Jan 9, 2013, at 5:54 AM, Olivier Goffart wrote: > On Friday 28 December 2012 08:36:21 Glen Mabey wrote: >> Hello, >> >> For some time, I have been working on a QtCore-based class that would be a >> container class of arbitrary dimensionality. I did give a presentation on >> this topic at DevDays-CA: > > Just my personal opinion on this: > > I do not think this class should be included in QtCore or even in a any > module > of Qt base. > > I think this is out of the scope of Qt. I do not see that many uses case for > normal Qt applications.
I am not surprised that some developers would feel this way, and I think I would also feel that way if Qt were still strictly a GUI toolkit, instead of the application framework that it became in Qt4. I'm sure that most Qt developers work strictly with GUI applications, and I *think* that [at least part of] the intent in separating QtCore from QtGui with 4.0 was to broaden the type of apps that make use of Qt. A majority of the programs that I have written in the last 4 years have been QT-=gui. (As a side note, the graphical apps I have written have mostly been to represent the large, multi-dimensional data sets that were generated by the console Qt apps.) The introduction of QNDArray is an effort to broaden the base in a new dimension. However, I am also not surprised if many developers have not felt a loss at the lack of a multi-dimensional container class in Qt, like "oh I've always wanted that type of functionality" -- I would only expect you (that is, you as a subscriber to development@qt-project.org) to have that opinion if you did scientific computing. In fact, I hope that Qt will appeal to a new demographic of programmers because of QNDArray (those who are *not* currently subscribed to development@qt-project.org). > Perhaps it would be a better fit in a library that does numeric calculus. So, I agree that too much *could* be put into QNDArray, and *that* would be inappropriate for the Qt project, in my mostly-outsider opinion. But I'm not proposing that the kitchen sink be put in, only the container class itself, and a few very basic mathematical operations like sin, cos, exp. In fact, I probably should have down-sized the number of functions that were included in the QNDAMath namespace before I pushed. I am proposing what Charley referred to as a common (or in other words, universal among Qt apps) "representation format". I think that the phrase "interchange class" might be more appropriate, but the concept is the same: have a single C++ class that all other libraries can not only use internally but also use to exchange data with other libraries. Like, for example, one library that computes an FFT and another that plots the result, like maybe QtCharts. That is the case I was trying to make in the Dev-Days presentation: there are *many* projects which build on Numpy but all use it for holding data and communicating data to other libraries. There was quite a period of time in which there were competing modules in the Python world that aimed to fill that roll (numeric and numarray), and in the end, one developer took the best ideas from each and produced Numpy, and in doing so was able to unify the entire community and hence propel forward what is now an extremely strong and active group of developers for scientific computing using Python. I might not need numeric calculus in my work today, but if someone else does implement that functionality using QNDArray and makes it available, then it will be a lot easier for me to interface to your 3rd-party library. I hope that helps clarify the intent. Glen P.S. There are two cases that are considered very significant in the Numpy world that I have not dealt with in QNDArray (yet): masked arrays and sparse arrays. These cases would probably need to be addressed in order to have a truly universal, multi-dimensional container class. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
