Two Data Tables and a Microphone: Unlocking the Power of the Tables Menu (2025-US-30MP-2509)

Welcome, folks. My name is Nathan Clark. I work at IDEXX Laboratories. I've been using JMP for 22 years now, and I'm going to be giving a talk on the Tables menu. The Tables menu, I have found to be one of the greatest things that JMP is bringing to the table, pun intended, because it gives you such power to manipulate, massage, and do things your data so that it can facilitate so many other additional analytics. If you can master the Tables menu, you will be several levels higher than if you have to go some of the old-school routes, like copying and pasting to move your stuff around.

I want to talk with you today about how I use the Tables menu, some pitfalls I've seen over the years when people are trying to get used to using it, and also maybe some tips and tricks along the way. With that, let's get started here. We're going to open up everyone's favorite big class with a couple of modifications I've done. We'll start right at the top in the Tables menu with Summary.

Summary, as you would expect, is for summary statistics. When you open it up, you have a number of options in here. If you choose a response variable such as height, you can do a mean, an SD. For all of the table menu things, there is a preview that should pop up. This is phenomenal. I cannot overstate how great it is to have this here because this way you can take a quick look at what you're going to be seeing in the table.

Right now, you see that I have a summary. It has 42 rows and a mean and a height. It takes nothing else into account here. This would represent the grand mean and the grand standard deviation for all the data. If I want to split that out, I can just drag things over into the grouping section. Now I have a male and female mean and height.

This is, I'll say, the main intention of the summary. When you click OK, you get your summary, and then you can go up here, you can add statistics from this hotspot column. If you realized you forgot something and say you wanted to throw in the mean of weight as well, you can click OK, it'll add it in.

That's really cool. I use this a lot. I'll note a note right here where these things are locked. This means I cannot edit. If I try to type another number, I get a notification here, and so I use this to get my summaries, summary statistics, but I use it a whole lot more for something a little bit different. We're going to close this. I'm going to reopen it and point out a few other things.

You just saw that I mentioned the locking of those columns. If you uncheck this box, those columns will not be locked, but it'll not be linked to the data either, which facilitates some of the stuff we're going to be seeing in a moment.

While I'm over in this section, I will also point out here two boxes you see often in the Tables menu. Keep dialog open. We'll keep this box open even after I click OK. That way, you can quickly play with a bunch of different ideas. Then, if you were to save a script to the source table, not only would the table you create have a script and how it was made, now that same script will get stored in this area on the table where the table came from, which is, I think, a really great thing that came out a version or so ago.

Now getting more into really what I use summary for a whole lot more, it is diving in to understand the data and to break into various demographics. For instance, if I just go here to sex and I just put this in the grouping, I don't do anything over here with the statistics. I'll still get a table. This table will have the breakdown and the number of rows. If I click OK, you get a table here. Because it's linked, as I click through these, it selects all of the stuff I'm interested in this instance.

This is a great way to start poking around to your data to get data to subset, which we'll talk about later, as well as understanding other aspects of your data. We'll bring this back here to go a little bit deeper into this. If I go here by name, you'll see that you get a split in the sex as well as the name associated with it. This is bringing in here, as you notice, where some of these N rows are actually one.

Something that I'll talk about here with the summary, but it's really important for a lot of the other platforms we're going to be talking about, especially if you need to troubleshoot because something doesn't look quite right in your data. This is the idea of uniqueness.

With any table you're dealing with, you should always be able to identify which columns in various combinations can get to various levels of uniqueness. If I remove both of these, we'll start with this for what I'm talking about. If we go to name, which we think is generally a fairly unique identifier, we can group by name here.

What we see, if we scroll through, we see that most of them are one. Down here, we see Robert and Pat, both have two rows associated with them. Name by itself isn't enough to be unique with this data set, so we need to add more columns to it. Maybe if we add sex into this, we can get this feel for it.

We still have many N rows equal one, we get uniqueness, but down here, still we have two Robert, there's a male and has two rows associated with him. That means we have still another column we need to bring in to get to the level of uniqueness we need. I'll bring down age. Now we can see we have full uniqueness for our data, one's all the way across.

