Top x-axis disappeared in plotyy

I am using plotyy. It worked nicely until I added a title to the plot. Now the top x-axis has disappeared. What to do in order to make it visible?

[dpb]

Post an example of how you created the plot with the symptom...don't recall it ever failing w/ that symptom so no klew otomh, sorry...

If it's a complex plot, try going back to the beginning and adding features and see when the issue appears (presuming it's reproducible).

[perfectionist]

The matter is that when I remove the command line with which the problem arrived, i.e. adding the plot title, the top x-axis stays disappeared. My impression is that the top x-axis was a relict from the version before introducing plotyy. Can this be the case? Then the reason for the x-axis disappearing must have been the intermediate step of quitting MATLAB. Does that mean that plotyy regularly generates two ordinates but only one abscissa? There is no information about that in the documentation.

[perfectionist]

It is interesting that in the section "Create graph with two y-axes" all examples shown are without the top x-axis, which is different from the examples shown in the section "plotyy". However, both sections equally refer to the function plotyy. What is the reason for the difference?. How to create the second top x-axis reproducibly?

[perfectionist]

Still another interesting observation that further increases the axes-related confusion: Without changing the code, I made different calculations in which the axes limits always changed according to the input data. I have got two different versions of the plots (in each case with plot title): 1. without the top x-axis as described before; then there are two different ordinate scales with different ticks, as it should be. 2. WITH the questionable x-axis; then the right ordinate shows the ticks of the left and the right ordinate.

I should mention that before applying the plotyy command I have two quite normal plot(x,y) commands. Might there be an interference?

[dpb]

Again, we need to SEE what you have actually done, not just have it described.

plotyy creates two axes, there is no such thing as "two ordinates but only one abscissa". By default the two x-axes overlay each other visually so there may be the appearance of only one, but the axes are independent and complete axis entities; the only default difference is that the second axis has its ordinate labels on the right rather than the left.

I presume you've modified to place one of the x-axes at the top but that's only a presumption. It's quite easy with multiple commands onto a given figure to inadvertently place a component on top of another which hides its visibility or to address the wrong axes handle inadvertently. But, it's impossible to diagnose a problem without seeing just what it was that was done to create the problem, sorry.

ADDENDUM

Regarding the previous comment where you mention the difference between two example plots -- in the doc here, those are

plotyy(t,y,t,y,'plot','stem')
plotyy(t,z1,t,z2,'semilogy','plot');

and the difference when execute those two types here is that for the latter one gets

>> get(gca,'box')
ans =
off

whereas for the former it is

>> get(gca,'box')
ans =
on

WHY TMW chose to do it that way w/ semilogy as one of the function handles to plotyy I don't know; it isn't a fignewton of semilogy itself; perhaps it is an inadvertent issue (aka a bug); perhaps there is some logic behind it but it escapes me at the moment what that might be, granted. Anyway, adding box on to the axes may well solve your issue.

[perfectionist]

Thank you so much for your assistance. I understand that I should send the code I am using:

FIG1=figure;
plot(lgaXxsi,yepsilon,'ro','markersize',6);
hold on;
plot(lgaXxsi,ynorm,'bo','markersize',2);
[ax,~,~]=plotyy(xextrap,yextrap,xextrap,tion);
xlabel(ax(1),'lg a(X)');
ylabel(ax(1),'epsilon [mV/K]');
ylabel(ax(2),'t(ion)')
axis(ax(1),[xlimitA xlimitZ ylimitAA ylimitZZ]);
axis(ax(2),[xlimitA xlimitZ 0.0 1.0]);
ax(1).YTick = -2.0:0.2:2.0;
ax(1).XTick = -40.0:2.0:10.0;
ax(2).YTick = 0.0:0.2:1.0;
set (gca,'Title',text('String',[char(Author),' ',num2str(TK),' K']));
legend('y(exp)','y(norm)','y(norm,calc)','t(ion)','location',[0.2 0.3 0.1 0.1]);
print (FIG1,'-dpsc',RESFILE2);

[dpb]

