Wed 10 Jun 2015 01:29:24 PM UTC, comment #14:
I added some trivial tests on stable to ensure this keeps working:
http://hg.savannah.gnu.org/hgweb/octave/rev/7ab81a9fa065
|
Tue 09 Jun 2015 11:42:07 PM UTC, comment #13:
Thanks for addressing this issue.
|
Tue 09 Jun 2015 11:36:55 PM UTC, comment #12:
I added a changelog comment and checked in jwe's patch on the stable branch (http://hg.savannah.gnu.org/hgweb/octave/rev/7fa170cc14fe). This will be a part of the 4.0.1 bug fix release.
|
Tue 09 Jun 2015 11:42:03 AM UTC, comment #11:
jwe wins by default, right? :)
It was because my solution adds troublesome special case code that I posted the patch here for comment. As I mentioned to jwe on irc, my first attempt was to try to return true from the ok_for_*_int_conv functions, and I ran into the invalid conversion error. I agree his patch is a cleaner solution.
|
Mon 08 Jun 2015 10:45:09 PM UTC, comment #10:
I doubt there would be much of a difference in performance. It just seems better to me to add value extractors rather than more logic in the printf function.
|
Mon 08 Jun 2015 09:56:18 PM UTC, comment #9:
jwe's patch also works for me.
Is there some additional criteria such as performance that can be used to distinguish which patch to implement?
|
Mon 08 Jun 2015 07:09:36 PM UTC, comment #8:
Here's another possible way to fix this problem that doesn't add yet another special case to the do_numeric_printf_conv function.
(file #34181)
|
Mon 08 Jun 2015 06:48:38 PM UTC, comment #7:
@Mike: I have also rebuilt with your patch and it fixed the problem for me.
Any estimate on when the next dot release would happen?
Thanks!
|
Mon 08 Jun 2015 06:06:18 PM UTC, comment #6:
@Mike: The patch works for me. Maybe you want to check with jwe since he was the one changing a lot of the printf code for greater Matlab compatibility?
|
Sun 07 Jun 2015 03:47:06 PM UTC, comment #5:
I have a patch for this, see attached. Not sure if it's the cleanest way this could be done, but adds special handling for char array arguments to printf functions to make sure the characters are converted to equivalent integral values properly.
I think this qualifies for a stable update for the next point release, marking as a regression.
(file #34171)
|
Sun 07 Jun 2015 02:01:24 PM UTC, comment #4:
On MATLAB Version 7.11.0.584 (R2010b) all of them are 40
|
Sat 06 Jun 2015 02:38:05 PM UTC, comment #3:
There were several fixes to the printf family of functions for 4.0, so it's entirely possible that some regressions for weird cases like this unintentionally slipped in as well.
Can someone confirm in Matlab what the output is for
|
Sat 06 Jun 2015 10:13:09 AM UTC, comment #2:
31 Hex = 49 dec.
|
Sat 06 Jun 2015 04:04:31 AM UTC, comment #1:
The same error happens with %x as well. I have tested this with Octave 4.0.0 built from source on a Ubuntu 14.04 64bit system and see the same behavior that Tom reports, so it is not specific to the Windows implementation.
Here are my results showing the difference between 3.8.1 (installed from the Ubuntu distro) versus the 4.0.0 built from source:
Here is what happens on 3.8.1:
>> s = "123"
s = 123
>> sprintf("%X", s(1))
ans = 31
>> sprintf("%x", s(1))
ans = 31
>> version
ans = 3.8.1
>>
Now try this on 4.0.0:
octave:96> s = "123"
s = 123
octave:97> sprintf("%X", s(1))
ans = 49
octave:98> sprintf("%x", s(1))
ans = 49
octave:99> version
ans = 4.0.0
octave:100>
|
Sat 06 Jun 2015 03:35:52 AM UTC, original submission:
Try this, see if it makes sense to you:
str = '3'
printf('%X',char(str(1)))
Prints the result 51.
It should be 33 (that's what it is in Octave 3.8.2 and 3.2.4)
Happens in both Win7 and Win8.1.
|