[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