Live CEOing Ep 775: Language Design in the Wolfram Language [InterpolatingFunction Methods and More]

Okay. Hi, everyone. Welcome to another Wolfram Language Design review, part of our Language Completeness and Consistency series. And we have a variety of topics for today. And I'm to trying. Trying to figure out why something is not working correctly here. Let me see if I can make it work. Okay. Okay, first key auto stripping.

Right. So let me set the table a little bit here, because this is spun off from the tabular meeting, but obviously we have people who weren't at that meeting. And there's also some additional issues. Right. So in the prototype build, we've made sort of. We've made some changes to how key is handled by association and related functions and sort of the goal is to make, you know, association of key, key of association, lookup of association and part of association and key sort of as similar as possible as they can be. Although there's the part of me that's like, why do we need four different syntaxes for the same thing? The. The other, you know, this what sort of came from the tabular project because we think this will sort of make a cleaner design with multi keys, which are sort of essential for. For tabular and sort of align association and tabular as much as possible. So the first change is to give key the flat and one identity attributes. You know, the flat, I think, is pretty. Assuming we agree with this whole direction, the flat is, I think, uncontroversial. The one identity I am personally, I mean, I understand why it makes some things cleaner, but given that it's not always true that key of X and X are semantically equivalent, it's a winner.

One identity would not necessarily affect evaluation. It affects pattern matching, but not necessarily evaluation. It's not true.

Statement. Correct? That is correct. I'm just saying that in things like times which have the one identity attribute. Yes. X and times of X are not the same expression, but if you allow them to evaluate normally, they're always semantically equivalent.

Yes. No, I, I don't think it's obvious that. I think key of X shouldn't be the same as X. Probably. I. I'm not sure. I'm not sure. I'm not sure. I'm not sure.

Right, so that's that. That's what's been done. We can discuss.

I'm confused by the flat.

Yes.

Yeah. That means that if I do happen to make an association with a key that is explicitly a key, then functions that require that I wrap the key in key won't let me access that key value pair from that association because key is flat.

Right. So the Point is. Right, so, so part, part of the point is that association creation will strip the key. So that's the second bullet point. When association is created through evaluation key point, any key of deform, key of blank becomes just the blank. And so you can through normal evaluation create a valid association with those keys. So there's no need for the key of key construct. Now, in the binary compatibility issues, it's worth perhaps pointing out that you know, it's not completely true and that might be worth at least briefly discussing. Right, so, right, if you import a WXF or an mx, because those are sort of fully have fully created expressions in them that don't go through the evaluator, then you can still have a key which is a key in it. And as it turns out, if you think very, very, very carefully about all of the proceeding, you can extract it, which is you need to do unevaluated of key of key because that will prevent the flat attribute from firing and then the lookup function will strip one level of key and find the thing that you're looking for. But you know, it took me several minutes of thought to come up with that construction once I noticed this.

Can we zoom out for a minute? What are we trying to achieve here?

Right, so, right, so, right, so there are the three design goals I mentioned about aligning these syntaxes and making tabular cleaner and aligning it with association. That's what we're trying to achieve. There is there are backward compatibility issues and we need to sort of decide are we okay with them or are they fatal? And so if you, you know, we can look at the two examples of the two behaviors or we can look at the new inconsistencies and just muddle our way through.

Okay, so hold on. I'm. I have to say I'm a bit nervous now about the flat and one identity business.

Okay.

And I'm wondering why we need those things. So.

I'm sorry, I would say that the, the fundamental thing here is to avoid users having to think do I need a or key of a? Because once we put key inside multi keys, we might end up with key of key if they are not careful because they got a key from position, for example, and so it's key of A rather than A and things like that.

Jose, can you, can we try and make arguments about this without talking about multi keys, which like so far are completely undefined, especially in. For this audience and have not been design reviewed at all. Like if, if. Okay, yes, then maybe we cross the bridge. But I Don't think everything can hinge on something that is still untouchable.

