Quantcast

Experimental matrix editor patch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Experimental matrix editor patch

John W. Eaton
Administrator
I've uploaded a patch to implement an experimental spreadsheet-like
matrix editor for the GUI here:

   https://savannah.gnu.org/patch/index.php?8039

This is a very bare-bones proof-of-concept implementation.

To use it, apply the patch to the development branch, rebuild Octave,
then right click a variable name in the workspace viewer and select
"Open in Variable Editor" from the context menu.

There are many things left to do, and many decisions to be made about
what exactly we would want from something like this.  For example,

  * it currently only handles double precision values (should we be
    able to edit arbitrary Octave data structures, or just numeric
    data?)

  * it doesn't preserve full precision (moving data in and out is done
    by converting to/from text)

  * resizing the matrix isn't possible

  * inserting rows or columns isn't possible

  * applying functions or performing arithmetic on the data (or
    regions) is not possible

  * editing is possible, but normal spreadsheet operations like filling
    a region is not possible

  * you are not prevented from inserting non-numeric data

  * things like "Inf" and "NaN" aren't recognized

  * only 2D arrays are handled properly

  * only one variable may be edited at a time (I guess we could use a
    tabbed editor, or some other way of managing multiple matrix edit
    windows)

  * we don't keep track of the original scope of the variable, so if
    you start editing a variable, then use the debugger and step into a
    function, then click "done" in the matrix editor, the variable will
    be inserted into the current scope, which is the one the debugger
    is visiting

  * and many other things, I'm sure...

So clearly this patch is not ready to be committed, but I wanted to
see if I could get a relatively simple structure in place for doing
this job.

jwe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental matrix editor patch

vinukn
It looks like 'variable view' in DomainMath IDE. It Convert a workspace variable to text file and represent it in a matrix viewer. It can handle almost all datas. When we using this type method, we should take care with different types of datas like struct, struct array,cell,matrix,complex numbers, multidimesional strings etc,because we are just displaying text data in matrix viewer. I think the scripts in DomainMath IDE may be help you to improve matrix editor!
Regards!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental matrix editor patch

Daniel Sebald
In reply to this post by John W. Eaton
On 05/01/2013 01:47 PM, John W. Eaton wrote:

> I've uploaded a patch to implement an experimental spreadsheet-like
> matrix editor for the GUI here:
>
> https://savannah.gnu.org/patch/index.php?8039
>
> This is a very bare-bones proof-of-concept implementation.
>
> To use it, apply the patch to the development branch, rebuild Octave,
> then right click a variable name in the workspace viewer and select
> "Open in Variable Editor" from the context menu.

It's a start.  I like the slide bars for quickly moving around within
large matrices.

I get a segfault when I click "Done", so I can't tell what happens after
that.  I suggest it should place a command in history "x(2,3) = 6", for
example.  That is, anything that modifies workspace memory should show
up in the history somehow.

[comments below]


> There are many things left to do, and many decisions to be made about
> what exactly we would want from something like this. For example,
>
> * it currently only handles double precision values (should we be
> able to edit arbitrary Octave data structures, or just numeric
> data?)
>
> * it doesn't preserve full precision (moving data in and out is done
> by converting to/from text)
>
> * resizing the matrix isn't possible
>
> * inserting rows or columns isn't possible
>
> * applying functions or performing arithmetic on the data (or
> regions) is not possible
>
> * editing is possible, but normal spreadsheet operations like filling
> a region is not possible

Might not be hard.  If the cell begin:end of a selected area is known,
can issue command like "x(3:5,7:10) = 0".


> * you are not prevented from inserting non-numeric data

There might be a way to configure that in the table view, but more than
that I wonder if the "Done" button is actually needed.  Instead, when
someone edits a cell and hits return, then a command like "x(2,3) = 6"
should be sent to Octave core.  If the user types "foo", so that "x(2,3)
= foo" is sent and comes back as an error, then the contents of the cell
should be reverted back to the original number.


> * things like "Inf" and "NaN" aren't recognized

Probably not a difficult addition.


> * only 2D arrays are handled properly
>
> * only one variable may be edited at a time (I guess we could use a
> tabbed editor, or some other way of managing multiple matrix edit
> windows)

