
<html><head></head><body><br><br><div class="gmail_quote">On 6 October 2018 06:00:11 GMT+02:00, "Darafei "Komяpa" Praliaskouski" <me@komzpa.net> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My idea is about solving the second part, and I don't know how it will<br>

affect the overall compression.<br>...<br>

<br>

Any thoughts?<br><br></blockquote><div><br></div><div>I see a problem with this approach: what is the actual operation that is going to get benefit from it?</div><div><br></div><div>If we're making the format coordinate-number-addressable, then we need to utilize that. It means writing two versions of functions that operate on it, on "compressed" and "uncompressed" representation. The number of functions that will not require a complete scan over geometry is also pretty small - just StartPoint / EndPoint / PointN?</div></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>

</blockquote></div><br>

<br>

Yes , I agree it is just a small number of functions that can benefit from that. But it has been an argument. Wouldn't it be enough to make the that iterates pointarray and returns points aware about dynamic length? <br>

<br>

Ah, you are right, we use a pointer directly into the point array sometimes. That will affect many functions. My thought was that we anyway put the value in a double on the stack. But that is not true.<br>

<br>

/Nicklas<br>

<br>

<br>

<br>

<br>

<br>

Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>