<div dir="ltr"><div dir="ltr">On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud <<a href="mailto:chgans@gmail.com">chgans@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 May 2019 at 07:47, Konstantin Shegunov <<a href="mailto:kshegunov@gmail.com" target="_blank">kshegunov@gmail.com</a>> wrote:<br>
> Doesn't this imply it should be dropped as an API that we can rely on?<br>
<br>
No i don't think so, this is just an edge case. I solved it by<br>
changing the base unit of my graphics view, so that it doesn't have to<br>
manipulate tiny FP values.<br>
I remember reporting that, and AFAIR, an example was an arc in a<br>
QGraphicsPathItem rendered as as a polyline.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I then turned on specialised library, Qt is a GUI toolkit, and is<br>optimised for painting. Qt takes all opportunities to be fast and<br>efficient in that context, and that includes being "mathematically"<br>imprecised, painting is all about pixels at the end of the day.<br></blockquote><div><br>Look, I'm not arguing we should aim for 1 epsilon precision, but there's "imprecise" and then there's "blatantly wrong".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A pixel is a surface, everything is correct as long as the surface<br>
covered by the pixel contains the point.<br></blockquote><div><br>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? <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What i was trying to say, is that all geometry operations performed by<br>
components coupled to QPainter are good enough (and very efficient)<br>
for painting, by are not usable for "scientific" calculation.<br></blockquote><div><br>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?<br><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
QPainterPath is not called QPath, expecting to do precise geometry<br>
boolean set operations with it is a mistake.<br></blockquote><div><br></div><div>To extend my argument from the previous paragraph(s):<br>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.<br> <br>Kind regards.</div></div></div>