I am facing a strange behaviour in MATLAB when declaring an object variable as global. Where all global doubles I define seem to be recognizable by functions, it seems not possible to do the same with objects, or structs of objects that are defined from a class. This is what I have done.
Class definition:
classdef Class < handle
properties
property
end
methods
function obj = Constructor(value)
if nargin == 1
obj.property = value;
end
end
end
end
Construction of objects array:
% Define objects array as global variable to be accessible in functions
global objectsArray variableA
% define value of variable A, to be accessible in functions
variableA = 123;
% Values to be assigned to objects' property field
values = [1,2,3];
% initialise object array using constructor
if isempty(objectsArray)
objectsArray(3,1) = Constructor();
end
% define objects' property field
for k = 1:3
objectsArray(k) = Constructor( values(k) );
end
Now, I'd like a function to access both the objects array, and variable A, both defined above, and both declared as global variables. However, if I build a function as follows, only variable A is accessible, while the objects array is seen as an empty variable.
function varargout = doSomething (varargin)
global objectsArray variableA
aaa = variableA;
bbb = objcetsArray(1).property; <--- code crashes here
end
The code crashes at executing the instruction defining bbb. Debug mode reveals that objectsArray is empty, and that variableA is equal to its value, 123. Ending debug mode, exiting therefore the function's execution, the objectsArray is defined as I'd expect, as a structure of 3 objects.
My question is, why does this happen? Why does it seem possible to recall global variables, but not if they are defined as objects?
After some research, I realised the problem was not the object itself, but the concept of global variable and how MATLAB works with it.
The same issue materializes when trying to make a struct global.
An answer to my question is explained in this thread by the user Steven Lord:
The problem here is not caused by global, at least not directly. When
you define a variable to be global, it starts out as an empty
(0-by-0) double array. So this line:
global array_Structure
sets array_Structure to be a global array containing [].
Now when you try to assign a struct array (data_Struct) into an
element of the array_Structure double variable, since the variable
has to be all one type, MATLAB has to convert one of the variables
into the other's type. In this case, since you're trying to put the
struct into the double array, it tries to convert the struct into a
double array. For some pairs of the built-in data types, MATLAB knows
how to convert between the two data types implicitly (for instance,
double to single) -- but struct and double is not one of those pairs
of types, so MATLAB says that converting a struct into a double is
not possible. It doesn't know how to do it.
Related
classdef Dog < handle
properties
data;
end
methods
function self = Dog(varargin)
disp("Dog()")
end
function out = new(~)
out = Dog();
out('bark') = 1;
end
end
end
d=Dog(); why does d.new() print below?
Dog()
Dog()
Dog()
It also bypasses subsref if I overload it. Entering d in console gives
ans =
1×114 Dog array with properties:
data
and isn't reproduced with d('bark') = 1.
The behavior changes if I get rid of varargin, instead there's an error. Also why 1x114?
Here is what's happening when calling d.new() (after d = Dog()):
out = Dog(); is invoked. This constructor call triggers the first output of "Dog()"
out('bark') = 1; is invoked, which triggers the following:
The characters of 'bark' are interpreted as values [98 97 114 107 ]. Consequently, Matlab resizes out to a size of 114.
To construct a Dog object to fill positions [98 97 114 107 ] in out, Matlab calls the constructor again, this time with the input argument varargin equal to { 1 }. This triggers the second output of "Dog()".
To construct a Dog object to fill the other positions in out, Matlab calls the constructor again, this time with no input argument. This triggers the third output of "Dog()".
Furthermore, subsref is not bypassed, but simply not called, as you do not refer to the object in a reading manner.
And when you remove varargin, you get the error, because the constructor cannot be called anymore with one input argument, as explained in the second bullet point under 2. above.
As I understand it, within class methods, indexing expressions always use the built-in subsasgn and subsref, not the overloaded (customized) one you might write yourself. This is so that overloading these functions doesn't remove the ability of class methods to access object properties.
So, within your class method, out(i) accesses the ith object in the array out. This is not out.data(i), out is really an array of objects of class Dog. Dog() creates a 1x1 array, which you would normally think of as an object, but it really is an array. Everything in MATLAB is an array!
Now for out('bark') = 1. 'bark', as explained by user16372530's anwser, is a 4-element array, with numeric values [98 97 114 107]. Thus out, which starts off as a 1x1 array of your custom class, is resized to an array of 114 elements, and to 4 of those elements you assign 1. Here, MATLAB needs to create an empty element to fill out the 113 new elements, so calls Dog() once and copies the result to each of those elements. Then it needs to convert 1 to your class, so calls Dog(1) to do so, and copies to result to the 4 indexed elements. Actually, as indicated by
user16372530 in a comment below, first 1 is converted and then the empty object is created.
If you want your class method to use the overloaded indexing operator, you need to explicitly call subsasgn or subsref, which is ugly and hard to read. There really is no way, as far as I understand it, to use class objects inside the class methods as you actually intend your class to be used. The same code behaves differently inside a class method and outside of it.
MATLAB OOP has some really interesting features, but it also has a lot of weird and inconvenient things. I guess they did their best designing a custom class system within the previously existing MATLAB array syntax.
Being given the name of a variable as a string (in my case the name of an existing Simulink.Parameter variable in the workspace selected by the user as a design variable for optimization), I would like to be able to access the properties of the object such as Simulink.Parameter.Min, Simulink.Parameter.Max, Simulink.Parameter.Value without using eval(). So far I am employing the (very ugly) solution
varnames = {'var1','var2'}; % Simulink.Parameter objects existing in workspace
objects = cell(length(varnames),1);
for i = 1:length(varnames)
eval(['objects{i}=', varnames{i}, ';']) % Store objects in a cell array
end
Ideally, this would look like:
objects = get_object_handles_from_string(varnames);
value_1 = object{1}.Value(:);
Otherwise a method returning the variable name given the object handle would also be acceptable.
Methods that I found not to be working but might be useful otherwise:
whos finds variable names and properties in the current workspace but no handles.
inputname returns the variable name of an explicit function input as a string but does not work for cell arrays of objects (see this question).
str2func returns a function handle with a string as input but does not enable access to attributes.
findobj returns objects given an array of objects to iterate over which I do not have. Might there be a method returning all workspace variable handles as an array?
Thanks!
This is exactly what eval is for. Yes, you should avoid using eval, but if you want to have a user type in stuff to be evaluated, you need eval. Or evalin if you want to evaluate it in the base or caller workspace rather than the current workspace.
There are no such thing as "object handles" (except graphics objects, but that is not what you are talking about here). There are variables owning arrays of data, that is it.
If you don't trust your users, don't use eval. They could type in anything, including clear all or !\rm -rf /* (or whatever the Windows equivalent is to erase the disk).
In this case, and presuming there is a limited set of variables that the user can specify, do
var1 = 1;
var2 = 2;
varnames = {'var1','var2'}; % Simulink.Parameter objects existing in workspace
objects = cell(size(varnames));
for i = 1:numel(varnames)
objects{i} = get_variable_value(varnames{i}) % Store objects in a cell array
end
function val = get_variable_value(name)
switch name
case 'var1'
val = evalin('caller',var1);
case 'var2'
val = evalin('caller',var2);
otherwise
error('Illegal variable name')
end
I defined a class in one of my many MATLAB packages. To my suprise, I could not access a constant property of my class without importing the class definition. Even if it is a method of the class itself. Like so:
classdef TestClass
properties( Constant )
c=0;
end
methods
function obj = TestClass()
end
function getC(obj)
import test.TestClass;
disp(TestClass.c);
end
end
end
I just want to check whether I am doing something wrong here or is this the correct way to use constants in MATLAB.
Since you have placed TestClass inside a package Matlab needs to know where to look to find the definition for this class, even if it's a reference from within the class or function. An alternate to the above code could be:
function getC(obj)
disp(test.TestClass.c);
end
Alternately, if within a class, constant values can be accessed from the object itself.
function getC(obj)
disp(obj.c);
end
If neither of these is working for you, you may need to refresh the classdef for TestClass from memory. This will cause matlab to reload the constant value, which is pulled into Matlab when it first parses the classdef file to determine the structure of the class. This can be done using clear classes, however a warning that it will also clear all other classes, variables, and any breakpoints you have set.
If you want to see if this is necessary you can view the metaclass object to determine what Matlab "thinks" your class structure should be. You can do this using the following.
mc = ?test.TestClass;
mc.PropertyList
You may need to index into the property list to find the specific property you are interested in, but the thing you are looking for are the following fields.
Name: 'c'
Constant: 1
DefaultValue: 0
i have a class called sampleClass with a cell array member variable called list.
Now i am trying to add elements to the internal list. For this purpose, i created the method addToList. The method simply tries to add elements to the list.
classdef sampleClass
properties
list = {}
end
methods
function addToList(obj)
obj.list{end+1}='test';
obj.list
end
end
end
Now the problem is, that the elements are not stored in the list.
Inside the function addToList the following output signalizes that the element is stored in the list:
>> samp = sampleClass();
>> samp.addToList
ans =
'test'
But after leaving the function, the element is no longer accessible:
>> samp.list
ans =
{}
Has anybody an idea what's going wrong? I am using Matlab 7.11.0 (R2010b).
Thanks for your help.
Julien
That's because you forgot to inherit from the handle class:
classdef sampleClass < handle %// Change here!
properties
list = {}
end
methods
function addToList(obj)
obj.list{end+1}='test';
obj.list
end
end
end
If you want to retain the changes made when modifying an instance of your class, you must inherit from the handle class. This can be done by taking your class definition (first line of your code), and doing < handle. If you don't, then any changes you make will not be saved. To show that this works, this is what I get in MATLAB:
>> samp = sampleClass();
>> samp.addToList
ans =
'test'
>> samp.list
ans =
'test'
To be more verbose, here's what the MATLAB docs say about handle:
The handle class is the superclass for all classes that follow handle semantics. A handle is a reference to an object. If you copy an object's handle, MATLAB® copies only the handle and both the original and copy refer to the same object data. If a function modifies a handle object passed as an input argument, the modification affects the original input object.
As such, you need to inherit from the handle class so that you have a reference back to the object you created. Any changes you make to the instance of your class will be remembered if you inherit from handle. If you don't, no changes you make get registered.
I am having a go at matlab object orientated programming. I have a class with properties. The properties are computed if they are NaN otherwise the property is returned.
So I have this section:
properties
some_property = NaN;
end
and a property is computed like this:
function some_property = get_some_property(obj)
if(isnan(obj.some_property))
% do some expensive computation
obj.some_property = ...;
end
some_property = obj.some_property;
A get_some_property method can be used by another get_some_property method. The problem is that between method calls properties are set back to NaN. This causes the error:
Maximum recursion limit ...
Any ideas? Thanks.
Your problem is that your class is not derived from handle, so it's passed around as a value. This means that when you call get_some_property, Matlab faithfully duplicates obj, giving a copy to the function get_some_property and keeping that separate from the copy of the code that called get_some_property. So, when you change some_property in the function get_some_property, it changes the property on the value of obj in the function, but not the property of obj in the code that called it.
There are two solutions to your problem. The best solution (IMO) is to derive your class from handle. Classes derived from handle are passed as references, so when you change the property on obj, it will change the property everywhere.
However, if you're unwilling to do this, then you can return obj from get_some_property:
function [some_property,obj] = get_some_property(obj)
And then call get_some_property in this way:
[property,obj] = get_some_property(obj);
This updates the value of obj in the calling namespace. It's both awkward and clunky; I would derive your classes from handle unless there's a good reason to avoid it.