W/o data can't execute yours, but I don't see anything terribly untoward there. I duplicate of the basics of

x=1:10;  y1=x.^2; y2=x*2;
plot(x,y1,'ro','markersize',6)
hold on
plot(x,y2,'bo','markersize',2)
hAx=plotyy(x,y1,x,y2)
Author='Anon'; TK=273.15;
set(gca,'Title',text('String',[char(Author),' ',num2str(TK),' K']));

I am, however, limited to R2012b; you have HG2 as can tell with the usage of the axis methods instead of set() but can't figure the ticks have much to do with anything altho again, you can leave as default to see if makes any difference.

As a general note, I'd probably do the above in the opposite order; that is, create the two axes initially by calling plotyy first, then plot into those specific axes handles...

hAx=plotyy(xextrap,yextrap,xextrap,tion);
set(hAx,'nextplot','add')  % "HOLD ON" for multiple axes
plot(hAx(1),lgaXxsi,yepsilon,'ro','markersize',6)
plot(hAx(2),lgaXxsi,ynorm,   'bo','markersize',2)
...

Then whatever cleanup, additions one needs subsequently should be less complex I'd think as the two axes limits should stay in synch as one presumes the two datasets are of approximately same magnitudes.

[perfectionist]

Thank you for your assistance. I followed your advice and got the following error message

Error using matlab.graphics.axis.Axes/set
While setting the 'NextPlot' property of 'Axes':
'on' is not a valid value. Use one of these values: 'add' | 'replace' | 'replacechildren'.
Error in nilireg4P5 (line 177)
set(ax,'nextplot','on');

Without understanding the background I additionally tried 'add' and 'replace' and 'replacechildren', but there was always an error indicated.

[dpb]

Sorry, I typed in comment box instead of pasting from command window; the 'NextPlot' property is indeed, 'add' to emulate the HOLD ON effect. It's done this way since have two axes and HOLD won't accept a vector of axes handles. It, i.e.,

set(hAx,'Nextplot','add')

is the same thing as executing

hold(hAx(1),'on')
hold(hAx(2),'on')

I just auto-rote typed 'on' for the hold form instead of 'add' for set. Shouldn't have any issue with

set(hAx,'nextplot','add')

If that continues, post the command used and the full, complete text of the indicated error.

As for the understanding, read the details under

doc hold

ADDENDUM

What do you get if you do something as trivial as the above? Does it still cause the issue? If not, that's also informative of where the issue must lie; it'd be in what's in your other case vis a vis the simpler.

Then, of course, the steps would be to add the additional details and see if the gremlins reappear.

[perfectionist]

Thank you for your effort.

Upon using your refined code I get the same as with my code, namely: 1. The top x-axis exists (as before; remember: sometimes exists, sometimes not)

2. The ticks of the left ordinate do additionally occur on the right ordinate (as before, when the top x-axis did occur)