The preview is a great way to see this. If you have more data that fits well in the preview, you can always click OK or use the keep dialog open to keep it going. It's really important when you're dealing with data to know what makes unique and sometimes to add columns to make things unique if it isn't unique to start with, because that comes into play as we play with some of the other avenues that we're going to be going into.

Speaking of that, we're going to go right into the Subset platform. What this does is this gives us a way to sub the data as it suggests. You can do all rows, the selected rows. You can do filtering by rows. This way, you can also link it to the original data table, although I'll do something else here that I think is a little bit faster and easier to do. JMP will also help you based on what is actually in the table. As always, the preview gives you a hand.

If I go here, I can actually click on M, right-click select Matching Cells. All of my Ms are selected. Then, if I go into Tables and Subset, I can then see it's automatically… Assuming I want to do the selected rows. I could do all columns, I could do selected columns, which right now, sex is a selected column, or I keep it as all columns.

Copy and suppress formulas are to help keep things clean. You only evaluate formulas when you're really interested in doing so. By clicking OK, you get a subset. This subset is not linked to the data. You can click around here. This is the standalone table.

If you do want a linked subset, yes, you can go up here to Subset. We'll do a recall, click this, and click OK. This is now linked to the data. However, that's several clicks more than I'm really interested in doing. I usually right-click, select Matching Cells, get to the selection I want. By this, there are many methods. You'll see down here, it shows us that we have 23 selected rows. If I right-click here, I can go to Data View. Immediately, you get a link subset.

This doesn't give you the option of only the selected columns. This data view will always bring up all of the columns, but I use this constantly. If I'm in a situation where, say, I have a row at the top and then a row at the bottom of a data set selected here, and I want to see them both side by side, Data View brings them, so I can look at them immediately and identify things that are going on.

I love this feature. I use it a lot. One thing people should be aware of, though, is that when you're using Data View, because it is linked to the data set, if I make a change in this Data View, this change will be reflected. You see, I have Tim here highlighted. If I change that to a lowercase M, that is now reflected in the table itself. Be aware if you are using these, because if you treat it like a standalone subset, you may be actually changing your main data.

You can use this to your advantage. If I needed to change all of these Ms mixed without the table to lowercase Ms, I could just change this first one to a lower M, then right click and go fill to the end of the table, and now all of them are lowercase Ms. That could be a really useful way to fix a bunch of data or augment your data in a different way. It's something to be aware of when you're using your data and playing around with your stuff. It's a phenomenal feature when you're getting involved with your data and doing different things.

Sorting is really what it says. It's powerful but simple, which is a great platform to have. You can sort. Let's see, we'll sort by name right here, and you see it immediately starts defaults to ascending order. If you click on it, you can force it to descending order. You can add additional things in here, and it will sort, and you can also do that by ascending or descending order, and so you can do this with as many columns as you need to. When you click OK, JMP will create a new column.

I find that's really useful, especially with big data sets, I think I know how I want to sort things. It will look like I want it to look if looks matter. I also don't want to mess it up and have to work really hard to get back to the table that I'm at. This gives me a whole separate table.

A lot of times, I'll do this, and I'll take a look at this table, and I'll ask myself, "Is this what I want to see? Is this what my endgame is?" Then I'll close this. If it is what I want, I'll go right back into the sort menu. I'll recall, and then I will replace the table. By doing that, I've now sorted the main table I have that helps keep my number of tables to a minimum quantity.

That is really nice that you have the option to do so. I do that a lot to make the table. Then I go back and replace the table just to help make sure that the things I'm doing to my main table are what I want, especially when I have a lot of data with a lot of columns that I don't want to just make the data look junky and harder to don't mind going through.

Next up, we're going to go to stacking. Stacking is some really cool stuff here. I actually have a special table here that we'll start playing with. Stack is, by its nature, just what it says. It'll take columns and stack them up. If I go into Tables and I go to stack, I can take these three read columns and I can stack them together.