I think that is enough for a start.  Multiple tabs might be OK, just
like multiple tabs for files, but don't get too complicated from the
start.  I do think the "Done" button should be removed.  That way there
isn't some sort of "unsaved" matrix modification hanging about.  It is a
workspace variable, not a file.  It would get too confusing to have too
many variables being edited and "unsaved".  Now, there would probably
eventually be a request to allow saving/loading matrices from the
variable editor to/from files, but I'd say leave that for down the road.
  Again, whatever is shown in that variable editor should exactly match
what is in workspace memory.


> * we don't keep track of the original scope of the variable, so if
> you start editing a variable, then use the debugger and step into a
> function, then click "done" in the matrix editor, the variable will
> be inserted into the current scope, which is the one the debugger
> is visiting

Get rid of "Done", save the scope.


> * and many other things, I'm sure...

What I think would be a nice feature is to have a background color for
the cells based upon their value.  I'm thinking, say sparse matrices
where the matrix might be big but mostly zero.  (Or maybe even better a
little slider for a cut level that will color the background of elements
above a certain value and not color the background of elements below
that value.)  If the non-zero entries have a background color tint, that
might make viewing the matrix easier.  Could be useful for eigen
structure, who knows?

Dan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Experimental matrix editor patch

PhilipNienhuis
In reply to this post by John W. Eaton
John W. Eaton wrote
I've uploaded a patch to implement an experimental spreadsheet-like
matrix editor for the GUI here:

   https://savannah.gnu.org/patch/index.php?8039

This is a very bare-bones proof-of-concept implementation.
Thank you for this development.
I have played a bit with the last few days.

<snip>
There are many things left to do, and many decisions to be made about
what exactly we would want from something like this.  For example,

  * it currently only handles double precision values (should we be
    able to edit arbitrary Octave data structures, or just numeric
    data?)
2D cell arrays (incl. mixed cell arrays) and char arrays would be an obvious next step. With that in place most of my own needs would be served.

More complicated data types:
- ND arrays,
- Struct arrays,
and especially:
- Nested arrays (e.g., cell arrays in structs, or double arrays in cells),
- (once classdef is working OK:) Data objects
would probably need some clever data slicing strategy to make them amenable for editing in some 2D view.

  * it doesn't preserve full precision (moving data in and out is done
    by converting to/from text)
Preserving full precision can probably only be done with copy-paste operations. Until that is (ever) implemented, I see little problem in conversion from/to text.

How does Matlab handle this?

  * resizing the matrix isn't possible

  * inserting rows or columns isn't possible

  * applying functions or performing arithmetic on the data (or
    regions) is not possible

  * editing is possible, but normal spreadsheet operations like filling
    a region is not possible
For those functions, spreadsheets are much better suited. Why duplicate that in Octave?

With the spreadsheet I/O functions in the OF io package it is very easy to delegate more involved data surgery to programs that are meant to do just that. (Just write data in question to file, process them, read back from file.)
Even w/o io package, csvwrite and csvread can help here.

My POV is that a variable editor is primarily useful when debugging scripts and m-files.
It also makes for much handier inspection of 2D data than displaying it in the terminal (no clobbering up of the terminal window).

  * you are not prevented from inserting non-numeric data

  * things like "Inf" and "NaN" aren't recognized

  * only 2D arrays are handled properly

  * only one variable may be edited at a time (I guess we could use a
    tabbed editor, or some other way of managing multiple matrix edit
    windows)
Indeed, a tabbed data editor would be very handy.

  * we don't keep track of the original scope of the variable, so if
    you start editing a variable, then use the debugger and step into a
    function, then click "done" in the matrix editor, the variable will
    be inserted into the current scope, which is the one the debugger
    is visiting

  * and many other things, I'm sure...
... like updating variable values after commands in the terminal are finished.

The patch as it stands prohibits editing scalar variables (in an MXE build).

So clearly this patch is not ready to be committed, but I wanted to
see if I could get a relatively simple structure in place for doing
this job.
IMO with that "relatively simple structure" you've already accomplished the larger part of a very useful add-on.

Philip
Loading...