Error using figure: First argument must be a figure object or a positive Integer

temp = uint32(1);
figure(temp);

Gives:

Error using figure
First argument must be a figure object or a positive Integer

If anything, 'temp' is definitly a positive integer. What is wrong? (Fix it Mathworks...)

[Jochem Bonarius]

it works when I do

figure(double(temp))

But it would be insane if that was the correct solution: casting an integer to double in order to produce an integer....

[Stephen23]

"But it would be insane if that was the correct solution: casting an integer to double in order to produce an integer...."

Not really. MATLAB's default class is double, and most internal processing uses double. Some operations only work with double, e.g. adding double scalars to arrays of any class or size. With MATLAB only use integer classes if your algorithm specifically require them. For this trivial code there is no memory or speed advantage to using integers types, so there is no real reason for you to complicate your code and use a non-default class for that value.

For no obvious reason you decided to make your code more complex than it needs to be. Why not just do this?:

temp = 1;
figure(temp);

It works perfectly.

[Jochem Bonarius]

@Stephen Cobeldick becasue the uint32 values come directly from a MySQL database (not mine to change). As a programmer it sounds insane that I have to recast these to double in order to get a 'mathematical integer' between 1 and 2^31-1. IMHO figure should just as well work with an int-type. I haven't encountered this using R, Python or Mathematica...

[Stephen23]

"I haven't encountered this using R, Python or Mathematica..."

Sure, because other languages have their own "features", e.g. Python's default of integer division, which was a much more significant "feature" that caused far more people problems than this "feature" of MATLAB's. Both are documented too!

Comparing "features" like this is likely to be an endless game that no one wins.

"IMHO figure should just as well work with an int-type."

I totally agree. You should make a feature request: click "My Service Requests" at the bottom of this page:

https://www.mathworks.com/support.html

Answer 1

[Pawel Jastrzebski]

The doc says the input argument must be of double type:

[Jochem Bonarius]

Thank you. Then the error message is incorrect. It gets worse when you type

figure(3.1)

Gives:

Error using figure
Single input must be an existing figure handle or a scalar integer from 1 to 2147483646

Clearly the function expects an int32 type. Too bad 'figure' is a build-in function. Else I could correct this madness myself...

[Stephen23]

"Clearly the function expects an int32 type. "

Not at all. According to the figure help it expects a double class.

If you have a background in programing then perhaps you conflate integer with some kind of integer class, e.g. uint32. But this is MATLAB, a language based on something called mathematics, where integer refers to a numeric value with no fractional part. Because that is actually the definition of integer. If a function requires a particular class of variable, then the help will say so.

If you have a programming background then forget everything that you know. Programmers who try to write MATLAB as if it was C++/Java/yourFavorite always end up writing inefficient code and wasting time tilting at windmills.

[Star Strider]

If you want to call your figure ‘Figure 3.1’, this works:

figure('Name','Figure 3.1', 'NumberTitle','off')
plot((1:10), randn(1,10))
grid

You can give it figure handle if you want to refer to it later:

fig31 = figure('Name','Figure 3.1', 'NumberTitle','off')
plot((1:10), randn(1,10))
grid

See the documentation on figure (link) for this and other options.

[Jochem Bonarius]

@Stephen Cobeldick I'm actually quite proficient with MATLAB. I'm even teaching it to students at my university. But I'm also a programmer and from that perspective it's very stupid that a function that wants a 'mathematical integer' between 1 and 2^31-1 would not accept a uint32.

[Ilmari Pohjola]

@Stephen Cobeldick In mathematical literature integers are usually not defined at all like that. in Wikipedia the first sentence is misleading. Indeed integers "can be written without a fractional component" and one can interpret this as the definition as the sentence as a whole is not unambiguous. Wikipedia is Wikipedia. Mathematics always aims at unambiguous formatting of definitions. Depending on the field of mathematics, integers migth have different definitions which all are unambiguous and probably all of them are equivalent.

From a theoretical mathematical point of view the functioning of Matlab is not obvious. I'm working in a research group in applied mathematics with Matlab, and just like all the other languages, you have to learn to use it and it is really good at some things. There is no problem with anything else here, but the error message. Matlab Documentation lists it's integer types and none of the is a double without a fractional part. Figure does not expect the input to be integer but double as the accepted answer points out so the error message should not be as it is. This would be reasonable from all aforementioned reasons.

[Jochem Bonarius]

Excactly my point.