We'll just click OK here to showcase. Now it shows that I am the labels, Read 1, 2, and 3, and then the associated data that was in their original columns or the original values, and so this is great.

I use this a lot when I have a lot of data that comes out horizontally, and I need to put it vertically. Stack does all of this, and it does it irrespective of how the table may be organized, which I think is really good, too. It maintains the proper relationship within the table. This data is a little bit special, though, and it takes advantage of something that I use a fair amount. When you have different groupings of data that all need to be stacked but organized in a specific manner.

In this case, I have 3 wavelengths of data, 405, 357, and 680, and then I have a read associated with each one of them. Rather than just stacking my reads, I need to maintain their association with the correct wavelengths. JMP can do this with their stacking. We go into the stack menu.

We're going to stack all six of these columns, and then JMP is going to organize them really nicely together. You can see what we've done so far in the preview, JMP has not organized them really nicely together. They did what I just showed you. It stacked all of them into its two columns, which isn't what we need with this data.

We're going to go, and we're going to check this box down here, multiple series stack. This is so great. You already see some of the changes JMP is doing and put this out. It puts them in to start off with the default of two series. That is what we want here is two series because we need a column that represents the wavelength, and then the column that represents the data values that go with those wavelengths. That's where the two series comes from. If we had three sets of three, that would be for three series to get those pieces of information.

I will say for as semi-confidently as I am talking about this multiple series stack right now, nine times out of 10, I go to do my stack, I click a button wrong, and the data doesn't look like what I want. Play around and get used to it. More importantly than memorizing how to do it, recognize what your data should be looking like, so you can play around to make sure you can make adjustments if things aren't quite right.

One of those choices often is down here with the Contiguous button. The Contiguous button tells JMP how the columns are organized in this window, not in the data table, but in this window. That's one piece I usually would forget when I'm going through these. Because we have wavelength1, wavelength2, wavelength3, and then the 3 reads, these are touching each other, these are touching each other for the two series. This is contiguous data.

You can see over here in the preview, JMP automatically fixed it to look a bit more normal. If it went wavelength1, Read1, wavelength2, Read2, wavelength2, Read3, like this… Actually, I will remove these, and I'll go wavelength1, Read1, then 2, 2, 3, 3. Now you can see with the contiguous box checked, the data doesn't look good, so I want to uncheck that box. How this data is organized in this window and whether or not you use this button are linked to one another to get to the data you want.

We will click OK. Now you can see that we have this data looking pretty good. You can do a spot check for like we'll do Sample 1, we have 9.83 and 141. That's looking good. You're going to always spot check a couple of others. Once you have this done, we don't necessarily need this. We're going to rename this wavelength, and we can get rid of this column. We can rename this Reed or Read with an A, and we can right-click, and we can delete this column. Now you have your stacked data organized appropriately.

That's a really nice thing when stack is there. A couple of things I'll point out just in the menu that you can utilize to your advantage if you so choose, you can rename the data and label in here before you start. You can choose to drop all the columns that are here or keep them all or do a selection, as well as just telling you where you want to put the data and label columns when you're going through to make the data look like you want it to.

Moving on, we're going to go to split. Split is the opposite of stack. It is one of the most powerful but most pain in the butt platforms to get used to. We're going to show you why right here and how to pay attention to what you might want to see. The easy stuff is what these represent. The split column or the column you want split out, this is the one that actually contains the response data you want to keep in the cells. In this case, we'll do Read.

Split by is the column that the reads are split up individually by, in this case, it's wavelength. It gives us a look at the data in the preview. We have the choices here, the keep all or drop all, depending on how much data is in the table. We're going to click OK, and we can see the JMP has done a pretty good job, 357 is 0.83, 405 is 9, and 141. It looks like JMP did exactly what we needed out of it. Good job on JMP.

I will say that this forgot a very important piece of information that makes it seem like doing the split is easy, but as soon as you get slightly more complicated data, it becomes a problem because the users will start seeing data that they did not want to see, and they'll have a lot of frustration trying to get their split correctly.

