Discussion:
wrapToPi function
Oscar
2015-12-07 23:37:59 UTC
Permalink
Hello,

I'd like to post my implementation of wrapToPi function. It is available in
Matlab but is still missing in Octave. I hope it will be included in a
future versions of octave or one of its toolboxes. For sure it can be
improved but I believe it is fast enough.

Regards,

Òscar

wrapToPi.cc <http://octave.1599824.n4.nabble.com/file/n4673887/wrapToPi.cc>





--
View this message in context: http://octave.1599824.n4.nabble.com/wrapToPi-function-tp4673887.html
Sent from the Octave - General mailing list archive at Nabble.com.
Mike Miller
2015-12-08 15:17:08 UTC
Permalink
Post by Oscar
Hello,
I'd like to post my implementation of wrapToPi function. It is available in
Matlab but is still missing in Octave. I hope it will be included in a
future versions of octave or one of its toolboxes. For sure it can be
improved but I believe it is fast enough.
Thanks for offering this function. The best way to contribute a new
function to Octave is to post it to the patch tracker

https://savannah.gnu.org/patch/?func=additem&group=octave

Please post the file there, as it will likely be lost and forgotten here
on the mailing list. Please also make a note that it should be added to
the Octave "mapping" package.
--
mike
Nicholas Jankowski
2015-12-08 17:15:55 UTC
Permalink
Post by Mike Miller
Post by Oscar
Hello,
I'd like to post my implementation of wrapToPi function. It is available in
Matlab but is still missing in Octave. I hope it will be included in a
future versions of octave or one of its toolboxes. For sure it can be
improved but I believe it is fast enough.
Thanks for offering this function. The best way to contribute a new
function to Octave is to post it to the patch tracker
https://savannah.gnu.org/patch/?func=additem&group=octave
Please post the file there, as it will likely be lost and forgotten here
on the mailing list. Please also make a note that it should be added to
the Octave "mapping" package.
2 silly questions:
1 - does anyone generally care about unicode, etc. character sets in
the source? I only ask because the O in Oscar renders quite
differently depending on my browser setting, and my default text
editor sees it as it's saved, which isn't with the accent. I'm
unfamiliar with whether there's a preferred set to use or if it
matters.

2 - Oscar, seems like there are 2 or three nearly identical functions
also not implemented:
wrapTo180, wrapTo2Pi, wrapToP360.

Those seems like minor changes to what you've written for wraptopi.
Would you be able to post those along with WrapToPi?

nickj
Mike Miller
2015-12-08 19:19:21 UTC
Permalink
Post by Nicholas Jankowski
1 - does anyone generally care about unicode, etc. character sets in
the source? I only ask because the O in Oscar renders quite
differently depending on my browser setting, and my default text
editor sees it as it's saved, which isn't with the accent. I'm
unfamiliar with whether there's a preferred set to use or if it
matters.
Files should be UTF-8 encoded (without BOM, and with Unix line endings
while we're at it). Òscar's file looks correct to me.
Post by Nicholas Jankowski
2 - Oscar, seems like there are 2 or three nearly identical functions
wrapTo180, wrapTo2Pi, wrapToP360.
Those seems like minor changes to what you've written for wraptopi.
Would you be able to post those along with WrapToPi?
I'd also ask if there is a performance reason for writing the function
in C++, m-files make for easier maintenance and installation.
--
mike
Oscar
2015-12-08 19:58:39 UTC
Permalink
Hi,

I've already upload the wrapToPi.m and wrapTo180.m to specified pataches
web.

Additinally, I've removed the accent from the "Ò"....

Finally, I was playing a little bit with the oct files but there is no much
performance advantage as the functions have only two code lines.

Regards,

Òscar



--
View this message in context: http://octave.1599824.n4.nabble.com/wrapToPi-function-tp4673887p4673930.html
Sent from the Octave - General mailing list archive at Nabble.com.
Nicholas Jankowski
2015-12-08 22:41:07 UTC
Permalink
Post by Oscar
Hi,
I've already upload the wrapToPi.m and wrapTo180.m to specified pataches
web.
Additinally, I've removed the accent from the "Ò"....
Finally, I was playing a little bit with the oct files but there is no much
performance advantage as the functions have only two code lines.
Regards,
Òscar
by all means, leave the Ò, as that's the correct spelling. The problem
is all over on my side.

I've been using SciTE since it was bundled with Octave way back when.
It's supposed to Autodetect UTF if it starts with a correct BOM. This
is the first time I've had it incorrectly autodetect unicode. Usually
Firefox on windows keeps autodetecting encoding to 'Western' no matter
how many times I try to set it otherwise. but I was surprised to see
it carry through to the editor.

Anyway,Mike, a side note: the Octave Windows gui editor
is set by default to EOL mode "Windows (CRLF)". Again, being
unfamiliar with the implications, will that cause problems for
contributed code? would just switching it to linux (LF) cause problems
for code I save/run locally?

sorry to derail the thread :)