3. the legend is corrupted (which I don't care at the moment)

In summary: it is the same as before.

[dpb]

OK, paste the example and attach the resulting plot illustrating the problem. To do the latter, "Save As" .jpg to a file and attach with the "Image" icon.

OH, just a thought; just for grins try changing the 'renderer' property to see if by any chance it's a figment of a graphics driver. Not likely, but always worth a try for such odd symptoms.

[dpb]

"2. The ticks of the left ordinate do additionally occur on the right ordinate (as before, when the top x-axis did occur)"

This is normal and unavoidable if the two axes (left and right) don't have the same number of tick marks; as noted above, plotyy creates two totally independent axes, they're just overlaid on top of each other.

If shown, tick marks are shown on both the left and right (or top and bottom) axis lines and there's not any property that control these two independently; they're either on/off. By default, plotyy will create the same number of tick marks on each axis, this will cause the two to overlay each other. If either is changed, however, then the ranges and number may change and then the two axes appear and tick marks aren't coincident. Unfortunately, TMW has never bothered to add the details internally to HG axes objects to allow for this level of granularity of control.

Just guessing, again, since you've resolutely failed to provide enough information despite all the prodding that we can reproduce your plot to see the symptoms, the presumption I have at the moment is that the hold on an addition of additional data has caused the ranges to change but I still can't see your terminal from here to tell precisely what you've done, sorry...

[perfectionist]

The code is:

FIG1=figure;
plot(lgaXxsi,yepsilon,'ro','markersize',6);
hold on;
plot(lgaXxsi,ynorm,'bo','markersize',2);
[ax,~,~]=plotyy(xextrap,yextrap,xextrap,tion);
xlabel(ax(1),'lg a(X)');
ylabel(ax(1),'epsilon [mV/K]');
ylabel(ax(2),'t(ion)')
axis(ax(1),[xlimitA xlimitZ ylimitAA ylimitZZ]);
axis(ax(2),[xlimitA xlimitZ 0.0 1.0]);
ax(1).YTick = -2.0:0.2:2.0;
ax(1).XTick = -40.0:2.0:40.0;
ax(2).YTick = 0.0:0.2:1.0;
set (gca,'Title',text('String',[char(Author),' ',num2str(TK),' K']));
legend('y(exp)','y(norm)','y(norm,calc)','t(ion)','location',[0.2 0.3 0.1 0.1]);
print (FIG1,'-dpsc',RESFILE2);

The two different versions of the attached figures were generated just by entering different numbers for "xaxext". "xaxext" defines the extension of the x-axis to the right. The code is:

xlimitA=round(min(lgaXxsi),0)-2.0;
xlimitZ=round(max(lgaXxsi),0)+xaxext;

Figure1 (with top x-axis; right y-axis with ticks from left y-axis) was obtained with xaxext=1.0. Figure2 (without top x-axis; correct right y-axis) was obtained with xaxext=0.0.

[dpb]

You still didn't give enough data to be able to easily recreate anything that matches -- don't know what the ranges are so can't do anything meaningful in trying to match what is causing your issues.

I do suspect it has to do with the previous comment but until can duplicate the symptom can't really provide a solution.

At a minimum, the ranges of each of the vectors you're plotting would suffice; simplest would be to have a complete sample can just run directly using (say) some random values over those ranges. Also, what are the bare minimum lines required before the symptom appears the x|ylabel I presume make no difference? Let's pare it down to the essence, iow.

Also, you didn't hit the "Attach" button in lower RH corner apparently; your figures didn't show up.

I had a much longer reply including trying some to try to guess-plicate the results but we're rural and have had a series of power outages this AM and it got me last time so I gave up.

I'm willing to help but give me some help here... :)

ADDENDUM

Besides the x ranges being same, it would likely help if the y ranges are consonant with your data as well. As said before, I'm suspecting it's tied in with the use of hold on as well as the changing of the axis limits; seeing it operate on those same limits is, perhaps, key in both reproducing and solving the problem. At least, I'm not willing to spend time trying without the detail I think needed to have a chance of success, particularly when it's would be so trivial to do so...

ADDENDUM 2

BTW,

xup=round(max(x));

will always be < max(x) unless max(x) is integer-valued or the fractional part is >0.5. So when your dx is 0, your x-limits won't cover the full data set. You're probably looking for

xup=ceil(max(x));

for positive values of x.

Also, you don't define the ylim variables you computed(?) I suppose also somewhat similar to the x-axis ones.

Again, as I've suggested a number of times, create a small, reproducible in its entirety w/o relying on something else we don't have example and paste it in.

Shouldn't take more than 10 lines or so...

ADDENDUM 3 :)

BTW, if you do post an example case and don't hear back for a while, "not to worry!". My next couple of days are pretty much spoke for so won't be having much time until later in the week...I'll try to catch a moment to check and if it seems easy-peasy maybe, but if it is going to take some digging, it'll likely have to wait...

[perfectionist]

I wrote a test file that only contains the commands aiming at the generation of the figure. Here it is:

function test(xaxext)
load('InputTest.mat');
xlimitA=ceil(min(lgaXxsi))-2.0;
xlimitZ=ceil(max(lgaXxsi))+xaxext;
ylimitZ(1)=round(max(yepsilon),1)+0.1;
ylimitZ(2)=round(max(yextrap),1)+0.1;
ylimitA(1)=round(min(yextrap),1)-0.1;
ylimitA(2)=round(min(yextrap),1)-0.1;
ylimitZZ=max(ylimitZ);
ylimitAA=min(ylimitA);
RESFILE2='/Users/nafe/Documents/Disk1/Mathematics/MATLAB/ML-Computation/Regression/Non-Linear/figure1.ps';
FIG1=figure;
plot(lgaXxsi,yepsilon,'ro','markersize',6);
hold on;
plot(lgaXxsi,ynorm,'bo','markersize',2);
[ax,~,~]=plotyy(xextrap,yextrap,xextrap,tion);
xlabel(ax(1),'lg a(X)');
ylabel(ax(1),'epsilon [mV/K]');
ylabel(ax(2),'t(ion)')
axis(ax(1),[xlimitA xlimitZ ylimitAA ylimitZZ]);
axis(ax(2),[xlimitA xlimitZ 0.0 1.0]);
ax(1).YTick = -2.0:0.2:2.0;
ax(1).XTick = -40.0:2.0:40.0;
ax(2).YTick = 0.0:0.2:1.0;
set (gca,'Title',text('String',[char(Author),' ',num2str(TK),' K']));
legend('y(exp)','y(norm)','y(norm,calc)','t(ion)','location',[0.2 0.3 0.1 0.1]);
print (FIG1,'-dpsc',RESFILE2);
end

For running you need the input data attached as InputTest.mat

The result is always a plot without the top x-axis and with the two y-axes having their own scales, independent of the value of xaxext.

That means test cannot produce plots with and without the top x-axis, depending on the value of xaxext, as they can reproducibly be produced by means of my original program.

The difference between my original program and test is that in my program the vector size of xextrap, yextrap and tion changes with xaxext as a consequence of the commands:

xlimitZ=ceil(max(lgaXxsi))+xaxext;
xextrap=transpose((xlimitZ:-0.1:xlimitA));

That means, the vector size of the variables to be plotted changes with the limits of the x-axis for the figure. Unlike the situation in my original program, in test the vector size of xextrap, yextrap and tion is fixed, namely by the input.

So, the big question is: what is the impact of the vector size of xextrap, yextrap and tion on the appearance of the figure?

Answer 1

[dpb]

OK, now we have enough to diagnose the real problem -- turns out didn't need so much but without something that could run to illustrate your concern didn't know exactly what the issue really, really was/is...

Anyway,

That's the symptom I described "way back when"... :)

A) box on will restore the top x-axis if it isn't displayed. As noted, why it's left 'on' in some instances and 'off' in others is buried in the internals of HG that have no way to ascertain but restoring it to 'on' will fix the issue. If you want the axis shown, then it can't hurt to force it irrespective. This one is, as I think I mentioned also, probably worth an official bug/interpretation request to TMW.

B) This is the other one I previously outlined. Unfortunately, you can't eliminate the dual tick marks on the right axes as long as you force having a different number of tick marks and non-consistent spacing because there are two independent axes objects and TMW didn't include the facility to separate the tick marks on the LH and RH axes (or top or bottom either, for that matter) as independent properties; they're both on or both off.

ADDENDUM It just dawned on me the reason for A -- it's because the internal logic is "smart". It recognizes the discord between y tick mark locations on the two axes and so turns off the box for both axes so the duplicated and non-matching y-ticks don't confuse. BUT, this has the side-effect of turning off the upper x-axis as well.

I turned your function into a script so had access to the variables at the command line (or you can just use the debugger and stop inside) but try

set(ax(2),'box','on')

to see what happens, then toggle it back off and switch axes.

I don't think the lengths have anything to do with it other than whether by happenstance you end up with the same number of y ticks or not; that will, I'm virtually certain, be the key point.

I've got the "high-priced consultant" coming in at noon; gotta' run now but I'll try to check back later on to see if you've other issues/concerns.