It goes back what I talked about with summary, when it talks about uniqueness, understanding what makes your data unique to get to various responses. Now, in this case, sample would be an obvious unique choice because these are all grouped by sample here. JMP magically, I won't say magically, JMP got it right with their internal algorithms to understand how I wanted this to probably look based on how it was organized.

But let's say it's not like that. I'm just going to insert a quick column here with some random numbers, and I'm going to sort by these random numbers to completely disjoint how these are organized. Now, if I go into my split again, I can hit recall, and I can see this stuff is here, but I can automatically see that wide JMP has these pieces of information, see the 99.63, but then it's like a 128, which is down here.

Obviously, there's something that's not necessarily aligned with how this is going. This is where frustration comes into play. People have to do a lot of work sometimes to understand why. That's where this grouping thing comes into play. Group by all the columns that are necessary to create the uniqueness based on what you're going to see for the split.

In this case, if I group by sample, suddenly everything in the world is right again because JMP can now explicitly know that these readings in this table need to be grouped by sample because they're inherently connected. If it was something of a big class, then it would be, name, age, and sex that we had looked about before for that uniqueness.

Your data is going to differ depending on its complexities, but always keep in mind being able to get to that level of uniqueness. I haven't found that you can overgroup in split. If you know it's a column that's involved, even if it might be overredundant with your grouping, feel free to add it in because it's better to overgroup and still have your uniqueness than to undergroup and have things missing.

One thing to look at when you're doing a split as an indication of various levels of success, is keep an eye on your row count. If I start with 300 rows, and it's relatively balanced data and each sample has three wavelengths, when I do my split, I should get about 100 rows. If you find yourself getting weird numbers of rows, it's probably because JMP did the best it could, but it wasn't finding the exact organization necessary to create what you wanted.

That's an indication where you probably didn't quite group something successfully. That's something where you want to pay attention and use that to your advantage to get a feel for if your data is looking right, so you don't have to spot check 10,000 rows of data. You can spot check a couple, three to feel comfortable with it and move on from there. If you do those sorts of things, splitting will become second nature and start working really well for your day-to-day JMP work.

Transposing, I'm going to talk really briefly about in the interest of time, in part because I don't use it very often. I've met a few colleagues that use it a lot. But basically transpose allows you to take stuff that's organized like this and just twist the whole thing on its end. That is useful in some degrees. I don't use it very often. I think in some cases, I'm lucky enough that my data in general isn't organized that wonky.

But I want to show you the dialog because, again, uniqueness and grouping comes into play here with this label and this by. This helps, so you can tell JMP how you need the data to be organized when you're trying to transpose your specific call problems. Again, understanding how your data is organized uniquely gives you a lot more power with that platform.

Moving on to Join. Join is another really good one, and it's extremely powerful. We'll talk through some of these pieces, then we'll get to the example. When you open up the Join, it starts with, this is the table that I'm starting with. This is the table I will join to. I select over here which table I want to join with, and then it's going to go through over here. We'll see some columns, and I have some options over here on this, specifically how I want to do my joins.

We're actually going to go back to a modified big class here that we have. I have another table that's an extension big class. Basically, I have a whole bunch more names, age, sexes, but here I have heart rate and BMI. I want to join this information together. I'm going to go to my original table here, and we're going to go to the Join. Here's my big class. I want to join it with my extended big class. By default, it goes by matching columns, which is, I think, 99.9% of joins are done by matching columns. Then you tell JMP what you want to match.

This goes back to the various levels of uniqueness or to what layer in your uniqueness you want to join by. But you can select the name in both columns, click Match, Age. They do not have to say the same thing. You're telling JMP what the names are that have to be matched up. It has nothing to do with what their physical name is.

Over here in the preview, you notice that it does something a little bit weird and potentially annoying. Here, it actually gives you a column now. It's a name of 2025 discovery mod big class. You see this over and over again with your other ones. Now all of your column names are large and huge. This is great to double-check your data after the join is done, but it can be annoying to fix.