But I get where this is coming from. Before I became a scientist, I spend 8 years in software development. What I know from this experience is that software engineers are very convinced about the way they solved a problem. However, usualy they are not so good with users. That's why thriving companies have UX designers and markering/product managers to steer SW developers. Further more, SW developers do not like to admit they did something wrong, as that will mean they will have to fix it=more work.

In this case, SW engineers found some SW solution for handling multiple figures, by using "handles" to objects. Very nice for SW engineers.... but us scientists and mathematicians just want to use numbers! We don't want to maintain a software structured database of figure objects. We want to draw figures to display our data and put them in articles.

So for the Mathworks SW engineer reading this: please call a UX designer to help you make a nice interface for your users.

[Jan]

"scientists and mathematicians just want to use numbers!"

No. Computers and programmings languages are tools. Many scientists have learned to use tools carefully. Using numbers to address GUI elements is like using a drilling machine to pull a nail into the wall. There have been ambiguities with using doubles to identify GUI objects:

plot(X, Y)

could be misunderstood, if X is a scalar and contains a value, which accidentally equals the handle of an axes object.

With the GUI handle objects these problems are solved. Writing stable and clean codes is or should be the vital interest of scientists and mathematicians. Of course, I have seen many scientists also, who simply do not care about code quality. I've see programs written for a PhD, which do not care about software engineering, documentation, unit-testing and maintainability.

The only problem here is, that the error message was missleading:

First argument must be a figure object or double with a positive Integer value.

That a user misinterpretes "positive Integer" with an integer type, is not really likely. At least one would take a look into the documentation, because there are many integer types: (U)INT8/16/32/64. So chosing just one of them an hoping, that it is the expected one, looks naiv.

[Jochem Bonarius]

@Jan

but a figure object is not a scalar, isn't it? At least I hope not. Else it would be very easy to mix things up.

