octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoc 2016: Final Reviews required


From: PhilipNienhuis
Subject: Re: GSoc 2016: Final Reviews required
Date: Sun, 21 Aug 2016 02:35:32 -0700 (PDT)

PhilipNienhuis wrote
> 
> John Swensen-3 wrote
>> 
>> <snip>
>> I think we still need to make another tweak to the makefile.in. The only
>> feature of the polygons that is version dependent is the
>> self-intersection correction (they call it the “dissolve” algorithm).
>> Everything else should work as-is. The dissolve function is currently in
>> the development repositories, but not in the releases. I was under the
>> impression that the 1.60 dissolve worked for both 1.60 and 1.61, but I
>> guess that isn’t the case. 
>> 
>> There should be two scenarios, though both should work with different
>> levels of functionality:
>> 
>> 1) all functions should work without self-intersection correction for
>> Boost.Geometry > 1.57
>> 2) all functions should work with self-intersection correction for
>> Boost.Geometry > 1.60
>> 
>> I will take a quick look and help Amr figure out why it isn’t doing the
>> conditional compile of the self-intersection correction.
> The crash with poly2fv in case of boost 1.61 (see my earlier reply) also
> needs some attention.
> If that is due to erroneous input in turn due to polybool yielding
> erroneous output due to whatever, it indicates that poly2fv needs more
> robust error checking and/or more robust error catching. Crashes just
> should not happen.
> Admittedly I could have compared polybool's output for both boost versions
> I tried (1.61 and 1.60) but that didn't occur to me at the time :-(
> If that crash is more directly related to boost version 1.61 (i.e., if
> poly2fv depends on the boost library as well) that would be a more serious
> issue.

I compared the polybool output from the last item of the second example on
Mathworks polybool web page
(http://nl.mathworks.com/help/map/ref/polybool.html) for both polybool built
with boost-1.60 and with boost-1.61. See attached .mat file.

Indeed the output cell arrays are quite different.

Feeding the Fx, Fy arrays from polybool/boost 1.60 to poly2fv in a geometry
package built with boost 1.61 gives a nice plot and no crash.
So that confirms my thinking:

- Ideally, polybool should (IMO) be able to be built and operate properly
with boost <= 1.60 and boost >= 1.61
As boost.geometry currently is at 1.61, my suggestion would be to require
boost 1.61 as minimum version, but that would require additional work on
polybool()

- poly2fv should merely have more robust error checking & error catching
(exception handling). E.g.,

>> poly2fv ('a', struct ("b", 3))
error: invalid conversion from string to real N-D array
>> poly2fv (9, struct ("b", 3))
error: octave_base_value::array_value(): wrong type argument 'scalar struct'


JuanPi, how would  you like development to proceed further?
Amr has finished his work but polishing the code for error checks etc. is
still required. Such (input) error checks do not look very difficult and can
be copied from other code in octave. 
The error catching (= avoiding crashes) is probably more challenging.

Philip

polbl_ML_2nd-ex.mat
<http://octave.1599824.n4.nabble.com/file/n4679373/polbl_ML_2nd-ex.mat>  





--
View this message in context: 
http://octave.1599824.n4.nabble.com/GSoc-2016-Final-Reviews-required-tp4679299p4679373.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]