JMP has something for this. It's called merge same-name columns. When you merge same-name columns, I'll uncheck match flag, you see that it combines the same-name columns into a consistent feel. It was able to do it even recognizing that name and name technically are different because of case, but JMP put them together because it recognized they were the same there. When you check merge same-name columns, match flag turns on also. This lets you when things are in play and do some matching between the tables.

Down here, so I often will do merge same-name columns and match flag. Something else I always do, especially with a first join, is, I include non-matches from the main table and the width table. I'm going to click okay, and I'll show you why I like this, because it's a good way to double-check to make sure my data is properly organized.

You get this match flag column, and we're going to expand this out here, and we see that it says both main and width. If we go to both, and we're going to go down here, this represents a piece of information that were present in both the original table as well as the second table. You can see we have the original height and weight, but we also have the heart rate and BMI.

If you have something that's main, select all of them here, this is something that that existed in the first table but did not have a match in the second table. You can see here it has the height, height, and weight, but no heart rate in BMI.

The width is just the opposite of that. It was in the second table but lacked stuff in the first table. I like looking at the data this way because it lets me double-check to make sure the things that are missing, I expect to be missing.

In the case here, I had 112 names. I have only 42 in this first table. There's no way I'm going to get 100% matching. Having some widths because I have things here that don't have a match is perfectly acceptable and makes complete sense. By that same token, some of these names may not be in the extended list that we have the additional metrics on.

The main and width, at least in their general concept, are fine here. Then the both aligns where they both fit together, and you can spot check what you may expect. When you're doing this with data more in real life, someplace where I feel this is really useful is, say you're running an experiment, and you are running something on a machine, and then you also have a run sheet or something that you are taking notes on that correlate, maybe run IDs or something.

If you're doing that match together, it means very specific and different things. If you have data that came off the machine, but you have no information on your run sheet for, or if you have information on your run sheet for a run that you have no data off the machine. In the cases of errors or things like that, that may make sense, but it also could represent maybe a transcription error when you were typing an ID on the machine to run or other things like that.

Being able to do those joins with larger sets of data and immediately being able to see where your data matches and doesn't, is an absolute game changer in terms of being able to quickly break down and identify.

Again, here, looking at the number of rows also is another indicator, 42 rows, if everything was a perfect match, I should only have 42 rows. But I have a lot more in part because I have widths that were in this table or not, and then the mains. Using that to your advantage can also help you recognize if there is a problem or something you need to dig more into.

Finally, a little warning about when you are doing this join, and you have a situation where you have the same-name column, but it's actually something different in terms of the information it represents. If I go into this, and we'll just do age for ease, and I'll just make it so that this age is all 89. For whatever reason, this table 89 represented something about age, and it's all going to be the same.

If you go through, and you're going to read through this join, I don't know why when you do the recall, it doesn't do the preview for you quite the same way. But what I will do is I'll click OK. What you'll see here is age has been overwritten in some instances. Actually it didn't there. That is something good to see. I wonder if that is something that is new or if that's only fixed on the other ones.

That is something I've witnessed before, where I will overwrite depending on. It's something that JMP has been improving on, clearly in some of these instances here. But it is something that if you don't pay attention for it, we'll make sure this double-checks again.

That seemed to have fixed some of the problem there, but it's something to pay attention with, although I wonder where my both went. That's a side concern I'll deal with on the side. The main important thing to pay attention to is that you can have age overwritten by the other table there. I see this a lot when the machine data has a full-time stamp, but like a run sheet date is actually just the date you ran, you can get some of your data overwritten there.

That's something you really want to be careful of because many steps down the line, you don't want to see this happen. What ends up taking place is you may be expecting to see sometimes in your data, but now there's none because they're overwritten, or in this case, you'd expect to see individual ages, but now suddenly everyone is an octogenarian.

That is not conducive to efficiency and workflow, and especially if you have to go back seven steps to figure out where the problem came in. Knowing this in advance gives you a little bit more power. The easiest fix in this case would be, if you know this is a risk, just update the column name or eliminated completely depending on whether or not it matters.