Oh, one last thought -- I don't have time now to do it, if you really, really, really must have the top x axis, you can either just draw the tick marks if that's all needed (no labels) or add yet another axis object that overlays these with x-axis at the top. I think that'll work altho there may be some issues of transparency to make all levels show thru. To see "issues", try

axes(ax(2))
axes(ax(1))

and likely the legend will become occluded.

Oh, one last thought, given your moniker... :) I've complained for almost 30 yr and TMW hasn't fixed it yet, but the mismatched formatting on the axis tick labels just bugs me no end. I'd add

ytk=get(ax(2),'ytick').';                    % retrieve tick values
set(ax(2),'yticklabel',num2str(ytk,'%.1f'))  % set with consistent formatting

You can, of course, dispense with the temporary ytk by folding into the num2str argument but it's far easier to write initially as above. BTW, do NOT forget the transpose; you won't like the results otherwise! :)

Good luck, hope that 'splains the problems/issues...they're pretty much inherent w/ HG. An enhancement request never hurts.

ADDENDUM

As is so often the case, the real solution just came to me--

set(ax(2),'xaxislocation','top','xticklabel','')

and you can "have your cake and eat it, too!" :)

This will put the RH axis at the top and have the same net effect on the top tick marks as does 'box','on' but without the side effect of turning on the other ytick. Setting the tick labels to null string keeps them from showing up; if leave on you'll need to make that fixup before using title so it is written above them, otherwise they'll clash for room.

[dpb]

BTW, the description isn't quite proper for the axis ticks--they are separable, but it's done by the opposite axes being tied to the box outline for the opposing x- and y- axes from the location of the main axes for the given axes object. Thus, you can avoid the mismatch in two y-axes but there's no outline nor opposite x-ticks, either. It needed that box outline and the ticks (x- and y-) all be independent features.

[dpb]

OK, one more thing came to me while cleaning up that may help to understand HG axes objects ... from the command line just enter

figure, axes  % make empty axes in new figure
get(gca,'box')% note default is 'off'

set(gca,'box','on')  % turn bounding box on

NB: not only is the outline shown, but the tick marks are as well. Now, w/ plotyy there's two independent sets on top of each other; hence the interference.

As said, 'box' should just be the outline and there should be another property to show opposite-side ticks or not for the x- and y-axis--but there aren't so you're stuck w/o other workarounds.

By default plotyy solves it by ensuring the two y axes tick locations coincide; you've broken that by forcing the number and spacing on each so unless your algorithm happens to return the same number, they'll conflict with each other.

Oh, one other possible way to "fool" plotyy -- compute the maximum/minimums as you want them and incorporate them into and additional vector with NaN x- or y- values for the opposite axis and let the automagic scaling take over. That might give you something approximating what you're doing now with even spacing, don't know for sure.

Alternatively, of course, you can do the details of the scaling plotyy does and find a matching set. Note that to do this you have to work over setting up the tick marks at the same distances from the boundaries of the plots whether you actually put the initial tick at the limits or not. What you can't do is arbitrarily draw y ticks on both axes and still use the builtin 'box' property to show the x-axes at the same time.

All in all, the easiest solution is probably the one previously mentioned of manually fixing up the upper x-axis...

[perfectionist]

Bingo!!!!

With:

set(ax(1),'box','on');

I always get the top x-axis even in those numerical cases in which I failed to get it before.

The matter with the double scaling on the right y-axis is certainly excusable. Now, that I know what a "high-priced consultant" is thinking about it, I am quite happy with my result.

BTW, your advice with handling the y-ticks was not really helpful.

Thanks ever so much. Your help gave my certainty about that I did not make a primitive mistake.

Greetings from Stuttgart, Germany.

[dpb]

"BTW, your advice with handling the y-ticks was not really helpful."

I'd be interested in knowing more of what you mean with the above comment????

Glad it explained the other phenomena; the earlier issue was that I wasn't sure it was that simple and not a fignewton of the new HG2 engine which was what required being able to try to duplicate your actual case...otherwise, thought possibly would be "right answer, wrong question".