Okay. Okay. So I, I would say yes, this example. Let's. Let's think of this example. So why should users have to be thinking about whether they need key of a or a?

There can be some good reasons for that.

Because key is. To me, key is at least two things right now. It's a quoting mechanism, and as such it needs to be not to be flat, because otherwise you cannot quote multiple times, you cannot have iteration in the quine sense. And secondly, it's a shorthand form for lookup in some sense. And I think it's already pretty awkward that it's trying to be those two things. And this is where the tension comes from. I tend to use it mostly as a quoting mechanism. So to distinguish between part one and. If there is an integer key in an association, the key one.

Why should key of A and key of key of A be different? I mean, why. To me, this is like times, times of X and times and times of X, right?

No, because key of key of A is the key that is literally key of A.

Exactly.

Yes, but why do people need that?

Because they provide meta way to collect meta information about positions.

Like you're. You're creating a tree out of positions, position returns key, even if it's just a string. And it's. It's very useful that it's that way. It's very clear, it's very clean. And if you're grouping them and then you end up with an association which has key as a key, that thing is not the same as the naked A or as the naked one, even worse.

I think you just all got used to using key, right? It's like we could have gotten used to use times of X.

Right. And for example, data set tries to avoid making you use key, but it can't be consistent because one is function query stuff. And to this.

So, so Stephen, may I suggest that you open the prototype section and you. And just so we can compare the two sets of behaviors. So. Right. So we created a key. Well, we tried to create key of B, but you know, it was stripped at creation time. And now, you know, however many levels of key we have, we always extract the associated string. Now of course, if we had an integer in there and it would be different, you know, in the part case, it would be different whether it was one or key of one. Right. So. So I would say that the first and third subsequent outputs would be, you know, right. And then. But if you did, you know key of one, you would, right? And if you did a sock of key of one, you, you'd get the same result. But if you did part one and part of key of one, you'd get something different. Right?

And that's because E is, is a disambiguator.

It's quoting, not disambiguation. It's.

Oh boy. Okay, so the nice thing about this behavior in the prototype build is you don't have to think about, you have to use key only.

Right? So for, so for example, if you want to make sure something is treated as a key and you don't need to check if it's key of string or just string, you just wrap it in string and if it happens to already be wrapped in key, then that key key is auto flattened. That's the, that. That's the Jose and Rob argument. You know, the Jeremy and Carlo and Leonid argument is, well, but you know what if I want to create a key, you know, use key as key of string as an, as a literal key in my association. And maybe there's.

Why would you want to do that?

Because that gives you information about positions, which serves a role of meta information when you are thinking about positions as expressions.

Why use key specifically? Why don't you use F or something?

Because that's what position returns right now. So this is not like. This is not a contrived example. This is how we discovered this behavior. So we had code that Leonid wrote in databases that was doing exactly that. It was constructing a tree like expression made of associations that were constructed by grouping by on the resulting positions.

And the reason I was doing that was that I needed to traverse expression and apply certain things during traversal only to specific positions. So I constructed a tree of positions, essentially where keys were in fact positions themselves.

Right. Sorry to cut you off, Leonid, but I tried to recon to construct such an example on my own since you had mentioned this in the previous meeting. And what occurred to me is that unless your expression is just a flat association, right. Aren't you going to get a list of keys and therefore you wouldn't have this issue when you called. Right. Wouldn't each entry in position be a list of keys?

Yes, but then I'm doing. Right, but then I'm doing nested grouping to get a three associate like a nested association expression out of that list of positions.

Okay, all right, now I understand.

And this was very important because I was doing double traversal of expression, traversing both original expression and that position tree. And that was a Pretty essential part of our traversal mechanism for what we needed. It certainly can be rewritten, but it's not. It's not completely untypical to have this kind of construction. And all of them will be broken for us or for external code, whoever also uses this trick. And this is, I think, the instance of a more general problem, that key, in that sense serves as a quoting mechanism for positions, just as, for example, verbatim serves as a quoting mechanism for patterns or, you know, quoting for strings, which would be some specific slashes or strings, which when you want. When you want to quote things. And this is going to be completely destroyed.

