[Development] FP calculations and stability in Qt

[Konstantin Shegunov]

On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud <chgans at gmail.com>
wrote:

> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov <kshegunov at gmail.com>
> wrote:
> > Doesn't this imply it should be dropped as an API that we can rely on?
>
> No i don't think so, this is just an edge case. I solved it by
> changing the base unit of my graphics view, so that it doesn't have to
> manipulate tiny FP values.
> I remember reporting that, and AFAIR, an example was an arc in a
> QGraphicsPathItem rendered as as a polyline.
>

Okay, I'll bite. Let's take as an example the bugreport I mentioned, how
would such a transformation of units look like? It's not a loaded question,
I'm genuinely interested if I missed something because really I don't see
it. My point is that the actual calculation is done internally, so
restructuring the units isn't at all trivial, nor perhaps possible, on the
part of the user. If we can accept that we don't want to go through the
motions to make transformations at least correct in all cases, I'm fine
with that too, but we should then warn the user not to expect it from the
library.

I then turned on specialised library, Qt is a GUI toolkit, and is
> optimised for painting. Qt takes all opportunities to be fast and
> efficient in that context, and that includes being "mathematically"
> imprecised, painting is all about pixels at the end of the day.
>

Look, I'm not arguing we should aim for 1 epsilon precision, but there's
"imprecise" and then there's "blatantly wrong".

A pixel is a surface, everything is correct as long as the surface
> covered by the pixel contains the point.
>

Which it may not, is my argument. Numerical instability is the
disproportionate grow of the relative error. If you don't keep that error
in check then you (can) just get nonsense. I can, and will, accept that we
don't want the most precise algorithm out there, but at least we should
strive for one that's correct, shouldn't we?

What i was trying to say, is that all geometry operations performed by
> components coupled to QPainter are good enough (and very efficient)
> for painting, by are not usable for "scientific" calculation.
>

Define "good enough" please. Is "good enough" errors bound by the errors in
the input, is "good enough" errors that explode with some inputs, or
something else?

OT: By the way, as far as I can tell a LU with pivoting (O(n^3) complexity)
is approximately as efficient as the algorithm currently employed in the
mentioned bugreport. It has two major advantages in my view, however. One
is that it's rank-revealing, thus you can tell if there's linear dependency
with zero cost. Secondly, it's not reinventing a square wheel.


> QPainterPath is not called QPath, expecting to do precise geometry
> boolean set operations with it is a mistake.
>

To extend my argument from the previous paragraph(s):
How do you take the algebra out of the geometry? I get that the algebra can
go its merry way on its own (e.g. in science), but the geometry just
depends on the algebra. So if the algebra's wrong, the geometry can be all
over the place by simple logical implication, you can't tell if it's
correct or not.

Kind regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190513/aeec5b76/attachment.html>