Re: [Lib2geom-devel] Mandatory path stitching

[Johan E. <jbc...@sw...>]

Stitching, i.e. adding segments, is not a good solution to floating 
point rounding problems. IIRC, most of 2geom explicitly sets end-points 
to the same value, solving rounding problems. You have to push 2geom 
pretty hard to have it generate non-continuous paths. When adding little 
segments to paths that generate discontinuities for some operations, I 
think the problem only escalates.
(Side point: from what I remember, many of the non-continuity exceptions 
arise because of user code pushing NaN points to the path. That's not 
going be solved by stitching.)

In any case, I am simply giving my input having used 2geom a lot in 
Inkscape, but I don't expect to be writing code with/for it in the near 
future.
I don't see why stitching should be implied default behavior. Stitching 
is useful, but isn't it really just a hack? My course of action would be 
to remove the default Stitching value for all functions that take a 
Stitching argument.

- Johan


On 29-3-2015 0:25, Nathan Hurst wrote:
> It's not sloppy code, it's inescapable floating point rounding.
>
> njh
>
> On Sat, Mar 28, 2015 at 10:29:07PM +0100, Johan Engelen wrote:
>> I understood what you wrote.
>> I argued that the default of allowing sloppy code is probably not a good
>> default.
>>
>> - Johan
>>
>>
>> On 28-3-2015 17:24, Krzysztof Kosiński wrote:
>>> A non-contiguous path is practically always an error, so it makes
>>> sense to either prevent it or report it as early as possible. Now the
>>> default behavior is to add those extra segments, which allows sloppily
>>> written code to function as expected, but you can call
>>> setStitchExceptions() to enable the throwing of exceptions whenever a
>>> stitch segment would be appended.
>>>
>>> Regards, Krzysztof
>>>
>>> 2015-03-28 13:09 GMT+01:00 Johan Engelen <jbc...@sw...>:
>>>> On 27-3-2015 20:48, Krzysztof Kosiński wrote:
>>>>> Every method that modifies a Path has an optional argument called
>>>>> "stitching" that determines whether additional segments are added to
>>>>> make the path continuous. By default, stitching is not used. If there
>>>>> are any discontinuities, calling some of Path will cause an exception
>>>>> to be thrown, which in most cases means a crash.
>>>>>
>>>>> I want to make stitching mandatory. Since in some cases you want to be
>>>>> sure that no stitching happens in your code, there will be an extra
>>>>> boolean member variable. When set to true, it will throw an exception
>>>>> whenever you try to insert a discontinuity into the path.
>>>>>
>>>>> Is everyone OK with this idea?
>>>> I am not so sure about this.
>>>> It may not be very helpful if 2geom automatically fixes "user errors",
>>>> leading to unexpected results. If you change the default behavior (from
>>>> not stitching to stitching), user code will suddenly behave different
>>>> perhaps without the user knowing (e.g. no compiler error).
>>>> How about making the _choice_ for stitching behavior mandatory?
>>>>
>>>> -Johan
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>>>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>>>> things parallel software development, from weekly thought leadership blogs to
>>>> news, videos, case studies, tutorials and more. Take a look and join the
>>>> conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> Lib2geom-devel mailing list
>>>> Lib...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for all
>> things parallel software development, from weekly thought leadership blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Lib2geom-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/lib2geom-devel
>