And of course many programs written for a PhD do not care about the things you mention. As a SW engineer in a company you get judged by your code quality, etc. As a PhD student you get judged by your scientific output, which is journal publications. Usually nobody cares about your code (only if somebody continous your work, but that's usually not you problem).

But anyhow, the way most people I know change figures to plot is just:

figure([nr]); plot(X,Y);

They do not use handles.

And the interger problem you mention: most other languages have no issue with this (python, C++, Java, etc.). Why does Matlab have to be so different??

[Steven Lord]

but a figure object is not a scalar, isn't it? At least I hope not. Else it would be very easy to mix things up.

One figure handle is a scalar. A vector of figure handles is not.

f = figure;
isscalar(f) % returns true

f(2) = figure;
isscalar(f) % returns false

The only time the isscalar function cares about the class of its input is when the class of its input has specifically overloaded isscalar (and that's a somewhat uncommon situation, in my experience.) Before the graphics system update in release R2014b figure handles were stored as double arrays and isscalar accepted (and still accepts) them. Since the graphics system upgrade figure handles are actual handle objects, and isscalar accepts them.

But anyhow, the way most people I know change figures to plot is just:

figure([nr]); plot(X,Y);

They do not use handles.

And nr must be a double precision integer value.

And the interger problem you mention: most other languages have no issue with this (python, C++, Java, etc.). Why does Matlab have to be so different??

This predates the start of my tenure at MathWorks by quite a bit, but the figure function predates the introduction of the integer data types (and I believe even single precision) to MATLAB. The figure function exists (and accepts a handle as input to make a specific figure active or to create that figure) in MATLAB 4.0 (from 1992) but there doesn't appear to be any integer data types in that release (at least looking for help text.) I'm not sure if figure was introduced in MATLAB 4.0 or in an earlier version, but that's as far back as I can easily check.

The picture's not quite clear to me exactly when uint8 was added to MATLAB, but I have found a reference in the MATLAB 5.3 (release R11) Release Notes to the introduction of additional integer classes beyond "the existing uint8 class".

We introduced the 64-bit integer types in MATLAB 6.5 (release R13.)

So my guess is that there hasn't been enough demand for figure to accept non-double integer values in the 20+ years since the integer types have been introduced for us to modify figure to accept them. If this is an important capability for your work, I recommend contacting Technical Support using the button with the telephone icon in the upper-right corner of this page and requesting this functionality.

[Jan]

@Jochem:

"And of course many programs written for a PhD do not care about the things you mention. [...] But anyhow, the way most people I know change figures to plot is just:

figure([nr]); plot(X,Y);

They do not use handles."

Exactly what I have said: This code lines are a common example for a bad programming style. Adressing figures by numbers is fragile. Better:

FigH = figure;
AxesH = axes(FigH);
plot(AxesH, X, Y)   % Or: plot(X, Y, 'Parent', AxesH)

So using handles for graphic objects is recommended and clean. By this way, Matlab cannot be disturbed by users clicking on another axes object during the code runs.

If using numbers to address figures is really "the way most people you know use", it is time to teach them how to use the smart and stable handles.

[Jochem Bonarius]

Yes... but you're reasoning like a (imho typical) software engineer again...

The only reason *I* know about object-oriented and handles programming because I did a course on OO some years /after/ I got an MSc in Electrical Engineering. I learned barely anything about it during my studies.

However, currently I'm working in a life-sciences project with people from Innovation Sciences and Biomedics, who also want to use matlab. They don't know what a (software) object and a handle is, nor do they care about it. And that should be OK, as they have other things to break their mind over.... They just want software to display their data.

"it is time to teach them how to use the smart and stable handles." <-- in my experience this is typical SW engineer reasoning. But you should remember: you are writing software for your users, not making users for your software.

[Jan]

@Jochem: If you drive a car, you have to care for the pressure in the tires, the oil in the engine and the working lights. This argument is not convincing also: "Oh no, I'm not a mechanic, I just want to drive from A to B. And by the way, what are the funny red/yellow/green ligts beside the road?" Unfortunately I have seen many code written in this level: A bunch of scripts, which are needed to be called in a specific order, while all data are stored in the base workspace. It is hard to reproduce the results and in conseuqence to suitable for scientific work.

If you use such a powerful tool as a programming language, it is required to learn at least the basics. This is not hard and you do not need to understand all details. Teaching a good programming style is easy:

% For plotting into a specific figure use:
FigH = figure;
AxesH = axes(FigH);
plot(AxesH, X, Y)

The user do not need to understand, what a "handle" is. Just copy&paste&adjust some example code is sufficient. It's like "Take D to drive" and it does not require to understand the engine.

But if a user insists on addressing figures by integer numbers, this bad programming style can cause troubles, which produce the need to understand, what is happening inside Matlab's engine. It is like pouring some oil in the fuel tank: Suddenly you are faced with unnecessary troubles. Using figures with numbers produce the need to understand, why "integer" means "integer value" and not "integer type".

By the way, I'm physicist and decided to write clean code, because I need reliables tools. One is used for clinical decision making in several labs and has > 300'000 lines of code. The tools are used and expanded by other scientists and e.g. physiotherapists. If some code is shared between the labs and based on using integer figure numbers, collisions will occur and they can cause severe errors, which are hard to reproduce and to debug. Therefore I've used an own object oriented method to address figures long before HG2 was introduced in Matlab. As you say: I'm writing software for users. And if it is a powerful tool, the users have to learn how to apply it corrrectly and safely.

I have the opinion, that a certain level of software engineering is required, if computers are used to solve problems. My grandma (not a software engineer) told me: "If you do something, do it right." She meant, that I have to clean up the tools after working in the garden, and that I have to use the spade if and only if a spade is the best tool.

Figure handles are the best tool. Avoid numbers (to be exact: scalars of type double with integer values).

[Jochem Bonarius]

Ah, yes, the driver only needs to know that becasue they /have/ to due to technology limitations... But actually, they would prefers not to! I mean, in the first cars you needed to oil the pistons and gears manually, and had to operate choke and even timing advancement manually.... But those days are long gone.vModern cars offer a lot a neat features like oil level warning (better then the idiot light) and wireless tire pressure sensors. If you would offer options on cars that you would never need to check oil level or tire pressure, people would gladly buy it!

Users don't want to be bothered with technicallities. They actually would like the computer to read their mind and do excactly what they want, without putting any effort into it.

But anyhow, let's agree to disagree...

[Jochem Bonarius]

One more thing

"% For plotting into a specific figure use:

FigH = figure;

plot(FigH, X, Y)"

Doesn't work. Just try it.

QED: so easy to get it wrong...It is just not user friendly.

Furthermore: if somebody closes the figure, it's handle disapears. If by accident, this could mean a script crashes. Could mean you lose a lot of simulation time. With the "figure(1);" method a new figure will just be opened... no crash...

[Jan]

@Jochem: You are right, the figure handle is not correct to define the parent of a plot command. Of course an axes is needed. This was a too sloppy translation of my own handle graphic objects, in which this call is valid. See my edited code. Thanks for checking this detail.

figure(1) will work. The original question concerned figure(uint32(1)). Then the actual problem was the error message, which can be misunderstood by a person, who is not familiar with the Matlab language.

Did you write an enhancement request, such that Matlab fixes the error message?