[Development] Proposing reversal of the Math3D qreal->float change

Sean Harmer sean.harmer at kdab.com
Tue Sep 11 23:43:01 CEST 2012


On 11/09/2012 14:08, Thiago Macieira wrote:
> On terça-feira, 11 de setembro de 2012 12.46.56, marco.bubke at nokia.com 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



More information about the Development mailing list