bugGNU Octave - Bugs: bug #50855, new Matlab string array syntax


bug #50855: new Matlab string array syntax

Submitted by:  Ceral Paquet <octavebugs>
Submitted on:  Sat 22 Apr 2017 04:36:35 PM UTC  
Category:  Interpreter Severity:  2 - Minor
Priority:  1 - Later Item Group:  WTF, Matlab?!?
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.2.1 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 11 Jan 2019 11:59:46 PM UTC, comment #6: 

Gotcha. Thanks.

For the sake of discussion, here's an example of how a @string array could be implemented as a userland M-code class built on top of cellstrs: https://savannah.gnu.org/bugs/download.php?file_id=45939

It supports lexical casting and various other type conversions.

This approach works decently for string data analysis by users: it's a usable datatype, and functions aimed at string manipulation will work well on it. For text data sets, a user can create @string arrays and work with them usefully.

Where it works less well is all the various functions that take strings as incidental arguments, like the plotting functions, property getter/setters, statistical functions that take name/value pair arguments, and all the various other miscellaneous functions. Packages (e.g. from Octave Forge) will also not be @string-aware unless explicitly coded to be so.

Also, since this is based on cellstrs, the underlying "character" semantics are still those of Octave chars. (That is, bag-of-bytes interpreted via context or user locale settings? I'm not actually sure exactly how Octave chars work.)

Andrew Janke <apjanke>
Fri 11 Jan 2019 08:12:18 PM UTC, comment #5: 

Andrew - by "lexical casting" I meant conversion between numeric and string types that interprets the numeric value that the string represents, rather than the byte values of the characters.

Most interpreted languages use lexical casting for converting between strings and numerics. If you're familiar with Python, then using 'int' and 'str' to convert between the two is lexical casting, while using 'chr' and 'ord' imitates a C-style byte-oriented casting.

I was only pointing out that the string type has different rules for conversion between string and double than the char type that we support in Octave now, so it will need a completely new class definition and type support to differentiate it.

Mike Miller <mtmiller>
Project Administrator
Fri 11 Jan 2019 12:39:56 PM UTC, comment #4: 

> String array is a fundamental type, not a cell array, and follows different rules for lexical casting from other types and so on.

Could you elaborate on that a bit? What is "lexical casting"?

Andrew Janke <apjanke>
Mon 24 Apr 2017 02:02:05 AM UTC, comment #3: 

Of course even before this syntax change could possibly be adopted, we need a working implementation of the string array type itself. That can be done with or without the change in how the double quote character is interpreted by Octave.

String array is a fundamental type, not a cell array, and follows different rules for lexical casting from other types and so on.

Mike Miller <mtmiller>
Project Administrator
Sun 23 Apr 2017 02:22:50 PM UTC, comment #2: 

In terms of workarounds, it is quite easy not to use this specific feature of Matlab if you want to exchange scripts between the two environments.  Just use the regular cell string construction operator if you do, in fact, want a cell array.

str = {'Good' 'Morning'}

Rik <rik5>
Project Administrator
Sun 23 Apr 2017 02:06:45 PM UTC, comment #1: 

I saw that.  I don't know if they were being ornery and trying to force Octave to spend developer time catching up, or if they had simply run out of characters on a standard keyboard.

Rik <rik5>
Project Administrator
Sat 22 Apr 2017 04:36:35 PM UTC, original submission:  

Not sure if you guys noticed but MATLAB recently introduced String arrays which may conflict with Octave's use of the double-quote "" versus ''.


str = ["Good" "morning"]

now produces a valid 1x2 string array.

Ceral Paquet <octavebugs>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #45939:  string.m added by apjanke (21KiB - application/octet-stream - rough example of an M-code @string implementation)


Carbon-Copy List
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by octavebugs (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-03 mmuetzel Dependencies- => bugs #59389 is dependent
    2020-03-28 mtmiller Dependencies- => bugs #58071 is dependent
    2019-01-11 apjanke Attached File- => Added string.m, #45939
    2018-03-23 mtmiller Dependencies- => bugs #53439 is dependent
    2017-04-23 rik5 CategoryNone => Interpreter
        Severity3 - Normal => 2 - Minor
        Priority5 - Normal => 1 - Later
        StatusNone => Confirmed
        SummaryString array => new Matlab string array syntax

    Back to the top

    Powered by Savane 3.5