[perfectionist]

"BTW, your advice with handling the y-ticks was not really helpful."

What I wanted to say with the comment was that I did not realize a change in comparison with what I had before. However, I have to admit that I stopped pursuing that matter, I stopped trying this and that and was satisfied with what I had achieved.

You mentioned my moniker. BUT, please consider that I am a scientist rather than an IT specialist. I use MATLAB as a (highly useful) tool, implying that programming is not the explicit objective of my doing.

[dpb]

OK, wasn't wanting to leave you with a feeling of dissatisfaction if possible to resolve a question.

Re: the moniker, I was just commenting on it implying desire for "clean" graphics which is perfectly reasonable objective, particularly if one is trying to prepare presentation-ready graphics. The example of the mismatched formatting for tick labels is one that bugs me so that feel some tendency in that regards myself. :) My use of Matlab was pretty much the same way; I've since retired from active duty and this is "play" to keep in hand and that I simply do enjoy fiddling with such issues to try to find these workarounds as an intellectual challenge if nothing else.

Answer 2

[dpb]

The subsequent answer buried at the end of the long previous discussion is, I think, so significant I'll repost it here alone--

The real solution just came to me--

set(ax('box','off')  % turn box off both axes for sure...
set(ax(2),'xaxislocation','top', ...
          'xticklabel',[])  % move RH x axis, clear tick labels

and you can "have your cake and eat it, too!" :)

This will put the RH axis at the top and have the same net effect on the top tick marks as does 'box','on' but without the side effect of turning on the other ytick. Setting the tick labels to null string keeps them from showing up; if leave on you'll need to make that fixup before using title so it is written above them, otherwise they'll clash for room.

With this, I created a figure with two subplots, one with and one without the upper labels...

In the close spacing of the subplot the upper title still interferes with the labels altho it didn't as a single plot if added after the setting of the xaxis position property.

Also with subplot I had to set 'box','off' explicitly on LH axis whereas for the full-size plot the internal logic left both 'off'.

I dropped the legend for lack of room and of no real interest to the question at hand, anyway...

[perfectionist]

I am sorry to diappoint you. If I cancel the line

set(ax(1),'box','on');

and add

set(ax(2),'xaxislocation','top','xticklabel',' ');

The problem is the same as before: The appearance of the axes (with or without top x-axis; with or without double ticks on the righthand y-axis) depends on the input of xaxext.

I highly appreciate your enthusiasm, really ...

I think MATLAB has enough powerful features, but it will certainly not be competitive with other plotting programs (considering the time necessary in order to settle the most trivial issues).

[dpb]

Just removing

set(ax,'box','on')

isn't enough.

If you

set(ax,'box','off')

the double y-ticks will disappear, I'm certain.

As noted, there's a case where the default result is with one 'on', one 'off' which will leave the double y-ticks visible for the axis which is 'on' (typically what I've observed here is LH 'off', RH 'on'. With this solution as opposed to the previous of using 'on' to force the x-ticks but living with the y-tick being visible, you must ensure both are 'off'.

I agree with your assessment of HG; as compared to several other alternatives it remains klunky at best and is quite frustrating at times.

As said, at this point having retired from technical consulting after returning to family farm it's cheap entertainment for me...I'm easily amused! :) OTOH, when trying to solve a problem for a real application or client, it can be a royal pit[proverbial]a[ppendage].

The appearance dependent on the parameter has to do with how the intervals are set and what the triggers in the number and spacing of the ticks and which condition ends up (of the four possible) with respect to 'box' state.

To see this, for diagnostics put in

get(ax,'box')

after the plotyy and before any set call to see the state as left.

ADDENDUM

I just ran the specific test here between the two values of the x-axis extension factor and do see the same effect with default behavior for 'box' as you describe. The state at that point is

>> get(ax,'box')
ans = 
  'on'
  'off'
>>