Let me see. Quasi quoting, not quoting, but yeah, okay, so the issue is, you know, when would you ever. If key is automatically stripped, the only time you need to use key is in essentially quoting an integer to be a key rather than a. I'm totally confused.

Well, or in lookup, you have to quote lists, because lookup has special behavior for lists, right.

So in part, anything that could be a valid part spec on its own. So, you know, integer, list, span, all, etc, and in lookup, and also for ex and possibly also, what is it? Join across, right? There's special syntax for, you know, list of keys and rules whose both sides are keys, etc.

So, yeah, and that's actually a good argument for Jose and I, side, I guess we'll call sides is that. That when. When we do join across, say for tabular, we want people to think of columns and not keys. So it'd be nice to be able to do that without having to use key explicitly, which the code requires now.

But I still suspect that there are some bugs in doing across because it doesn't seem consistent what it's doing right now. So I wouldn't really take it as an argument against key.

You mean bugs, argument against join across.

So join across uses this difference too, for some reason that we don't understand. So we maybe leave it even a bug. Yeah, but it distinguishes A from key of a. And it refuses to work with a. But it works with key of a.

You know, I'm trying to remember. There we go. I'm. This is deeply horrifying because this is essentially what in SMP. This is 1981. This is. Mark, This was a total mess. I mean, it had all the same issues. I mean, it was. It was a thing that was used to designate, to distinguish things like a literal position from one used as a name.

I think. Yes, I think. I think. I mean, granted, there's nothing we can do about this now, right, but I think the literal sin was that, you know, we made, you know, key of string and string be the same thing. It should have been the case that in part, you always need key if you want it to be treated as a key.

I don't think that's. Yeah, okay, go ahead.

And everywhere else you just give it, you know, the thing and it's a key.

Well, wait a minute. Do you think that's the only problem? I mean, so like, let's imagine.

Well, lookup is a problem too. And, and I, in my code, I use lookup because I don't want to get a message. So, so that difference is important.

What does lookup do?

Look up. Lookup. It. It has special behavior for lists. So if you have a list, you have to quote that. If your key is a list, you have to quote.

I see, I see, I see. Yeah, great. You know, one thing will probably help all of this stuff is some syntax coloring indication in, for example, lookup. If you start typing a list in lookup to be able to get some kind of raft that offers you to essentially key ify it. Am I making sense?

But sometimes list is what you want.

Because I understand, I understand. So that's why it's just not a suggestion. It doesn't do it for you, it's just suggesting it.

Oh, I see.

Right. Because things like that can help smooth out what would otherwise be very confusing.

Right. And, and sort of, you know, I mean, the, the advantage, I think, I mean of, or I think, you know, Rob's argument is if you have lookup of X, you know, something comma X where X is a, you know, module variable and you really want it to be treated as a single key, you can just write key of X there. And then no matter what, what comes in. Right. If what comes in happens to be wrapped in key, then it auto flattens and, you know, if it's a list, it's treated as a key, et cetera. I'm not sure how Carlo and Leonid feel about that, but I think Rob sees that as an advantage.

Well, I think I can speak for both of us. We see this as a dangerous thing because it's this instance of auto evaluation where if intent was to distinguish things for whatever reasons that could be, that would not be possible. And also I think that the semantics of association is complex enough in terms of evaluation, and this will add another complexity on top that people might expect to get their internal SoC exactly the same keys as they have. So those keys have some key on top of that. Or key of key for whatever reason, I think people would expect generally to get that into a sock and not be stripped.

Right. Okay, look, this is, this is truly complicated and. Okay, do we understand, are there two distinct possibilities here or is it that there's much more than that?

No, I, I think there, there is don't do anything and then there is like the, the other thing is a spectrum. Like I guess we could decide not to do everything that was proposed, but probably it would limit you in more broken state.