I realized why this happened now is I just updated this one thing. It's because when I did my recall, it still matched by age, and I changed the age. We're going to actually remove that. Now you can see some of that overriding had taken place on some of your both. That's where that can catch you in the end. The simple fix is to just change that name. We all go back to join and recall. Now you'll see age will be missing for some of them, but have it for others. Then you'll have age_ for the other ones there to show that that didn't get overwritten.

That's how you fix that. It is something that has blindsided me many times, oftentimes, accidentally. I do not make the mistake anymore. I just am faster at finding it and fixing it. Don't beat yourself up if you make that mistake. It takes time to get used to it and in the end, you rarely stop making the mistakes. You just get better at fixing them when they occur.

Going up next is Update. Update is a phenomenal tool. I'll be honest, I had a love-hate relationship for a long time when it first came on the scene, and it was me, not it, because it had to do with the assumptions that Update makes. If you don't pay attention to them, they can burn you. Specifically like we were talking about with this overwriting. I'm going to put this page back here, and we're going to actually…

Apparently, I did this on doing all, but there we go. Getting back to where we have all the other ages. Update is really a join, but it doesn't make table. We go to Update, same basic setup. Now we want to join with the extended big class. We'll do our match by name, age, and sex.

At this stage in the game, you can also see this a little bit from the preview, JMP makes a couple of assumptions. It only does an inner joint, which means it does not include any missing values from either table. It only matches what is in the main table.

Secondly, it merged same-names columns by default. If you're not ready for that, that can bite you here. That is specifically what bit me early on when I was getting used to how update worked, and I didn't find it for an embarrassingly long time in my data, and then I had to go back and fix it.

Knowing that going in, JMP does give you some additional things to play with to help make it a little bit easier. If you have a whole bunch of data, or you're concerned about things that may overwrite that you don't want to, you can control which column from the update table come in. If I just go to selected, I can only do heart rate, for instance, or BMI, and make sure none of these additional columns get added in at all to risk that potential overwrite if they're not part of the joining.

Also down here, we're placing columns in the main table. I can select none, and that hard stop stops the overwriting from happening. Or you can allow for a selection in both of these cases to control that. When you learn how to use Update, it is a really nice thing to have, but it does have its caveats. For instance, now I just ran this, and it added BMI to this table. Now my main table has been altered. If that's not what you're looking to do, update may not be what you want for this specific use case.

However, as people get used to doing more JMP and get better at it, the desire to have fewer tables and not more is usually common, especially when it gets tired and trying to keep track of all the tables you made, where did that table come from, et cetera.

Little things you can do to minimize the table count can be greatly appreciated. In this case, Update does a really great job of doing that, especially if I had three or four tables. I had another table that had other metrics on people. If I had to do a join with each of those tables individually, I'd make three or four more brand-new tables to stack that join. Update allows me to pull it all into one table.

Something else that we won't talk about here, but it's great to look into if you have the opportunity is a virtual join that allows you to join several tables together without actually having the tables join. That is a really cool thing. There have been a number of presentations over time given by a JMP employees and whatnot, and there should be some webinars to hunt down that can explain that further. It's a really fun feature to play with when you have time. But Update does that join into your main table, and things are looking really nice.

Now we're going to go into something a whole lot more simple, concatenate. Basically, concatenate is taking tables and just stacking them one right on top of the other.

It does just that. Actually, I can just take this discovery mod. We're going to go to concatenate. Now we're going to pretty much just list all the tables you want concatenated together. If I wanted to add the extended big class on here, it's going to throw them on top of one another. I could append to the first table if I so chose to minimize table count.

You could also create a source column. I recommend doing this, especially if you're going to be doing a separate table, because this gives you that control on knowing where the data came from. If you click OK, it simply updates your data, puts them right on top of one another, and I can see exactly which rows came from which table, and it works extremely well in that vein.

Where people get tripped up on concatenate is usually just the data doesn't look quite like they want, or there's data in the wrong spot. In the case here, I will call this metric, or actually… I wonder if it'll do it with just a different way to say the same thing.

When I do the concatenate, you're going to see you're going to have two columns here. This is an example where they're clearly different. However, JMP does care, at least historically, from what I've seen, they care about case or typos and things like that that can mess up how data is organized. It could be something like this, where it's just different naming convention or typos when people may have hand-entered stuff that causes your data not to where it belongs.

In the case of something like this where BMI, Body Mass Index, it only happened once, these fixes are pretty easy. This is a fun little trick that if you click on one of these empty cells, and you right-click and go select Matching Cells, all the empty ones are selected.

I can now invert that selection, and all the ones I want to put over here where they belong are selected. I can copy these, and then if I just select the header of this column, they stay selected right there, and I can just paste them in, and now I've fixed the error. I can delete this column. This is the fast way.

If it happens to a dozen columns, it's less fast and more of a pain. The best way to fix it, if you're going to have it happen, is to actually fix the name of the column. But again, depending on what you're doing and where you are in a process step, there are lots of ways to do it. There's no real true best pathway here when you're looking to do this.

But that is the biggest thing I see that trips up people when they're doing concatenate because they have a lot of columns and now their data isn't where it needs to go. It becomes an issue from there. But other than that, concatenate works extremely well, and it's a great way to collate a lot of tables into one table really fast.

Now we're getting towards the end of time. I'm going to briefly talk about these ones here without a lot of specific examples, in part because I haven't used them a ton to really develop a mass of tips and tricks. But I've used them enough to know that they're useful and worth looking into and playing with.

JMP Query Builder basically allows you to build SQL queries from multiple data tables that you have in front of you. You can also utilize JMP Query Builder with data tables that are actually stored in databases outside of your computer and bring all of that data into JMP. You could do a mix of that with the tables that you have available, so that's really cool.

Missing Data Pattern, I have seen a number of neat presentations on Missing Data Pattern. I have not actually used Missing Data Pattern in my day-to-day, in part because I am fortunate enough that I don't have a lot of missing data issues.

Also, Missing Data Pattern came in many years after I had gotten really used to mining data in a whole separate way to get to where my missing data patterns might end up being. I just haven't added a missing data pattern into my arsenal yet. It is something I keep telling myself I need to play with more because it is a really fun way of looking at the data when you see some of the other folks using it.

Compare Data Tables. This is the fun one that… I will show this really quick. It allows you to pick a couple tables and do a comparison. JMP will try to match up their names pretty good. Here you can see that this is done, and you can fix that. But if you just click Compare, it goes through and shows you where all the differences are in the table.

It is something that, like I can see here, I'm not sure exactly what it's showing me. This is where I need to play more to get more familiar with it. But it's a fun way to, if nothing else, take two tables and find out if everything is the same or not. Oftentimes, I'm checking to see if I changed something about the data that I didn't mean to.

When you get into the nitty-gritty of the specifics of what changed, a lot of these options are really where that comes into play. That is something I encourage everyone to play around with just to see what happens in your own use cases, because it's a good platform, and I haven't used it nearly to the power that it can bring to the table. But it's really something cool that JMP lets us do that isn't something that I have other ways that I would do on my own.

Finally, Anonymize, the last thing on this list. Basically, it will take the table that's in front of you, and when you click OK on that, anonymizes it. Now no one knows what any of this means. That's the point of creating data tables that are devoid of any information that can be understood or digested by other folks.

If you have proprietary information in a table, but you want JMP's help with the problem you've been having, you could anonymize your table and then recreate your problem with this information and be able to safely share this with other JMP support folks, and not have to worry about breaking any proprietary IP rules you might have in your company because, now, no one knows where this data came from and what is going on with it.

That's a really fun piece of information; that JMP is also allowed to make this pretty fast and easy to poke around with. Play with that also. It's a really fun way to do things.

I think that pretty much takes us to the end of the Tables menu. I want to thank JMP and everyone involved with the Discovery Series for the opportunity to do this because this is a really fun thing to talk about. I think it is something that a lot of people will gain value in as they're going through their JMP journey. Thank you very much. That's all I have for today.