bugGNU Octave - Bugs: bug #50466, makehgtform function missing


bug #50466: makehgtform function missing

Submitted by:  None
Submitted on:  Mon 06 Mar 2017 05:49:33 AM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  In Progress Assigned to:  None
Originator Name:  Bob Stephens Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  Any

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)

Sun 30 Dec 2018 06:54:56 AM UTC, comment #31: 

I resolved the three issues mentioned in comment #30.  This will be a part of Octave 5.0 scheduled for release in January, 2019.

I recommend that you upgrade as soon as it is available so that you can eliminate the hack, which no longer works anyways, of testing for Octave and doing a two step create graphics handle and then set parent.

The "type" field as returned by

ht = hgtransform ();
get (ht, "type")

will still be "hggroup".  I don't have a workaround to return "hgtransform".

Rik <rik5>
Project Administrator
Thu 27 Dec 2018 06:27:32 PM UTC, comment #30: 

This has been a small but signicant thread.  When pulled on, it has unraveled the entire sweater.  I've located three bugs so far.

1) axes::properties::update_axis_limits is using a 1x4 vector for limits when it should be using a 1x2 vector.  This results in the error when trying to set "xlim".  The incorrect assumption also looks to be causing a significant performance hit as the limits are being updated every time this function is called, rather than only when values have changed.

2) Out-of-order processing of property/value pairs when the property is "parent".  This results in the wrong behavior for hgtransform.

3) "Lost" graphics handles if multiple "parent" properties are specified.  This isn't good coding style, but the interpreter should cope rather than potentially segfault.

I'm going to be filing separate bug reports about those three so that this report stays on target about the missing "makehgtform" function.

Rik <rik5>
Project Administrator
Tue 25 Dec 2018 07:44:30 AM UTC, comment #29: 


Not meaning to continue kicking a soon to be dead hgtransform.m horse, but I felt obligated to determine the cause of the 'invalid value for array property "xlim"' error encountered as described in comment #25.

Casual experimentation lead to the fact that hgtransform is not involved with the error caused by what may be a bug in using set(hx, 'parent', hg). This observation was substantiated through a debugging session with octave-4.4.1 source code using the attached axes_xlim_error.m script and gdb debugging command file .gdbcmds_axes_xlim_error as demonstrated below.

Terminal Window 1

~/Work/Octave/rvctools$ /opt/octave/bin/octave --no-gui axes_xlim_error.m

hax = -1.3944
hax xlim     =
  -2   2
hax xlimmode =
hg = -6.3352
hg xlim =
hx = -7.7682

*** Press 'enter' key after 'Breakpoint 1 at 0x____________:
    axes::update_axis_limits. (2 locations)'
    appears in Terminal Window 2 when the debugger starts
    processing the specified command file.

Terminal Window 2

~/Temp/octave-4.4.1$ ps a | grep octave

  409 pts/18   Sl+    0:01 /opt/octave/libexec/octave/4.4.1/exec/x86_64-pc-linux-gnu/octave-gui --no-gui axes_xlim_error.m
  454 pts/2    S+     0:00 grep --color=auto octave

~/Temp/octave-4.4.1$ sudo gdb -x .gdbcmds_axes_xlim_error -p 409

A sample gdb debugging session log is provided as attached file axes_xlim_error_gdb_log.txt

The error is produced by the array_property::do_set() method on line 1454 of libinterp/corefcn/graphics.h for a false value returned by the array_property::validate() method on line 1418 of libinterp/corefcn/graphics.cc. It appears the validate() method is expecting a {1,2} or {2,1} vector but has been passed a {4,1} vector. The {4,1} vector is instantiated as a Matrix in the axes::update_axis_limits() method on line 7781 of libinterp/corefcn/graphics.cc.

Note: this error does not occur when the hggroup 'parent' property/value pair is passed as arguments in the called line() function as demonstrated by running axes_xlim_error.m with NO_ERROR set to true. This is due to the axes::update_axis_limits() method on line 8013 of libinterp/corefcn/graphics.cc being invoked instead of that on line 7781.


