

I found a problem with continuation lines on octave 6 and 7:
c = ['1 2 3 ', ...
'4 5 6']
c =
1 2 3
4 5 6
while in octave 5 I get the expected:
c = ['1 2 3 ', ...
'4 5 6']
c = 1 2 3 4 5 6
Is this known? Should I fill a bug report?
Yes, that looks like you found a bug. Could you file a report at
bugs.octave.org? That needs to be fixed before the 6.1 release.
Rik


On Wednesday, 19 February 2020 17.24.13 WET Rik wrote:
> Yes, that looks like you found a bug. Could you file a report at
> bugs.octave.org? That needs to be fixed before the 6.1 release.
BTW I got this because of the following snippet:
>> c = ['1 2 3 ', ...
'4 5 6']
c =
1 2 3
4 5 6
>> strrep(c, '2', '0')
ans = 14 05 36
This is confusing, to say the least. :)
The right result should be:
c = 1 2 3 4 5 6
ans = 1 0 3 4 5 6
Not that it matters much but in Matlab (according to the documentation and
asking a colleague to test it) we get and error if the first argument is not a
character vector.
Should I fill this as a Matlab compatibility issue or is this done on purpose?
Best regards,

José Matos

Administrator

Not that it matters much but in Matlab (according to the documentation and
asking a colleague to test it) we get and error if the first argument is not a
character vector.
Should I fill this as a Matlab compatibility issue or is this done on purpose?
I think the strrep function is fine. c is a char array. the bug about how the array is stored is changing the shape of the array. the substitution appears to be fine, if c was actually what you wanted (a two row char array). As stated in 'help char', Matlab/Octave concatenates char arrays vertically (are stored columnwise). so the stored order is 1 4 2 5 3 6. eg:
octave:13> a=char('test1','test2') a =
test1 test2
octave:14> a(1) ans = t octave:15> a(2) ans = t octave:16> a(:) ans =
t t e e s s t t 1 2


On Wednesday, 19 February 2020 20.01.12 WET Nicholas Jankowski wrote:
> I think the strrep function is fine. c is a char array. the bug about how
> the array is stored is changing the shape of the array. the substitution
> appears to be fine, if c was actually what you wanted (a two row char
> array). As stated in 'help char', Matlab/Octave concatenates char arrays
> vertically (are stored columnwise). so the stored order is 1 4 2 5 3 6. eg:
>
> octave:13> a=char('test1','test2')
> a =
>
> test1
> test2
>
> octave:14> a(1)
> ans = t
> octave:15> a(2)
> ans = t
> octave:16> a(:)
> ans =
>
> t
> t
> e
> e
> s
> s
> t
> t
> 1
> 2
I am aware of this as well of the other variant:
>> a(1:end)
ans = tteesstt12
What I was trying to understand is if this result is an expected outcome or if
it would be better to throw an error in this scenario (just like Matlab does).
The matrix of char is confusing and probably (and this is the degree of
certainty that I am trying to determine) the user wanted instead to use the
cell array version:
>> a = {'test1';'test2'}
>> strrep(a, 't', '')
ans =
{
[1,1] = es1
[2,1] = es2
}
and this works the same in Octave and Matlab.
Regards,

José Matos

Administrator

What I was trying to understand is if this result is an expected outcome or if
it would be better to throw an error in this scenario (just like Matlab does).
can you give a code example of what produces an error in matlab but not octave? i may be misunderstanding your earlier comments.


On Thursday, 20 February 2020 14.35.19 WET Nicholas Jankowski wrote:
> can you give a code example of what produces an error in matlab but not
> octave? i may be misunderstanding your earlier comments.
c = ['1 2 3 '; '4 5 6 ']
strrep(c, '2', '0')
The call to strrep fails in Matlab since c is not a char array and it succeeds
in Octave (with an antiintuitive result IMHO). My proposal is to do the same
in Octave.
[m,n] = size(c);
If m != 1 and n!= 1 then throw an error. I hope that this now makes sense. :)
Regards,

José Matos

Administrator