Right. Yeah, I think there might be a couple of variation, minor variations on the new approach. But there's basically the current approach and the new approach and then how that may or may not impact multi keys is certainly not something I understand. I'm not sure how much.

Rob, I can't figure this out right now. I, I don't think we have, I mean, I, I think we've now primed this issue. How do we move forward on it? I mean the conservative thing to do is nothing. Right. And the problem with that is that there's some kind of frustration in do I need key or do I not need key? I think it's worth looping in our user assistance possibilities.

Yeah. And I think, I mean I personally maybe once I understand multi key could be bought into the new version, but I can't claim I understand multi key right now.

So my suggestion is if there are places where you likely need key, is there a way of auto suggesting that that would make it a lot less painful than oh, I didn't put key in do I need key? Do I not need key? I'm confused. Right. Seems to me we need to loop that in and see whether both, you know, the conservative approach that says you don't, you know, you put in key more explicitly, you don't auto strip it, but the putting in of key is hinted to you or even almost done for you by an auto suggest that seems, you know, worthwhile. Right.

Which I'll say is fine for interactive, but you know, it may not solve sort of programmatic issues.

Well, it, you know, if you're writing code and you have the code assistant on, then it'll, it'll do it.

Right. But if you don't, if you don't know what X is. Right. Because until some user runs it, you don't know what it will be. Right, that sort of.

But I understand, I understand. I mean, look, I think that the next iteration of this, we should talk about how we, you know, code assist some of this stuff.

Okay. And, and do, do you you want, right? Do you want that to be a meeting with you or do you want us to have a separate.

Why don't you try a meeting without me? That just asks the question, how good can the code assistance be?

Okay.

And then you know, because if it's filling in key, you know, pseudo automatically and just hinting you oh, you might need a key there, I think it could be fairly convenient. I mean, I think the thing that is not very satisfactory is this mystery hunt. Where do I need a key? Do I not need a key? I've got to run the code to find out.

Yeah, Yep. So that's, that's a good argument for having all the things consistent because basically using key will almost never give you the wrong thing with the new changes.

Right. Well, so let's see how good we can make the code assistance and see whether we then feel better about it.

I have one more question. We have had this for some time in the prototype and the only thing we broke as far as we know is databases for Carlo and Leonid. So for example, something like data set, which is also a big consumer of associations and keys, nothing broke there.

So.

But of course prototype is not master. So is there a possibility of testing this in master like for a week and seeing if something breaks and is there an easy way of backing this out?

I mean, I'm not an enthusiast. People are going to in that time, I guarantee people are going to build production code there.

I see.

And you know, okay, I think it'll be better.

Maybe we send an email to lkernel and say, you know, why don't you have code that's very association based. Please try the prototype build and see how it feels because we've made these changes.

I think that's the right thing to do. Yep, yep. Thank you.

By the way, my guess in terms of Data set is that the data test suite which tests more the internal of Data set will not break. But maybe somebody has a data science kind of workflow based on top of it.

That's what I'd be worried about, is external to the kernel stuff. Okay, can we go on?

Yep.

Okay.

Right, so we remember we had some. Discussion of this a few weeks ago, but due to a power outage in Montana, Rob was unable to join us and so there were sort of.

Gosh, it's complicated. So you would introduce string arguments to interpolate it function ages ago in a kind of rogue way.

Yes, yes, I plead guilty.

Right. So go ahead.

Right. And so you know, where we left the discussion last time is sort of, you know, a lot of these things sort of, you know, sort these into things that make sense and to. In information and things that don't. And then we can sort of focus the discussion on the things that, you know, that, that we would like but don't necessarily make sense in information. So, you know, so you, you. We have four groups here of, you know, informational things that likely or definitely make sense in information. Informational things that don't make sense in information because they're internal. Like one of these things is a pointer because, you know, that was necessary for some library to talk to some other library. Right. You know, we're not going to expose that in information. Yeah, right.