(file #45735, file #45736, file #45737)

Gary E. Deschaines <gary_e_d>
Fri 21 Dec 2018 04:55:23 AM UTC, comment #28: 

One more thought regarding my last comment about a set() callback.

To prevent never-ending stream of set() callbacks, a call to set() within hgtransform would have to be inhibited from triggering another set() callback.

I'm not sure if this could be done.

Gary E. Deschaines <gary_e_d>
Fri 21 Dec 2018 04:30:09 AM UTC, comment #27: 


So we now know:

  1. adopt() triggers children_cb() with default 'xdata' and 'ydata' for new line object instantiated by gh_manager,
  2. this default data gets saved in hgtransform orig_data property for the new line handle and processed by xform_data(),
  3. but when set() is called before make_graphics_object() exits, the passed in line data for the new line handle is saved in line object stored in core data structures,
  4. but the hgtransform orig_data property still has the initially stored default data for the line handle and is subsequently only modified by xform_data() called by matrix_cb() triggered when the hgtransform matrix changes.

Seems like the set() function which changes the values of the object data should trigger a callback to change the current values stored in the hgtransform orig_data property.

Am I missing something?


Gary E. Deschaines <gary_e_d>
Fri 21 Dec 2018 01:02:54 AM UTC, comment #26: 

For what it's worth, the 'xlim' error is exactly the problem I was getting when I simply reversed the order of adopt() and xset().  I fixed it in the C++ by also eliminating a call to update_limits(). 

On the positive side, if there is no workaround then I think we have to patch core Octave before the 5.0 release.

Rik <rik5>
Project Administrator
Fri 21 Dec 2018 12:22:13 AM UTC, comment #25: 


Well, "this is a fine mess we've gotten into."

The simple_2d_hgt_test.m script from comment #16 works in Octave 4.2.2 with hgtransform.m, but here is an error I encountered using my locally built Octave 4.4.1 executable.

error: invalid value for array property "xlim"
error: called from
    simple_2d_hgt_test at line 11 column 1

As with the hgtransform 'parent' property/value pair passed in line(), plot() and plot3() function calls, the problem occurs when the hgtransform children_cb() is executed.

I compiled a debug version of Octave 4.4.1, executed 'octave --no-gui simple_2d_hgt_test.m', and to my surprise the above error occurred.

The error does not occur for the following two test script changes.

Change 1:
    #axis([-2 2 -2 2]);
    x = line([0;1], [0;0], 'color', 'r');
Change 2:
    axis([-2 2 -2 2]);
    x = line('color', 'r');

Is it possible the hgtransform children_cb() callback is being erroneously applied by the core gh_manager to graphics figure child axes properties for the axes hgroup created in hgtransform()?

Why this problem in Octave 4.4.1 and not 4.2.2?

The pre-built Octave 4.2.2 executable is from package '4.2.2-1~octave~xenial2' for Ubuntu 16.04 LTS. I built the 4.4.1 version using the https://ftp.gnu.org/gnu/octave/octave-4.4.1.tar.gz source tar ball on 'Linux 4.15.0-43-generic #46~16.04.1-Ubuntu SMP Fri Dec 7 13:31:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux' OS using default ./configure options.


Gary E. Deschaines <gary_e_d>
Thu 20 Dec 2018 06:40:20 PM UTC, comment #24: 

I have a true fix in the C++ code that makes Octave compatible with Matlab when using a "parent" property in the constructor of a graphics object.  Unfortunately, we also are doing the code freeze for version 5.0 today which means I can't get this feature in.

In the mean time, your hack to detect Octave and apply a two-step creation and re-parenting will work.

I'll also take a look at whether there is a cheap hack in the hgtransform m-file that we could use for the next 6 months.  That kind of change I probably could get in.

Rik <rik5>
Project Administrator
Thu 20 Dec 2018 01:52:05 AM UTC, comment #23: 


That was just a pseudo-code snippet to illustrate how RTB for MATLAB scripts calling line(), plot() and plot3() had to be wrapped to avoid passing hgtransform as a 'parent' property/value pair to Octave's libinterp/corefcn/graphics routines.

The sample planar hgtransform test script provided as an attachment to comment #16 is what I used to demonstrate the problem with executable code. I am planning to debug Octave using Case 2 in the sample test script to determine how the hgtransform children_cb() was being triggered without using the line data passed to __go_line__() in __line__.m. -n

Sorry for the confusion.


Gary E. Deschaines <gary_e_d>
Thu 20 Dec 2018 01:11:57 AM UTC, comment #22: 

Well, you managed to find a deep, deep issue in the order of execution of code when graphic objects are created.  The order now is

1) create handle
2) adopt (parent, handle)