On Thu, Feb 20, 2020 at 11:51 AM José Abílio Matos < [hidden email]> wrote: On Thursday, 20 February 2020 14.35.19 WET Nicholas Jankowski wrote:
> can you give a code example of what produces an error in matlab but not
> octave? i may be misunderstanding your earlier comments.
c = ['1 2 3 '; '4 5 6 ']
strrep(c, '2', '0')
The call to strrep fails in Matlab since c is not a char array and it succeeds
in Octave (with an antiintuitive result IMHO). My proposal is to do the same
in Octave.
[m,n] = size(c);
If m != 1 and n!= 1 then throw an error. I hope that this now makes sense. :)
ok, it is a char array, so I was confused. testing in matlab 2019a: >> c = ['1 2 3';'4 5 6']
c =
2×5 char array
'1 2 3' '4 5 6'
>> strrep(c,'2','0') Error using strrep Char inputs must be row vectors.
so the problem isn't that it is or isn't a char array. the problem is that matlab only accepts character vectors. any arrays must either be string or cell arrays. (and Octave doesn't do strings yet).
It's generally not a bug for Octave to have capability that extends beyond Matlab, which is what appears to be the case here. multidimensional arrays are always stored columnwise (despite most of us reading rowwise), and that's no different here.
I see no reason to throw an error, unless you see lack of an error message causing some other problem?
The only possible issue is that it doesn't return the original shape. But then strrep doesn't require substituted strings preserve length, so there's no way it can preserve array shape by default.
e.g., octave:7> strrep(c,'2','0000') ans = 14 00005 36


On Thursday, 20 February 2020 17.10.07 WET Nicholas Jankowski wrote:
> so the problem isn't that it is or isn't a char array. the problem is that
> matlab only accepts character vectors. any arrays must either be string or
> cell arrays. (and Octave doesn't do strings yet).
You are right, I should have been more clear. :)
> It's generally not a bug for Octave to have capability that extends beyond
> Matlab, which is what appears to be the case here. multidimensional arrays
> are always stored columnwise (despite most of us reading rowwise), and
> that's no different here.
>
> I see no reason to throw an error, unless you see lack of an error message
> causing some other problem?
My main objection to this extension is semantic. The function is called
strrep. The help of that function says:
"""
 NEWSTR = strrep (STR, PTN, REP)
 NEWSTR = strrep (CELLSTR, PTN, REP)
 NEWSTR = strrep (..., "overlaps", VAL)
Replace all occurrences of the pattern PTN in the string STR with the string
REP and return the result.
"""
My objection is that an example like the one we have been using
c = ['1 2 3';'4 5 6']
where IMHO c is not a string. I called it an array of chars to distinguish
from a vector of chars.
So if the input is wrong the usual procedure is to throw an error.
OTOH probably this is a fringe case not worth the time we are spending. :)
The goal of my original message on this subthread was to understand if this
is worth pursuing or not.
Thank you for your feedback. :)

José Matos

Administrator

is extension is semantic. The function is called
strrep. The help of that function says:
"""
 NEWSTR = strrep (STR, PTN, REP)
 NEWSTR = strrep (CELLSTR, PTN, REP)
 NEWSTR = strrep (..., "overlaps", VAL)
Replace all occurrences of the pattern PTN in the string STR with the string
REP and return the result.
"""
My objection is that an example like the one we have been using
c = ['1 2 3';'4 5 6']
where IMHO c is not a string. I called it an array of chars to distinguish
from a vector of chars.
so, one point here, these aren't strings. (strings didn't exist, i don't even think cell arrays existed, when this function was made). i don't know if this matlab's behavior changed over time with cell arrays and strings. But, allowing char arrays does produce odd results:
in addition to the case above:
octave:5> c = ['1 2 3 4 5 6'] c = 1 2 3 4 5 6
octave:6> strrep(c,'1 2', '6 7') ans = 6 7 3 4 5 6
octave:7> c = ['1 2 3';'4 5 6'] c =
1 2 3 4 5 6
octave:8> strrep(c,'1 2', '6 7') ans =
1 2 3 4 5 6
octave:9> strrep(c,'14', '67') ans = 67 25 36
so it is odd. I don't see any real definition or explanation in the docs to clarify this. So maybe it's not intentional.


On Thursday, 20 February 2020 18.14.09 WET Nicholas Jankowski wrote:
> so it is odd. I don't see any real definition or explanation in the docs to
> clarify this. So maybe it's not intentional.
>
> filed a bug report ( https://savannah.gnu.org/bugs/?57867) as either it
> should be changed or documented.
Thank you. :)

José Matos