I mean, get polynomial. I don't understand why isn't it just polynomial. Except it needs a point.

Could be local polynomial.

Local polynomial, Right.

Yeah, right.

Right. And so the question is, do we, you know, do we wanna sort of document these using a data set like syntax? Right. Because this obviously isn't something that you can get from information. Right. You need to add these two additional data points of the points and your variables.

Well, I thought information had a way to give additional arguments.

You can ask for sub properties, but you can't. If Nick is here, but I don't think it has.

Yeah, I'm here. Yeah, there's no, there's no parameterized properties in information generally. Well, then give a function. Give a function that gets information. Can have a function, a polynomial function or something that's just some pure function that extracts this maybe. Is this important, Rob?

No, no, it's, it's, it's something that Roger had wanted at some point for. And I'm. I honestly don't remember if it's actually used any place or not.

Yeah. From what I've heard from my discussions with Rob and Oliver, who's also here, if, if, if we need, need him. Vector evaluate sounds like the only one that they actually think is useful. Right. So it take. Avoids the normal listable behavior, you know.

Okay, but you've got a new solution for that so we don't have to worry about this.

What's the new solution?

All these vector variables which I'm going to hear about at some point.

No, that, that's not a solution to anything.

Well, in, in the example you're showing. The example is interesting for vector evaluators when you have several points, not just a single point.

Right.

What's the point of several points? Like list of lists.

That's used in finite element stuff all the time.

Yeah. Okay, but what, what, what's different about vector evaluate of a list of lists and just ordinary list of lists that.

One threads all the way to look at the, the two two last inputs in that subsection there, Right. Vector evaluates treats a list as a point and a list of lists as a list of points.

So this is delistability, basically.

Exactly.

Okay. Which is an issue we have in a bunch of other places. Yeah, and I thought we were coming up with a general solution to delistability that involves vector variables that I don't.

Yeah, I'm not sure that's going to work for this case.

Why?

Right, Because. Because in that case you have a combination of scalar things and vector things, right? That is solving the pro right vector variables solve the problem of we have X which is a vector variable and when we add it to the list 1, 2, it stays as X + 112 rather than.

The basic point is you want to be able to explicit list of points, right? You want to be able to say, take this in one gulp, right? Yeah. Delistify it.

Right. And part of the problem with interpolating function is it's not listable. It's. It has this pseudo listability.

In what sense?

In, in the sense that if it. It's not truly listable. But if you give, if you give one argument as a list and the other is a scale, say it's a 2D one, you have one as a list, one as a scalar. It'll, it'll, it'll do threading there, but it's not truly listable threading.

Okay. So the basic point is a two dimensional interpolating function. I, I don't understand why this is a problem. Okay, let me, let me play through this for a second. Okay. We've got a two dimensional interpolating function, okay. And you feed it a list, a list pair like this. What could it possibly mean other than sculpt the whole thing? Because if it threaded then it would be a one argument interpolating function which wouldn't be right.

Yeah, but I think I, I think ITAI is. Is. I can't tell what his if is. Is it two dimensional or one dimensional?

Yeah, it's a, It's a two to one if. If you look at the top of the section, you'll see that it's okay.

So in that case I don't understand why I am of, of list 2.5. 3.5.

So do if vector evaluate say random real of one comma, you know, make an actual list of points instead of just a single point in 2D.

Okay.

That's the case. That. And, and we can be much more efficient evaluating that. Sorry, you want, you want, you know, ten comma, two. Exactly.

Okay, so it's if of this, is that correct? That won't work it.

Right. It's if of vector evaluate at that.

Okay, but listen, listen, listen, listen, listen, listen. We did the wrong thing here. Okay?

Yes, I know.

This is a hand. Look, hold on a second. This is hand list, hand threading, Right?

Right.

Why doesn't the hand threader say I have the type pair to single element. Therefore, when I interpret this, I know that this must be a list of individual points. You see what I'm saying?

