Retrieve legend handles and text (2024)

"I have not yet found any way to obtain the text handles of an R2014b or later legend that was not created with the [a, b, c, d] = legend() syntax."

This penchant TMW has developed of making internals totally opaque, while popular in CSci circles, certainly makes for customization of anything they haven't thought to make a method for either a pit(proverbial)a(ppendage) or just downright impossible. I, for one, truly dislike it to the point if I were deciding to get back int to the consulting game I'd likely choose to not update Matlab at all as I was always running into things (particularly with respect to graphics fine-tuning) that just aren't quite the way they need to be.

As a plus, and in their defense, they did introduce some new features (the ruler object for one) that does ease some longstanding issues such as setting axes numeric formats, but to remove some other things by the change in access whether intentionally or just as a side result seems overall a net loss. A little less effort in being able to fix up something even if took a little more effort before just doesn't seem to make up for other things disappearing entirely.

I just discovered another in interp1 that I have a ton of code that depended heavily upon--no longer does it interpolate columns of an array of Y values given a vector X as an array of interpolated values of that many columns; now you have to write a stinkin' loop and update the X,Y properties for each column each pass thru... :(

dbp, what you describe for interp1's former working is still documented as being the current behaviour:

"If you have multiple sets of data that are sampled at the same point coordinates, then you can pass v as an array. Each column of array v contains a different set of 1-D sample values."

and testing in R2016a and R2016b confirms it works:

Sorry, I was just a little premature in what has yet apparently occurred; was reacting to the note in local documentation (R2012b) and presumed by now the threat had been followed up on. Maybe there was enough pushback to halt or at least delay this foolishness.

The links from there take one to release notes describing the workaround of an explicit loop. Hopefully the delay has turned into a permanent rescission?

ADDENDUM

Well, how 'bout that! Logic seems to have prevailed; although interp1 is sorta' now in the same "red-haired-stepchild" status as textread of being deprecated/discouraged, I see that the latest documentation even highlights the formerly-to-be-removed functionality as a featured example! [ :) ]

Consistency in direction is nothing if not consistently changing; a real difficulty in counting on Matlab in production environment as others have noted. I suppose this one had enough other users besides just me to have survived or they simply decided to stop using resources to modify it with the transition to the gridded interpolant route as primary.

I just created a service request asking about the status of the change for array Y for interp1()

In current documentation, the use of 'pp' is the only syntax that is recommended against.

Indeed, it'll be interesting to see what tack TMW chooses to respond under... :) There're beginning to be real consequences to the rapid deployment of new features and implementation; they've got the Fortran backwards-compatibility issue in spades of needing to find ways to continue the evolution yet not break too much going forward.

Fortran has chosen to keep the compatibility at almost all cost including just recognizing some potentially desirable features just may not be implementable as one would like. TMW, otoh, has chosen instead to keep adding duplication of functionality (with the hope of eventually, I suppose) deprecating much (on a relative scale) or simply announcing such as here that functionality will change. Sometimes they've kept legacy switches; other times, "not so much".

It's not so bad if one is introduced at some point as new user or if there aren't very long term requirements to maintain an application or the need for QA on results. That functionality can change is the most scary part; it may not be able to be seen that results aren't the same if a version is simply updated and new cases are run going forward without checking a test suite to verify same behavior.

None of this is news to you, of course, simply observations brought to mind by the subject question here where they've made changes that superficially may seem unimportant but for some users may create issues.

Mathworks replied that using the griddedInterpolant loop is an efficiency matter, but that the results would be the same, and the array Y is not slated for removal.

Interesting they would go to the trouble to provide compiled new routine w/o the facility but force the user to do the looping. interp1 is just an m-file, though, so there may be a speed advantage at the loss of the convenience.

Wonder why they changed their minds, though...altho one presumes if they'd committed to the new routine figured might as well just abandon the other as is as cheapest.

Anyway, thanks for the update/asking the question...

I did some timing tests and it turns out that using interp1() with the 'extrap' specification is faster than using griddedInterpolant in a loop over columns. interp1() without 'extrap' can be slower than looping griddedInterpolant over columns, but the timing difference is almost entirely due to extra memory copies as interp1 bashes NaN into appropriate placces.

Interesting results, Walter, and thanks a lot for the testing. I've used the idiom with the array quite a lot in some test data collection/analysis routines over the years but the sizes haven't ever been terribly big on individual cases; we had 8 coal pipes on a burner at a given level generally all we were monitoring although there can be as many as eight levels in a larger boiler. That's still not all that big but the compact code makes it worth a little tradeoff anyways as long as it's not a humongous penalty. Of course, prior to the intro of griddedinterpolant it was interp1 or "roll your own", anyways... :)

The line objects you get this way are not the line objects belonging to the legend. Even if you

you will not be able to find the sample line that is used for the legend.

If you are looking for a way to adjust the length of the lines in an existing legend then I would suggest using the following commands.

By default the values for x1 and x2 are 30 and 18 respectively, so reducing the numbers will result in a smaller line in the legend window. However, the line style will remain identical to the lines used in the plot.

This code is only an application of that found in the link below: