bugGNU Octave - Bugs: bug #58745, Conversion between matrices and...

 
 

bug #58745: Conversion between matrices and Java arrays

Submitted by:  Benjamin Moody <bmoody>
Submitted on:  Fri 10 Jul 2020 07:00:22 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  5.2.0 Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Fri 18 Sep 2020 08:30:50 AM UTC, comment #3: 

Minor technical/terminology note: there's no such thing as a multidimensional array in Java. Multidimensional arrays are represented as just arrays-of-arrays.

Andrew Janke <apjanke>
Tue 21 Jul 2020 06:48:54 AM UTC, comment #2: 

It is possible to make tests conditional on compile time and run time conditions. For Java, you'd probably want to start the BIST with:

%!testif HAVE_JAVA; usejava ("jvm")

For the Java part of the test case, you could probably add new files to scripts/java/org/octave (maybe named OctaveTestUnBoxing.java or something similar). It should be enough to add those files to the JAVA_SRC list in scripts/java/module.mk to have them compiled by make.

I'm not a Java expert, so you might want or need to deviate from that.

Markus M├╝tzel <mmuetzel>
Project Member
Mon 20 Jul 2020 09:28:01 PM UTC, comment #1: 

Here is a patch for handling two-dimensional return values.

Like the existing code in box_more, this works by copying the entire matrix into an NDArray and then transposing it - I don't know if this is better or worse, for large matrices, than copying one element at a time.

Of course, it'd be better to handle arbitrary N-dimensional arrays.  But handling 2D arrays is still a significant improvement. :)

In contrast to what I wrote before, I think it would be better not to introduce a new value for java_matrix_autoconversion.  For return values, there's no conflict in auto-converting both Matrix objects and multidimensional arrays.  Arguments are more complicated, and I think it would be better to convert argument values at the ClassHelper level, and avoid picking a particular data format before deciding which method to call.  (This is closely related to bug #53524.)

The overall conversion logic is already somewhat complicated and fragile, so I'd like to add some test cases.  What would be the best way to write a test case that includes both Octave and Java code (so the test should only be run if Java is supported, and the Java code must be compiled first)?

(file #49526)

Benjamin Moody <bmoody>
Fri 10 Jul 2020 07:00:22 PM UTC, original submission:  

In order to pass a vector or matrix as an argument to a Java method, or to return a vector or matrix value from a Java method, the value needs to be converted from a Java object to an Octave value, or vice versa.

In Matlab, this conversion is supposed to be automatic, as (partially) documented here:

https://www.mathworks.com/help/matlab/matlab_external/passing-data-to-java-methods.html
https://www.mathworks.com/help/matlab/matlab_external/handling-data-returned-from-java-methods.html

It gets very messy, but let's focus on the common cases:

  • Passing a vector (1xN or Nx1) as an argument converts it into a Java array.
  • Passing a matrix (MxN) as an argument converts it into a two-dimensional Java array.
  • Returning an array from a Java method converts it into a column vector.
  • Returning a rectangular two-dimensional array from a Java method converts it into a matrix.

Octave seems to work the same way for vectors.  For matrices, however, it is considerably more complicated:

  • If a matrix is passed as an argument, it is converted into either an org.octave.OctaveReference object (if java_matrix_autoconversion is 0) or an org.octave.Matrix object (if java_matrix_autoconversion is 1).
  • If a Java method returns a two-dimensional array, it is left as a semi-opaque "Java object", which can be indexed, but can't be used directly as a matrix, or converted directly to another type (e.g. calling double() gives "invalid conversion from octave_java to double".)
  • If a Java method returns an org.octave.Matrix object and java_matrix_autoconversion is 1, it is converted into an Octave matrix.
  • The 'java2mat' function is provided as a way to explicitly convert two-dimensional arrays to matrices.  (Long ago, I believe, it was also necessary to use this for one-dimensional arrays as well.)  However, this function has now been deprecated, and (as far as I know) it never worked for types other than double.

Automatic conversion can be less efficient, but I think it would be preferable for convenience and for compatibility with Matlab's Java interface.

One possibility would be to make automatic conversions the default, but keep both existing behaviors as options for compatibility.  (For example, we could say that "java_matrix_autoconversion(2)" would be the default, but a program could explicitly call "java_matrix_autoconversion(0)" or "java_matrix_autoconversion(1)" to get the old behavior.)

Another possibility would be to keep the current default behavior but to add Matlab-style autoconversion as an option that must be enabled explicitly.

A third possibility would be to always use Matlab-style autoconversion and remove all support for "java_matrix_autoconversion".

This issue is tangentially related to, but separate from, several existing bugs:

  • bug #48591 (handling of java.lang.Number objects)
  • bug #51822 (handling of multi-dimensional object arrays)
  • bug #53524 ("fuzzy prototype matching" for scalars)
  • bug #54170 (handling of character arrays)
Benjamin Moody <bmoody>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by apjanke (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by bmoody (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.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-20 bmoody Attached File- => Added box_primitive_2d_array.patch, #49526

    Back to the top


    Powered by Savane 3.5