Right? I mean, I don't understand why you can't do that. As long, as long as the data is entirely numeric, I think we, we, I think we can probably do that. I mean, Rob would.

Well, how can it not be numeric? Because if it's an interpolating function, it's not numeric. It's going to croak anyway.

It won't croak. It'll just stay unevaluated.

Okay, fine. Then we've got vector variable issues and things like this.

Yeah, I can, I can experiment with that. I think it's potentially dangerous, but it's. It, it might, it might, it might be a way around.

I predict it's going to work. Okay. The other thing. Yeah, go ahead.

Well, I guess one question is, can the input be ever anything other than a. Oh, no, because we use apply. So the input domain is always rn. It's never rn by N or something crazy like that. So we could distinguish between flat lists and matrices.

Yeah.

Rob, am I making, making sense to you? And the answer is yes?

Yeah, I think, I think, I mean, I, I, if, if I understand what Stephen's saying. I think I do, is that, that if the, the last dimensions, if it's given as one argument, the last dimensions matches the dimensionality of the interpolating function, we treat them as points.

Yeah.

Yep.

Yep, I think that can be done.

Good. That seems like a very useful thing. Well, we'll see.

We'll see what kind of ying will be very good at finding the, the chaos that creates if it does.

Let's, let's, let's deal with that. Okay. The second thing we had to talk about here was regions for interpolating function.

Right? So. And I talk about that in the points above the, so the, above the. That, that first long last, straight. So, I mean, one question is, do we want grid and Values on grid which can be quite large. So do we want them? And then there's the question of sort of domain versus a region. And can we have a region domain that's sort of more precise.

I don't understand anything. Maybe one comment concerning the region. So region is a symbolic. Sorry, it's like a spatial construct. But interpolating function can also have a temporal component. So if you call it region, it kind of doesn't allow that possibility. I don't understand what you were saying. So you're saying interpolating function could be of a time series. Yeah, not time series, but it could have a temporal component like a PDE that's time dependent. So here you have a spatial and a temporal component. Yes.

And suppose you've simulated the motions of a drum head on a circle. Okay, so the.

No, I've seen these. They're beautiful. They're interplay.

Yeah, they're beautiful. Well, that's, that's, that's got a 1D set of time with the 2D region.

Space time. It's a region in space time as opposed to a region, right?

Precisely.

I don't think. I think for the last hundred years the concept of a region in space time has not been totally alien.

But that, that's kind of not what our region means.

How do you know our region is just some geometric thing in, you know.

Some number of dimensions that goes up to 3D.

Basically a region can go to any number of dimensions.

Right. We have regions in any number of dimensions.

I think that's a non issue. I don't understand why that that's an issue. Interpolating function doesn't know that, you know, when it's X, Y and time. All it knows is I'm interpolating. It doesn't know if that's a time or a space or anything. It could be an XYZ in space. It's just going to interpolate.

Right. I agree with Stephen on this point. I don't know where, why you know, you as the person who have given it semantic meaning of spatial variables versus temporal variables. But I don't think that interpolating function itself has any such notion.

No, the function itself doesn't.

Right. Okay, so then what is the issue here? So there's the question whether information with a region should say, should have a way of giving a region specific symbolic region specification of where the interpolating function has support. Is that the question?

Correct? Well, I guess there are sort of multiple questions of, of that, that which of, for which that is the first, if we have that does the current domain thing, which currently gives sort of the bounding box. Is that still a useful thing? If we can be more precise. And, you know, I've, you know, I, I don't, you know, I don't understand exactly to what extent, you know, the domain can be not square. But I've certainly know that I've gotten things out of, you know, ND solve. And then even though I'm giving it points that are.

Well, let's let all of us speak, please.

Well, the, the drum example is, is not square, it's a cylinder.

Okay, but so, so hold on, hold on, hold on. If you asked it to solve, you know, ND eigensolve over a circle through time, then the interpolating function does what? Outside the circle, it gives indeterminate. We don't have a solution outside of the circle. Does it give indeterminate or does it get missing? No, it gives indeterminate. We don't know what the solution is. It's not missing. We simply. We don't know. It's not. It's not. Yeah. Okay, so it is super useful then to have a region that tells you this interpolating function has support and is determinate whether it's structured or unstructured. Basically.