nickj
Mike Miller
2015-12-09 14:35:06 UTC
Permalink
Post by Nicholas Jankowski
I've been using SciTE since it was bundled with Octave way back when.
It's supposed to Autodetect UTF if it starts with a correct BOM. This
is the first time I've had it incorrectly autodetect unicode. Usually
Firefox on windows keeps autodetecting encoding to 'Western' no matter
how many times I try to set it otherwise. but I was surprised to see
it carry through to the editor.
So does SciTE *not* detect UTF-8 properly if there is no BOM? Because
the BOM is typically discouraged, on non-Windows systems at least.
Post by Nicholas Jankowski
Anyway,Mike, a side note: the Octave Windows gui editor
is set by default to EOL mode "Windows (CRLF)". Again, being
unfamiliar with the implications, will that cause problems for
contributed code? would just switching it to linux (LF) cause problems
for code I save/run locally?
It's easy enough to run fromdos on my end if I get a patch in CRLF
format. Working in LF format should not cause any problems for you (only
Notepad has a problem with LF files I think), and will make your work
more compatible with the majority of us devs ;)
Post by Nicholas Jankowski
sorry to derail the thread :)
No problem, renamed sub-thread.
--
mike
Nicholas Jankowski
2015-12-09 15:20:23 UTC
Permalink
Post by Mike Miller
Post by Nicholas Jankowski
I've been using SciTE since it was bundled with Octave way back when.
It's supposed to Autodetect UTF if it starts with a correct BOM. This
is the first time I've had it incorrectly autodetect unicode. Usually
Firefox on windows keeps autodetecting encoding to 'Western' no matter
how many times I try to set it otherwise. but I was surprised to see
it carry through to the editor.
So does SciTE *not* detect UTF-8 properly if there is no BOM? Because
the BOM is typically discouraged, on non-Windows systems at least.
Apparently not. I forced it to UTF and it displayed fine. According to
the documentation: "SciTE will automatically detect the encoding
scheme used for Unicode files that start with a Byte Order Mark
(BOM)..." Just to check I resaved his original file with 'UTF8 with
BOM' selected, and now it detects just fine in both SciTE and Firefox.
*shrug*
Post by Mike Miller
Post by Nicholas Jankowski
Anyway,Mike, a side note: the Octave Windows gui editor
is set by default to EOL mode "Windows (CRLF)". Again, being
unfamiliar with the implications, will that cause problems for
contributed code? would just switching it to linux (LF) cause problems
for code I save/run locally?
It's easy enough to run fromdos on my end if I get a patch in CRLF
format. Working in LF format should not cause any problems for you (only
Notepad has a problem with LF files I think), and will make your work
more compatible with the majority of us devs ;)
Worth changing the default option in the editor for the next build?
Mike Miller
2015-12-09 16:55:49 UTC
Permalink
Post by Nicholas Jankowski
Post by Mike Miller
So does SciTE *not* detect UTF-8 properly if there is no BOM? Because
the BOM is typically discouraged, on non-Windows systems at least.
Apparently not. I forced it to UTF and it displayed fine. According to
the documentation: "SciTE will automatically detect the encoding
scheme used for Unicode files that start with a Byte Order Mark
(BOM)..." Just to check I resaved his original file with 'UTF8 with
BOM' selected, and now it detects just fine in both SciTE and Firefox.
*shrug*
Same *shrug* here. I just know the BOM shows up as garbage in my editor
of choice, and I'll delete it when reviewing files and patches.
Post by Nicholas Jankowski
Post by Mike Miller
It's easy enough to run fromdos on my end if I get a patch in CRLF
format. Working in LF format should not cause any problems for you (only
Notepad has a problem with LF files I think), and will make your work
more compatible with the majority of us devs ;)
Worth changing the default option in the editor for the next build?
A quick search shows me this has already been discussed pretty
thoroughly in bug #43334, it will probably stay a preference as it is
with the default dependent on the OS.
--
mike
Loading...