which is the LH axis box is 'on' so its ticks will show on the RH axis as well as the base ticks for the second (RH) axis. Since the second axis box is 'off', its opposite axis ticks won't show so the LH axis looks normal.

At this point if one executes

set(ax(1),'box','off')

the extra ticks on the RH side go away but the top x-axis disappears because now NEITHER axis box is 'on' so the opposite (now top) x axis ticks aren't shown for either.

I recommend using

set(ax,'box','off')

however, to ensure they're both off just in case HG were to ever return the other state of either both on or RH on and LH off

Now, if one subsequently moves the x-axis for one or the other axis to the 'top' position, then you have the desired result. The end sequence is then

plot(lgaXxsi,yepsilon,'ro','markersize',6);
hold on;
plot(lgaXxsi,ynorm,'bo','markersize',2);
ax=plotyy(xextrap,yextrap,xextrap,tion);
set(ax,'box','off')  % turn both boxes off for sure...
axis(ax(1),[xlimitA xlimitZ ylimitAA ylimitZZ]);
set(ax(1),'XTick',[-40.0:2.0:40.0])
set(ax(1),'YTick',[-2:0.2:2])
set(ax(2),'xaxisloc','top','xticklabel',[])
axis(ax(2),[xlimitA xlimitZ 0.0 1.0]);
set(ax(2),'YTick',[0:0.2:1])
xlabel(ax(1),'lg a(X)');
ylabel(ax(1),'epsilon [mV/K]');
ylabel(ax(2),'t(ion)')
title(ax(2),[char(Author),' ',num2str(TK),' K']);

I rearranged a little to basically do what needs to be done on each axis together as a group with the plotting and limits, etc., done first then follow with the labels and titles, etc. It doesn't really matter, just seems a little more organized to me in that order.

The key here to get the effect you're looking for are the two lines that

1. Turns the 'box' off for both axes for certain, and
2. Moves the second axis x-axis to the top

Within the latter I've shown eliminating the labels for it; if want them then just remove the 'xticklabel' parameter/value pair.

NB: the 2nd axis handle in text -- this is the key to making sure the title doesn't overlap the x-axis labels if they are displayed; by default gca is LH axis and so is written to it which has the x-axis at bottom so doesn't know to leave room. I'd forgotten to include the handle earlier.

[perfectionist]

I copied your code into my program, was asked to remove some of the brackets, removed the respective old lines, and ran the code:

I got nice y-axes with separate scales, BUT no top x-axis.

[dpb]

Peculiar, indeed.

That would seem to indicate a bug in HG2, then. Just out of curiosity, what do

get(ax,'box')  % and
get(ax,'xaxislocation')

return?

It's also somewhat puzzling what brackets would need removing (in fact, which could be removed without resulting in a syntax error). Which line(s) would that have been and what was the end line in place?

What's the result of

>> ax=plotyy(xextrap,yextrap,xextrap,tion);
>> get(ax,'box')
ans = 
  'off'
  'off'
>> get(ax,'xaxisloc')
ans = 
  'bottom'
  'bottom'
>> set(ax(2),'xaxisloc','top')

from the command line? Above is here and the resulting plot is as expected/desired...if the result of

>> get(ax,'box')

includes an 'on' response, then set it 'off' and see if that causes the x-axis to disappear, too. That would definitely be a bug and should be reported to TMW. If there were a 'box', 'on' result, that would be the case where also there would be a duplicate set of y-axis ticks showing, of course, as well.

ADDENDUM

Oh, just one more thought came to me -- I wonder it it's a layering issue where one axis is overlaying the other and doesn't let it show through and that's different between HG and HG2 for some reason. See what happens if move the x-axis for ax(1) to 'top' instead of ax(2). Either way, if the above simple test show up as you describe still, it's an issue TMW needs to fix; that should not be. And, if it does, it should, it seems, also be so for random x,y data irrespective of anything else.

[perfectionist]

in the lines

set(ax(1),'XTick',[-40.0:2.0:40.0]);
set(ax(1),'YTick',[-2:0.2:2]);

I am asked to remove [ and ].