I tried the trivial thing and moved the adopt() after set() and it works for this example, but I also start to get errors in other normal plotting routines.  Will have to investigate further.

Rik <rik5>
Project Administrator
Wed 19 Dec 2018 11:38:38 PM UTC, comment #21: 

I pushed the the change to add support for text objects here (https://hg.savannah.gnu.org/hgweb/octave/rev/298c30063b2f).

I'll take a look now at what is happening with line and plot.  I have a question, the code snippet you presented (shown below) doesn't run for me because 'x[]' is not a valid expression.

    hgt = hgtransform(hax);
    if isOctave
        h = line(x[], y[], z[], options);
        set(h, 'parent', hgt);
       line(x[], y[], z[], options, 'Parent', hgt);

What is the correct code?  Is it

        h = line([], [], [], options);
        set(h, 'parent', hgt);

Rik <rik5>
Project Administrator
Wed 19 Dec 2018 11:14:54 PM UTC, comment #20: 


Thnx for the offer, but the credit should go to you since my contribution is minor compared to yours!

I haven't delved into the possible problem with hgtransform passed as a parent property value in line, plot, plot3 functions. I believe it's going to require debugging and I'll have to recompile Octave and do some investigating.

At the moment I've shifted attention back to my RTB for Python - Update 1 effort. Just got it's trplot function matching Octave's so I can develop a Jupyter notebook illustrating transformations and trajectory commonality between RTB for Python/Octave - Update 1 and RTB for MATLAB.


Gary E. Deschaines <gary_e_d>
Wed 19 Dec 2018 08:36:26 PM UTC, comment #19: 

That's a step forward, thanks Gary+Rik.  A remaining issue is that the parent passed to plot is interpreted as an hggroup not an hgtransform.  In MATLAB it can be either and the object type is tested to determine which it is.  I am struggling to find Octave documentation that defines the semantics of the 'parent' graphical property.  The important question is whether or not it is consistent with MATLAB, group or transform, or defined as being just a group.

Peter Corke <petercorke>
Wed 19 Dec 2018 03:29:42 PM UTC, comment #18: 

@Gary: I reviewed your patch.  It seems to work nicely for text objects.  I made a few small modifications, for instance we don't need to call double() on the text position property since that is guaranteed to be double already.

Would you like to be credited with this patch?  If so, we usually check things in under a name and and e-mail.  The name, so you get credit, and the e-mail, in case anything happens in the future and the original author needs to be contacted.

Otherwise, I can check it in under my own credentials.

Rik <rik5>
Project Administrator
Wed 19 Dec 2018 02:35:52 AM UTC, comment #17: 


I took the liberty of adding text transformation capability to hgtransform as provided in the attached hgtransform.m script file.

The transformed text rendered by Octave 4.2.2 appears to be comparable to that obtained in MATLAB R2018b.

To address the issue of passing hgtransform 'parent' property/value pairs in RTB for MATLAB line(), plot() and plot3() functions, I've simply applied an isOctave check function (attached) and wrapped the relevant code blocks in RTB rvctools ./robot/trplot.m, ./robot/trplot2.m and ./common/plot2.m scripts
[see: (https://github.com/gedeschaines/robotics-toolbox-python/tree/update1/Octave/rvctools)] as shown in the following pseudo-code snippet:

    hgt = hgtransform(hax);
    if isOctave
        h = line(x[], y[], z[], options);
        set(h, 'parent', hgt);
       line(x[], y[], z[], options, 'Parent', hgt);

This should provide a basic level of MATLAB/Octave compatibility with hgtransform (note: RTB for MATLAB v9+ does not use the makehgtform function).


(file #45696, file #45697)

Gary E. Deschaines <gary_e_d>
Mon 17 Dec 2018 10:28:43 PM UTC, comment #16: 

Hi Rik,

I have recently been working toward revitalizing Dr. Peter Corke's Robotic Toolbox (RTB) for MATLAB to function with GNU Octave 4.2+ and have encountered this hgtransform issue. What I have deduced is that an hgtransform 'parent' property/value pair cannot be passed as arguments in line(), plot() or plot3() function calls, as done in most RTB for MATLAB scripts. It appears Octave's libinterp/corefcn/graphics routines interpret the passed 'parent' property/value pair as an hggroup and create a new line object with default 'xdata', 'ydata' and 'zdata' values (ref: line::properties::factory_defaults and line::properties::properties() in libinterp/corefcn/graphics-props.cc, and root_figure::init_factory_properties and default_data() in libinterp/corefcn/graphics.cc).

When the _go_to_line() function in the following code block from scripts/plot/draw/private/__line_.m

  for i = 1:nlines
    tmp = data(ismat);
    if (! size_equal (tmp)
        || (nvecpts != 0 && any (nvecpts != cellfun ("size", tmp, 1))))
      error ("line: data size_mismatch");
    data_args(mask) = cellfun (@(x) x(:,i), data(ismat),
                               "uniformoutput", false);

    handles(i) = __go_line__ (p, data_args{:}, other_args{:});


is executed by the associated libinterp/corefcn/graphics routines, the hgtransform children call back function children_cb() is invoked with a child line containing default line data, not that passed as data_args to the
_go_line_() function. This behavior can be demonstrated with the attached simple planar hgtransform test script. In the first case the given unit line along the +x axis is properly rotated along the +y axis. In the second case proper rotation is observed, but for the default line ([0,0],[1,1]) and not the given unit line along the +x axis.

Since I have not had to delve into the inner workings of Octave before, it may be a short time before I can determine the exact failure mechanism. However, I thought this information may be of service to you or others working on this bug issue.


(file #45685)

Gary E. Deschaines <gary_e_d>
Sun 16 Dec 2018 01:34:31 AM UTC, comment #15: 

Here's the minimalist example

octave:8> hg=hgtransformhg = -27.983
octave:9> plot3([0 0 0; 1 0 0], [0 0 0; 0 1 0], [0 0 0; 0 0 1], 'parent', hg)

% the 3D plot is drawn perfectly
% now I apply  a rotation of pi/2 about the x-axis

octave:10> T=[1   0   0   0; 0   0  -1   0; 0   1   0   0; 0   0   0   1]
T =

   1   0   0   0
   0   0  -1   0
   0   1   0   0
   0   0   0   1

octave:11> set(hg, 'Matrix', T)

and the result is not correct, the lines are no longer orthogonal.

Peter Corke <petercorke>
Mon 10 Dec 2018 07:30:58 PM UTC, comment #14: 

We haven't announced hgtransform because it is incomplete.  At the very least, it needs to have the documentation finished.

For text objects, as I understand it, not only do the coordinates of the text object have to change, but so does the "rotation" property.  Since Octave is not doing that, it issues a warning.

Can you provide the source code for the transform which isn't working?

A simple test of a rotation seems okay.

hl = line ();
ht = hgtransform ();
set (hl, 'parent', ht);
xfrm = get (ht, 'matrix')
xfrm(1:2,1:2) = [cos(pi/2), sin(pi/2); -sin(pi/2), cos(pi/2)]
set (ht, 'matrix', xfrm);

Rik <rik5>
Project Administrator
Sun 09 Dec 2018 03:39:20 AM UTC, comment #13: 

Not sure if this is still an active thread.  I'm the author of the robotics toolbox, and am interested in having it work under Octave. 

Right now I can see two issues with GNU Octave Version: 4.4.0 (hg id: d703d8bbc6ae), and the change log for 4.4.1 doesn't mention hgtransform.

1. warning: hgtransform: text objects are not yet supported

yet the text concerned seems to be placed at the right location

2.  setting the transformation matrix

The default transformation of the hgtransform works correctly, but as soon as I set the 'Matrix' property to a non identity value the plot looks very odd.  I'm drawing a coordinate frame with 3 orthogonal lines, after I set the 'Matrix' property I see only 2 lines of different length.

Peter Corke <petercorke>
Mon 13 Mar 2017 07:42:17 AM UTC, comment #12: 

Thanks Rik. That aspect works. I'm still not managing to successfully use the robotics toolbox function trplot2 to draw a coordinate frame. The toolbox was developed against Matlab so I have some work to do yet.

I think my next step is to try and get the debugger working so I can step through the code. I'm suspecting I'll need to install a Linux partition or VM as my PC's are Windows 10 and I've not had any success with the debugger on them yet. Seems to lock up Octave (and I read the disclaimer when installing Octave re Windows 10).

Bob Stephens <rst26508>
Sun 12 Mar 2017 06:13:47 AM UTC, comment #11: 

Having different recipes for each object type is definitely beginning to complicate this function.  I checked in a cset here (http://hg.savannah.gnu.org/hgweb/octave/rev/a470f7fee1cf) that does more input validation on the object type.  It issues a warning if the type should be accepted, like text, but the code hasn't been implemented.  The warning is issued only once.  Thereafter the unsupported objects are ignored.

Rik <rik5>
Project Administrator
Sun 12 Mar 2017 03:47:10 AM UTC, comment #10: 

There is a list of allowed types in http://matlab.izmiran.ru/help/techdoc/ref/hgtransformproperties.html

"Children of the hgtransform object. An array containing the handles of all graphics objects parented to the hgtransform object (whether visible or not).

The graphics objects that can be children of an hgtransform are images, lights, lines, patches, rectangles, surfaces, and text. You can change the order of the handles and thereby change the stacking of the objects on the display.

Note that if a child object's HandleVisibility property is set to callback or off, its handle does not show up in the hgtransform Children property unless you set the Root ShowHiddenHandles property to on. "

I had a limited period license for Matlab for a short period but did not get to know it well enough. Looking at the plot example in a text it appears that the position of the text is rotated but  not the orientation (Hope that makes sense). Eg X, Y and coordinate frame labels are upright but positioned to correspond to the relevant axis.

Would it be viable as an intermediate option to allow text to be added (or behave as though it had been added) but then ignore it.  Something that would allow code built for Matlab to run but with a reduced functionality (not displaying text)?

Bob Stephens <rst26508>
Sun 12 Mar 2017 01:45:28 AM UTC, comment #9: 

The problem, as noted, is that some graphics objects don't have data properties.  The text object is one of them.  It has a position property and a rotation property.  Instead of just doing matrix multiplication which is what hgtransform does now, one would need to merge the position and rotation information into x,y, and zdata, apply the transform, and then unmerge the data back to position and rotation.  That sounds like a lot of work.

Do you know if Matlab allows any object to be parented to an hgtransform?  The simplest thing would be a restriction on the allowed object types.  If Matlab does accept any object, does it actually transform them all or does it simply ignore ones with no data property.  Finally, if it is transforming even text fields then the transform becomes much more complicated as it will need to be a switch statement off of the graphics object type and properties.

Rik <rik5>
Project Administrator
Sat 11 Mar 2017 10:56:40 PM UTC, comment #8: 

Thanks Rik. I dropped part way into the debugger. I can see the "debug>" prompt but Octave keep getting stuck in a not responding mode.

I'm assuming that working towards getting hgtransform functionality to a point where it deals with all the functionality from matlab is of value and that lessons learned in the .m version will be important for an eventual build in c++  but if the priority is low enough on the big picture that I'm becoming a time waster please let me know.

I added the following to the test_hgtransform.m script just before the for loop. It appears to be failing in at least one of the same spots as the version using trplot2 although I've had to modify the statement from trplot2 as it was relying on structures and calls to other parts of the toolbox. Eg not entirely sure I have it right but somewhat hopeful.
% Modified extract from trplot2 to simulate errors raised from that
h = text(1, 2, 'X', 'Parent', t);
set(h, 'Parent', t);

It's stopping at line 161 of hgtransform.m
orig_data(end).xdata = get (hk, "xdata");

The initial error raised is
error: get: unknown text property data

I'm assuming that the areas where xyz data in the children is dealt with may need some kind of test on data type to handle types without xyz data differently but so far I've not yes succeeded in finding something that works.

From the Workspace panel in Octave (Values appear to be truncated)
orig_data   struct  1x7    ...
hnew        double  1x1    -13.732
hlist       double  1x6    [-6.2230, -7...
hkids       double  7x1    [-13.732, -1...
hk          double  1x1    -13.732
hgt         double  1x1    -12.619
hdel        double  1x0    []
            double  0x0    []

Bob Stephens <rst26508>
Sat 11 Mar 2017 05:40:54 AM UTC, comment #7: 

Maybe try

debug_on_error (1)

and then run your test code.  If it works as expected, you should be dropped in to the debugger at the statement causing an error.  At that point you can inspect variables, look at the backtrace, and maybe figure out what is going on.

Rik <rik5>
Project Administrator
Sat 11 Mar 2017 05:13:45 AM UTC, comment #6: 

The sample Code I posted earlier to test hgtransform appears to work well with the hgtransform.m file Rik so kindly created.

I have found that when trying to use the Robotics Toolbox and the trplot2 function it's failing. I've been trying to work my way through what and where (interesting learning).
I've not been able to find a neat way of providing a simple way to reproduce it without the Toolbox yet.

The errors appear to be around items returned in the "for hk = hlist.'" in xform_data failing when later statements try to extract the xdata. I am wondering if it's because trplot2 appends text data (but don't know enough yet to speak with confidence).

From line 157 of trplot2.m
    % label the axes
    if isempty(opt.frame)
        fmt = '%c';
        fmt = sprintf('%%c_{%s}', opt.frame);


    % add the labels to each axis
    h = text(x1(1), x1(2), sprintf(fmt, 'X'), 'Parent', hg);
    if ~isempty(opt.text_opts)
        set(h, opt.text_opts{:});
    if opt.arrow
        set(h, 'Parent', hg);

-- More for Y axis and the frame follow in the code.

As I stated earlier I've not yet worked out how to post a simple test for this without the toolbox. I'll post the output (I think I'm back to original code after lots of try blocks to see if I can isolate the issue)
    % label the axes
    if isempty(opt.frame)
        fmt = '%c';
        fmt = sprintf('%%c_{%s}', opt.frame);


    % add the labels to each axis
    h = text(x1(1), x1(2), sprintf(fmt, 'X'), 'Parent', hg);
    if ~isempty(opt.text_opts)
        set(h, opt.text_opts{:});
    if opt.arrow
        set(h, 'Parent', hg);

Bob Stephens <rst26508>
Thu 09 Mar 2017 11:07:23 AM UTC, comment #5: 

Thanks Rik, I really appreciate that. Tested earlier and the shape generated by the test script rotated nicely. That should get me going on some of the plotting stuff in the robotics toolbox and give me an opportunity to see how that was done.

I have some other bits to chase in behaviours of the Toolbox on Octave but greatly appreciate having a version of the function available.


Bob Stephens <rst26508>
Wed 08 Mar 2017 11:22:33 PM UTC, comment #4: 

I created a quick m-file version of hgtransform.m on the development branch of Octave (http://hg.savannah.gnu.org/hgweb/octave/rev/aaf91b4f48e4).  It seems to work pretty well.  Since it is just an m-file you can download it and use it as is.

Rik <rik5>
Project Administrator
Tue 07 Mar 2017 10:25:38 AM UTC, comment #3: 

I've attached my working files. After doing so I remembered that the version of makehgtform.m that I have so far relies on the robotics toolbox I mentioned earlier so may not make much sense at this point. It creates a 4*4 transformation matrix based on the type passed in.

hgtransform is doing some of what I want but I think I have a notable logic failure in the actual application of the transformation matrix. The parts of the surfaces which make up the group change shape (and size when I include the scale transform) but not in the way I'm expecting.

There is a test structure to drive it based on code snippets for using hgtransform eg (http://matlab.izmiran.ru/help/techdoc/ref/hgtransform.html).

Posting in case this of interest to others either for their own use or for guiding a learner.

I'm using padarray in the listener because I've not yet worked out how to append rows to the bottom of the matrix.

Bob Stephens <rst26508>
Tue 07 Mar 2017 06:00:05 AM UTC, comment #2: 

Thanks Rik. At this stage I'll try for the hgtransform.m approach, the learning curve on the C++ graphics object primitive looks like it would be a little steep at this point. Is it appropriate to ask "how to" questions here if I get stuck or should that be elsewhere?

I appreciate the hints by the way.


Bob Stephens <rst26508>
Mon 06 Mar 2017 07:37:55 PM UTC, comment #1: 

The function is known to be missing which is why it is in the unimplemented list.  If you try at the command line you get

warning: the 'hgtransform' function is not yet implemented in Octave

Please read <http://www.octave.org/missing.html> to learn how you can
contribute missing functionality.

This is a different, and more appropriate error message, than if the name in question doesn't refer to any known variable or function.

octave:2> abc
error: 'abc' undefined near line 1 column 1

Implementation, ideally, would be in C++ as a new graphics object primitive (like line, or surface).

However, you might be able to work up a replacement in an m-file that uses hggroup.  Child graphic primitives can have their parent properties set to an hggroup and you can add the necessary property (Matrix) using addproperty to make the hggroup resemble an hgtransform.  After that, you would need to add a callback function that listens for changes on the hgtransform Matrix property (addlistener()).  The callback functions would then use the transform Matrix to alter the Data properties of the child objects.

Rik <rik5>
Project Administrator
Mon 06 Mar 2017 05:49:33 AM UTC, original submission:  

Firstly - I'm a newby to this space so I may have missed something, my apologies if I have.

The Matlab function hgtransform does not appear to exist in Octave or in the function/missing function references I can find. One hit in Octave-4.2.1\share\octave\4.2.1\m\help\__unimplemented__.m  on line 690


It's used by some of the plotting functions in Peter Corke's Robotics toolkit (trplot2.m, trplot.m, plot3d.m, Vehicle.m and Shape.m) which are used in the Matlab examples in his text. Eg line 210 in trplot.m https://github.com/petercorke/robotics-toolbox-matlab/blob/master/trplot.m

I'm interested in how to go about adding a feature such as this to Octave (or the toolkit if that makes sense) but at this point don't know enough to make a credible start.

Should hgtransform be added to the list of missing functions?



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

Attach Files:

Attached Files
file #45737:  .gdbcmds_axes_xlim_error added by gary_e_d (659B - application/octet-stream)
file #45735:  axes_xlim_error.m added by gary_e_d (616B - text/x-objcsrc)
file #45696:  hgtransform.m added by gary_e_d (7KiB - text/x-objcsrc)
file #45697:  isOctave.m added by gary_e_d (242B - text/x-objcsrc)
file #45685:  simple_2d_hgt_test.m added by gary_e_d (680B - text/x-objcsrc)
file #39923:  makehgtform.m added by rst26508 (502B - application/octet-stream - First pass at some of the functionaility for a .m version of hgtransform)
file #39924:  hgtransform.m added by rst26508 (976B - application/octet-stream - First pass at some of the functionaility for a .m version of hgtransform)
file #39925:  test_hgtransform.m added by rst26508 (792B - application/octet-stream - First pass at some of the functionaility for a .m version of hgtransform)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gary_e_d (Updated the item)
  • -email is unavailable- added by petercorke (Posted a comment)
  • -email is unavailable- added by rst26508 (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-25 gary_e_d Attached File- => Added axes_xlim_error.m, #45735
        Attached File- => Added axes_xlim_error_gdb_log.txt, #45736
        Attached File- => Added .gdbcmds_axes_xlim_error, #45737
    2018-12-20 rik5 StatusPatch Submitted => In Progress
    2018-12-19 rik5 StatusConfirmed => Patch Submitted
    2018-12-19 gary_e_d Attached File- => Added hgtransform.m, #45696
        Attached File- => Added isOctave.m, #45697
    2018-12-17 gary_e_d Attached File- => Added simple_2d_hgt_test.m, #45685
    2017-03-08 rik5 Release4.2.1 => dev
        Summaryhgtransform function missing => makehgtform function missing
    2017-03-07 rst26508 Attached File- => Added makehgtform.m, #39923
        Attached File- => Added hgtransform.m, #39924
        Attached File- => Added test_hgtransform.m, #39925
    2017-03-06 rik5 StatusNone => Confirmed
        Operating SystemMicrosoft Windows => Any

    Back to the top

    Powered by Savane 3.5