I'd like to clear all application data from a single figure, without using the names of individual application data variables.
Is there any function in MATLAB that will do the above?
No, you can't do this in a simple way.
The application data for a figure is used to store lots of things by MATLAB itself (such as the zoom and pan status of the figure), not just things that you set yourself - so just "removing" it all is a bad idea.
You can get the full set of application data using getappdata(f), where f is the handle to the figure (as opposed to the more usual getappdata(f, 'varname'), which would get a specific variable that you'd stored in the application data).
The result is a structure, and you can than go through the field names and delete anything you've stored.
To make this easier, you can use a consistent prefix for the names of any variables you store. Then just go through the field names and call rmappdata for any field that starts with your prefix.
Related
I am thinking about how to best represent a certain data structure efficiently in Swift using CoreData. What I need is work with accounts (like savings, earning etc.). So what would probably make sense is an account class, where each account instance might have multiple characteristics like e.g. ACCOUNT_TYPE_ID which do not change. The core however is the VALUE attribute, which would hold the value of the account at a certain point in time. The complex thing here is that this value obviously might change over time (lets say on a daily basis, abstracting for intra-day changes) and I would need to be able to get the value of each instance for any given date. E.g. I might have my savings_private for which I would want to get the value at each month-end. This value might have changed, but as well could stay the same for various days/months. How could this most efficiently (when it comes to used space but - and that is even more important - be able to access computationally efficient) be done with a CoreData Entity/Class? I was thinking about maybe always starting with zero and then only somehow save the changes plus the date of change and then have some method for the call which would add all changes up to a date parameter - but was curious about what a best-practice might be here, as I guess I am not the first one trying to solve this.
I'm new to Matlab and I need some suggestions on how to deal with having many inputs to a function.
The program reads data from multiple elements and stores them in an array, which I'm doing in a loop. The problem is that if I input the wrong information about one element, I must re-input the data all over again. I believe that there must exist a better way to input these data, like reading it from a external file, for example.
The problem with the external file would be, as far as I know, with the reading of multiple arrays from a single file, hence the need of multiple external files - and I believe also that must exist some better way.
As noted by #beaker, you can use save and load to store the data. You can store multiple variables in a given file without a problem.
I'm working on an extensive Matlab based GUI that was created with GUIDE. Saving the full state of a GUI seems to be a laborious task as it is generally impossible to efficiently make a self-contained copy of the handles structure. From what I've gathered in my web searches, the current work-around is to manually create a new structure and store the necessary properties of all the uicontrols in the GUI in appropriately named fields. For example if there's a uitable in the GUI, you might want to include in the new structure a field called tabledata where you store the Data from the uitable. The idea is then to save this new structure to a .mat file and load the state of the GUI again by reading this file and doing the inverse exercise of manually copying fields.
I called the above a work-around instead of a solution because it's quite laborious for a large GUI. If anyone has a better/quicker/shorter/cleaner way to do this, please feel free to share! I've come up with a shorter and from some points of view cleaner way myself, but there are a few reasons why I might still prefer the above work-around. In any case my question is about that work-around.
The biggest problem with it is that your saving and loading code must be inclusive: every value and property that can be adjusted by the user should be saved into the newly created structure. For a large GUI it's a real pain, nigh on impossible, to find out which values and properties are adjustable by manually checking everything. Especially with the properties of one uicontrol possibly influencing certain properties of one or more other uicontrols. So my question is: is there a way to get an overview of all the values and properties that a user can influence for a given GUI?
Look into a function called uiinspect coded by Yair Altman. It produces a list of all methods, callbacks, and properties.
A full explanation of how the function work s is located here.
I got a part number field that have several repetitions. I want to use a variable to save this so that I can show all the descriptions of these parts in a different layout when user click a button.
But I do not know how to use variable to save several values like that. And I do not know exactly how many repetitions for each part number.
Although FileMaker allows for repetition fields and they have some valid behind-the-scenes uses for the database developer, they should NEVER be used for data. As pointed out by others, you should rethink you data structure.
That being said, you can capture the information in repeating fields by specifying which repetition you're interested in. If you have a repeating field named "partNumber" with 10 repetitions, then you can access each of the repetitions by:
partNumber[1]
partNumber[2]
.
.
.
partNumber[9]
partNumber[10]
RepFieldToVar [calculation] =Let($$varName = List(RepeatingFieldName), "")
This puts all repetitions into a return-delimited value list in $$varName.
Incidentally, there are _exceedingly rare_ instances where repeating fields are still useful. I've used them for grid-type schedule layouts that need stored values. But 99.98% of the time the other commenters are right, you can probably do it more efficiently with related records.
I am having issues with 'data overload' while processing point cloud data in MATLAB. This is what I am currently doing:
I begin with my raw data files, each in the order of ~30Mb each.
I then do initial processing on them to extract n individual objects and remove outlying points, which are all combined into a 1 x n structure, testset, saved into testset.mat (~100Mb).
So far so good. Now things become complicated:
For each point in each object in testset, I will compute one of a number of features, which ends up being a matrix of some size (for each point). The size of the matrix, and some other properties of the computation, are parameters of the calculations. I save these computed features in a 1 x n cell array, each cell of which contains an array of the matrices for each point.
I then save this cell array in a .mat file, where the name specified the parameters, the name of the test data used and the types of features extracted. For example:
testset_feature_type_A_5x5_0.2x0.2_alpha_3_beta_4.mat
Now for each of these files, I then do some further processing (using a classification algorithm). Again there are more parameters to set.
So now I am in a tricky situation, where each final piece of the initial data has come through some path, but the path taken (and the parameters set along that path) are not intrinsically held with the data itself.
So my question is:
Is there a better way to do this? Can anyone who has experience in working with large datasets in MATLAB suggest a way to store the data and the parameter settings more efficiently, and more integrally?
Ideally, I would be able to look up a certain piece of data without having to use regex on the file strings—but there is also an incentive to keep individually processed files separate to save system memory when loading them in (and to help prevent corruption).
The time taken for each calculation (some ~2 hours) prohibits computing data 'on the fly'.
For a similar problem, I have created a class structure that does the following:
Each object is linked to a raw data file
For each processing step, there is a property
The set method of the properties saves the data to file (in a directory with the same name as
the raw data file), stores the file name, and updates a "status" property to indicate that this step is done.
The get method of the properties loads the data if the file name has been stored and the status indicates "done".
Finally, the objects can be saved/loaded, so that I can do some processing now, save the object, later load it and I immediately know how far along the particular data set is in the processing pipeline.
Thus, the only data in memory is the data that is currently being worked on, and you can easily know which data set is at which processing stage. Furthermore, if you set up your methods to accept arrays of objects, you can do very convenient batch processing.
I'm not completely sure if this is what you need, but the save command allows you to store multiple variables inside a single .mat file. If your parameter settings are, for example, stored in an array, then you can save this together with the data set in a single .mat file. Upon loading the file, both the dataset and the array with parameters are restored.
Or do you want to be able to load the parameters without loading the file? Then I would personally opt for the cheap solution of having a second set of files with just the parameters (but similar filenames).