[Development] FP calculations and stability in Qt

[Konstantin Ritt]

Writing and proposing a patch would take less time than discussing pros and
cons here.


Konstantin

пн, 13 мая 2019 г., 12:31 Konstantin Shegunov <kshegunov at gmail.com>:

> 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190513/0363757e/attachment.html>