handles as integer or float
Status: Alpha
Brought to you by:
shaiay
Menu
▾
▴
This is a follow-up on Patch #1570627 and Feature Request #1570617, maybe it's better to discuss it here in the forum.
In matlab, "figure(5)" will create a handle of integer 5. "axes" will then create a handle of float. e.g 157.0013.
It seems like the figure object in matlab does not have a 'Number' property, the number is equal to the handle. I guess it reserves integer handles, or at least smaller integers, for figures such that the user can specify the figure number (=handle) without clashing with other objects.
I suggest doing something similar in octplot:
1) Shai suggested using negative integers for handles. We can then reserve the positive ones for figures, and map figure number/handle directly.
2) More invasive: Float handles like in matlab, positive integers reserved for figures.
3) Least invasive: Reserve integer handles below, say 1024, for figures. Just start the normal handle count at 1024 instead of 1(?) today.
Tormod
All of the options are not hard to implement.
About option #2, Do you have a suggestion on how to assign float handles -- i.e. what algorithm should I use to manufacture new floats? If there is a good algorithm -- i.e.
1. gives unique numbers,
2. is cross platform (i.e. does not depend on endianess)
3. allows a lot of numbers (i.e no wrap around)
I think I would go for it.
Shai
Shai
What about starting at 1.1 and increase by 1.0? Maybe not so elegant or clever, but should work for a lot of numbers.
Another option would be to access the float registers directly and do integer arithmetics on them, but that might be less predictable.
I don't know octave/matlab well enough to know what people might want to do with these handles, or what should be supported. I guess putting the handle in a variable and using it as a reference is all? And matching handle1==handle2 maybe?
I think you a right in that handles are only used for reference and maybe comparison.
both negative handles and 1.1,2.1,... handles are very simple to implement. Do you have any preference?
Shai
The 1.1, 2.1, ... approach will be very similar to matlab - that's my vote.
Well,
since you are the only voater so far, you seem to have won the elections :)
I will implement this
Shai
done in revision 372.
the handle of root is 0,
subsequent handles are 1.1, 2.1, 3.1, ...
Shai
Great! I am impressed at the speed you sort out any issue I can come up with :) What about figure handles, will you change them to be integers=number?
Well,
the current change was trivial, but going for special treatment for figures will really mess up the code. Is it really essential ?
Shai
It was the motivation for the change, wasn't? To reserve integers for figures. Maybe it's not too important, but you might have programs expecting:
figure(2)
get(2,'Children') % works in Matlab
Is everything float in matlab, so that what we see as integer X is just X.0000000 ? So to determine if it is an "integer" one would do the floor(x)==floor like you did in figure.m?
Would it mess up more than the attribution of handles to figures, letting figures have its own pool?
I don't know about matlab, but in octplot everything is float.
It would be messy to make figures have their own pool of handles.
Is the handle==figure number behaviour in matlab documented? If no then I will not do this in octplot since it could change. If it is documented, I will accept this as a bug, but I'll give it low priority
With the current octplot, you can give figure a handle or figure number and it will work as in matlab, which is an improvement
Shai
"figure(h) does one of two things, depending on whether or not a Figure with handle h exists. If h is the handle to an existing Figure, figure(h) makes the Figure identified by h the current Figure, makes it visible, and raises it above all other Figures on the screen. The current Figure is the target for graphics output. If h is not the handle to an existing Figure, but is an integer, figure(h) creates a Figure, and assigns it the handle h. figure(h) where h is not the handle to a Figure, and is not an integer, is an error."
This says clearly: figure(4) will create a figure with the handle 4. It doesn't say that all figure handles have to be integers though. In fact, there is a property "IntegerHandle" (Specify integer or noninteger Figure handle).
OK.
As I said before -- I would really not like to mess up my code to become compatible with some obscure feature (be it documented or not) of matlab, especially since the "figure(n)" command now seems to be compatible, so unless you really want to look at value of the handle. it all works.
Do you think this feature is important enough to make octplot code messier (==harder to maintain)?
Shai
figure(n) is not fully compatible, since a new figure is not created in octave when needed. I am not sure I would call this obscure, telling from what I see people do in matlab: They create new figures using "figure" and learn to bring up the right window with figure(n). When they go on to write programs, they often create the figures with figure(n) so that they can be sure they will refer to the same window later. Of course they could have used handles instead, but users get used to the figure numbering scheme.
I would agree to call it messy or badly designed, yes :) But I think you are so close to full compatibility on the figure handling now, that I would have gone that extra mile! The important part was the float handles. You will be able to remove the 'Number' property as well, which helps reducing some code complexity.
- we will have to add the n to the figure octplot_command call in figure.m
- in Root::AddFigure we can actually use the existing number allocation for the handle,
but maybe move it somewhere else
- make a special GetNewHandle for figure objects? Or just overload the float one with an
integer one in Root:AddFigure - hmm then root's Children list must be updated
(here my OOP/c++ skills are coming short)
Tormod
I am sorry I did not make myself clear. I totally agree that figure(n) should create the figure "n" if it soes not exist -- this is not an obsecure feature and should be implemented ASAP.
My previous emails are all related to the problem is withh the figure handle==figure number scheme. This would mess up the code -- as you realised yourself inthe last step you proposed -- and I am not sure how much this low-level detail of matlab is used by people.
Shai