[Octave-patch-tracker] [patch #9953] [octave forge] (mapping) angl2str

[Philip Nienhuis]

Follow-up Comment #7, patch #9953 (project octave):

I started reviewing your angl2str in some more detail.

Can you explain why round.m needs to patched in the first place?
If possible I'd like to avoid having that patched round.m either in core or in
the mapping package for the following reasons:

*If in core Octave*
0 First of all the usual prudency arguments for changing anything in core; no
one knows what code Out There depends on current round.m functionality, let
alone some core Octave functions
0 The mapping package and core Octave have different release cycles
0 The mapping package should work with older Octave versions for a number of
years after they were released. So for older Octave versions a new mapping
package's anglstr wouldn't work
0 If in core it'll be released only next year (we hope), so until then the
mapping package can't use it
0 In short, we'd need a workaround anyway for the next years in the mapping
package itself.

*If in the mapping package*
* When loading the mapping package, its entire function directory is placed
before all of core Octave so mapping's round.m would shadow core Octave's
version. So there you go, back to point 1 above ...
* There may be other mapping package functions, if not other OF package
functions, affected by a change in round.m's functionality (I haven't looked
yet for the mapping package, for other OF packages I won't even attempt)

If your angl2str really needs an amended round.m it had better be a
subfunction of angl2str.m to avoid all above mentioned scoping issues. In
addition it rather be renamed to something like round_a or so to avoid any
risk of function name mix-up.

But maybe / hopefully there are other ways to get numbers rounded properly for
angl2str w/o invoking round.m at all. I'm all prepared to help sorting that
out but then I need to know exactly what kind of rounding you need for
angl2str.

The angl2str.m currently in the mapping package doesn't need round.m either
but apart from format & wrapping to [-180 180] its output seems to at least
"numerically" match Matlab's exactly.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9953>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/