Yeah. Yeah. I think my, my opinion is the domain should go and we should, we should replace it with a region.

Yeah, it sounds right to me. I mean, we could, as a courtesy, we could make.

Right. I would, I would just suggest maybe something a more specific name like maybe domain region. Just because region by itself doesn't necessarily to me say input.

Well, where. I see. Well, I think it does, but I mean, that's what we're using it in, in all the, all the regions. But where else do we have a region? Property of things.

Special point data.

Say it again?

Special point data.

Okay, and there it's clearly the. Well, there, there. It's not so much the domain. Right. It's. That's like an actual collection of points.

Yes.

You always specify a region with them.

Let's try calling it region and see what happens. Because it's going to give a region. Object. Okay, I need to go very soon, so let's just have a quick look through here. What is this?

I don't think we can get through this in nine minutes. Maybe the last one. But this is, I mean, if we want to advance control equal, we need to make decisions about equal bracket, you mean. Thank you. Equal bracket. There's a reason I called it the fourth equal, but There, there are both language issues and some interaction issues. But before we can implement anything, we need to decide on the language issues. So, you know.

All right. This is also somewhat dependent on possible extension of control equals to handle LLM processed material. I think it's a mess. This is complicated. I agree. So let's not try to handle it.

That is the first that I've heard of that statement, though.

Me too.

Well, I mean.

Really.

I mean, it's like you use something to get a code fragment. I don't know whether it's control equals or something else. Right. The idea is you want to ask for a little piece of code. All right. I'd love to get through this because. Okay.

Right. So just to remind everyone. Right, right. We're thinking about how to clarify star bracket. And so, you know, Billy, Star carrot. Star carrot. Thank you. I can't speak today, apparently. And so, you know, through a couple of iterations, you know, Billy and John and I sort of came up with what's there. And actually, when I showed that Jose, his initial response is like, what's this decimal times operator? So maybe we didn't do a very good job, but I figured it was still worth discussing.

Well, what about putting the 10 right underneath the carrot?

I don't think that works. It just looks like 10 hats, right?

Yeah, I mean, I think it would be more, I think vertically centering the 10 with the star so it looks more like just a small independent thing is probably a bit.

But what about ligaturing it to be.

What does ligaturing it mean?

Turning it into a, a single ligature type thing. And I mean, in other words, right now we got a big bulb blobulous. Oops, I don't know what I did there. Okay, so we got the big blobulous help. I just want command line. Okay. I've got a big blobulus star wedge. Okay.

Yep.

Even if that thing became smaller and got a really tiny 10, that might.

Indicate I, I, I don't think it can be smaller and have a legible 10 in it. I mean, note that what we made is already larger, actually.

You mean the star wedge is larger?

Yeah, the star, the star 10 wedge is larger than the star wedge. And I don't think the star wedge can be made smaller and have a 10 inside of it. Star wedge could be made smaller if it's just star wedge. Sure. But Also putting a 10 in there, I just don't think it can be done.

All right, so do you guys think I'm wasting. I mean, is there something here. In other words, star wedge just looks kind of incomprehensible and whatever. It'd be nice if it indicated somehow what it was.

Yeah, well, if we're willing to go wider, I think, you know, making, you know, making the 10 vertically aligned with the star and moving the wedge that it's clearly to the right so it looks like times 10 to the fifth would provide some clarification. You know, whether that meets our aesthetics is, you know, something I'm not qualified to answer.

And, and I felt it was important to maintain something starish and something wedgish because I think if you type it in and it turns into something that looks completely different, it. That's just more confusing.

Yeah. Okay, listen, I need to wrap here, so we are going to have to cover this a different time.

Okay.

All right. See you guys soon. Thanks very much.

Thank you.