On 11/09/2012 14:08, Thiago Macieira wrote: > On terça-feira, 11 de setembro de 2012 12.46.56, [email protected] wrote: >> But than we would be not have the same behaviour, if qreal is float or >> double. Actually I changed every code in the qml designer explicitly to >> double or float. It would be really nice, if the Qt classes would be has a >> float and a double implementation. From my perspective qreal is breaking >> the cross plattform promise!
I agree. qreal should be avoided if you care for the error characteristics of your algorithms. > We discussed changing qreal to either of the types and we did not come to a > conclusion. The best solution would be to provide the complex types in both > formats and let the API decide which one is more suitable. For example, > QtLocation would prefer to have double precision, but the OpenGL-related > functionality might be satisfied with single precision. Indeed, and QtLocation have in fact introduced their own double-precision equivalents for that purpose. Yes it would be nice to also have such classes in QtGui (or even QtCore but that is another dicsussion). > But doing that was source-incompatible. > > So we didn't change qreal. We only changed the Math3D classes, apparently > because they're used with OpenGL only. Usage with OpenGL is the intent of the math3d classes. Prior the change in question QOpenGLShaderProgram was even iterating over the contents of QMatrix4x4 and converting them to floats before passing them over as uniform variables to the shader program since OpenGL does not support doubles (at least until very recent versions of OpenGL) If it is decided that the math3d classes should be of use to more than OpenGL, then yes it would be good to see double-precision versions of these classes present too. If not then that is also fine as there are alternatives available (e.g. Eigen) which might be more suitable for serious number crunching anyway. > > The only problem is that no one had ever tested them with single precision > while qreal is double, or in a platform where unit tests are run. > Yes. So now we are seeing all those issues that have been invisible in Qt until now. As mentioned in my previous mail, I would strongly suggest fixing the issues rather than re-introducing the fundamentally broken API. Cheers, Sean _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