The commands

get(ax,'box')  % and
get(ax,'xaxislocation')

return

    'on'
    'off'
    'bottom'
    'bottom'

With

'off'
'off'
'bottom'
'bottom'

the top x-axis really disappears.

With

set(ax(1 ),'xaxisloc','top');

the bottom axis disappears. Yes, I think it's an overlay issue.

[dpb]

Ah, that's just an editor suggestion; didn't think about tick vectors as I don't have the methods here so I had to convert those to set. OK, that's understood.

OK, I understand the sequence to the point "the top x-axis really disappears." That's what should happen at that point.

If you at that point

set(ax(2),'xaxisloc','top')

does the top x-axis not then appear?

If, at that point it isn't visible I'm pretty much w/o being able to put my hands on the actual system convinced it is a bug.

"With set(ax(1 ),'xaxisloc','top'); the bottom axis disappears. Yes, I think it's an overlay issue."

This was my last idea; swap the two such that

get(ax,'box')  % and
get(ax,'xaxislocation')

(will hopefully) return

    'off'
    'off'
    'top'
    'bottom'

instead of what I'd been attempting which was the last two items switched. But, either way, need to make sure your end result is with one top, one bottom or there's no chance.

If at that point it still won't show both x-axes I think it should be packaged and submitted as bug to TMW at the official support site www.mathworks.com from all I can tell from here lacking HG2.

It does work as expected here w/ R2012b which is still original HG, not HG2.

Sorry I don't have any better news; it should work I'm convinced.

[dpb]

Just as sanity check I redid the test here from command line...

>> ax1=plotyy(xextrap,yextrap,xextrap,tion);
>> get(ax1,'xaxisloc')
ans = 
  'bottom'
  'bottom'
>> set(ax1(2),'xaxisloc','top')
>> get(ax1,'xaxisloc')
ans = 
  'bottom'
  'top'
>> set(ax1,{'xaxisloc'},{'top';'bottom'})
>> get(ax1,'xaxisloc')
ans = 
  'top'
  'bottom'
>> set(ax1,{'xaxisloc'},{'bottom';'top'})
>> get(ax1,'xaxisloc')
ans = 
  'bottom'
  'top'
>>

Swapping back and forth makes no difference, both are viewable either way and the above is the following figure...

<<

>>

[dpb]

Oh, just one last thought...

What does

get(ax,'color')

return when x-axis not visible on the base trial? Wonder if by some chance the 'none' setting for the second axes could have gotten mucked upon....but then would think the lines wouldn't show up on ax(1), either....real long shot.

Answer 3

[Image Analyst]

Perhaps you'd like this, or an adaptation of it:

http://www.mathworks.com/matlabcentral/fileexchange/317-plotxx-m

[perfectionist]

No, I wish to have two different y-axes and two identical x-axis, one at the top and the other on the bottom.

[dpb]

Use the same x data on both plots and the above would probably do so. I'd guess it's essentially the same thing trying to do above with two axes overlaid also with one 'top' the other 'bottom' so perhaps the same bug will be uncovered.

[Image Analyst]

Well, it was worth a shot. I didn't read the whole extensive discussion above, so I don't know the background, but it sounds like you want plotyy and that is what dpb is working with you on. Good luck.

[dpb]

I just looked at the source for plotxx and it's a very simple two-axes routine the guts of which boil down to

ax(1)=gca;
....
ax(2)=axes('Position',get(ax(1),'Position'),...
 'XAxisLocation','top',...
 'YAxisLocation','right',...
 'Color','none',...
 'XColor','r','YColor','k');
set(ax,'box','off')

the settings for the 2nd axis vis a vis the first are identical as to what have been doing with plotyy (other than the hardcoded axis colors which is pretty user-belligerent there).

It's looking to me more and more like there's an issue with HG2. Do you have it, IA? Can/would you try perfectionist's sample above if so? Given the longwinded conversation, here's the link to the comment where the basic function was posted and there's a link to the data file at the bottom so you don't have too much hunting to do to find it.

Test Function Link