Live CEOing Ep 730: Language Design in the Wolfram Language [Dissimilarity Measures and More]

Okay. Hi, everyone. Starting a little bit late here. We are doing a Wolfram language design review, part of our incremental language development series. So let's see what's first on the list here. Dissimilarity measures.

Yeah, so this is rounding out the first set of suggested functions from our ChatGPT plugin. Specifically, it was trying to use Gero Winkler distance, which we don't have a system as have as a system function. But it turns out we've actually had it as in an experimental context since about 2008. It was added with some of the other dissimilarity measures. And as far as I've been able to dig up talking to Wen and Rob, it just was never documented. So it was never promoted. There's two very similar measures, Gerodistance and Gero Winkler. They basically just differ in how they handle a prefix scale.

Okay. But they typically named separately like that.

Yeah. So gerowingler is basically a special version of Gerodistance that gives extra weighting for similarities at the beginning of a string or a vector.

So, I mean, if these are both widely used in literature, I don't see any reason we shouldn't have them.

Yeah, I think it basically was just something that never got documented and then got put on the back shelf. But I think it, you know, looks like it's reasonably well used in literature. I don't know, Michael, if you have any additional comments there. But I think it's basically just something we should document and put. No, not an expert on this. Okay.

Okay. Now, Roger was the person who was in charge of these originally, and I have no idea why we stopped. Maybe we have notes for why we stopped at this point.

Yeah, I mean, I went back and talked to when and Rob who'd originally put this in, and they, you know, it's been 15 years since it was originally implemented, so they don't have thorough notes. But I did not specifically check with Roger.

When did you say this was done?

This was added in 2008 originally.

Oh, for God's sake. Okay, all right, fine. Let's just put it in.

Yep, that's basically what I figured. But no one seemed to know of why we shouldn't, so.

Okay, take before and after.

So these are two related WFR functions that are fairly popular, effectively figuring out.

A.

Position of a given element and then extracting either the following or preceding elements.

Right, so. So this is kind of like. I mean, The thing that I'm a little bit confused by. So take after could have, you know, like that third element there. This could be, let's say, you know, minus two to two. Am I right?

Yes. There's a question about how to handle zero. I think this is a situation where any span like must not a span, but a range like this should include zero.

I see, but so this would be. Because we haven't really had take specs that are anchored to something like this before. Right. We've always had take specs that go with respect to the beginning of the string or end of the string.

I think that exception would be next prime, something like that.

And how does that work?

If memory serves. And this source of some acrimony at one time. But I believe we include zero.

So if I say next prime of.

Did you see that documentation?

What did it say?

Go back to it. Next prime is. No. Also known as previous prime details.

Oh, that's crazy. That's crazy.

Yeah.

I hope I didn't write it.

No, Roger wrote that. That is clearly a Roger note.

It's cut and paste error.

Yeah, so I, I, I, no, I don't think so. I think he's, it's, it's a badly, it's badly worded, but he's trying to make the point that you can also use it to get the previous prime.

Yeah. So that needs to say.

Okay, sure, sure.

But it needs to say explicitly with negative K. It does this, this is another piece of bad documentation.

Yep. I will follow up on that.

Needs to get fixed. But, but this here minus two to two. I don't understand that. I don't understand that.

So what, what's, so then what is the zero?

I mean, no, no, but wait a minute. That is not a span. That's just, that's just listability.

Oh, yeah, yeah, yeah.

Right. Because zero wouldn't make sense unless, unless that happened to be a prime. Right. So we could see what happens if you did 23 and 0.

Yeah. You do 23 and 0 to get back 23.

Does it should.

Yep.

Non prime.

Then it's.

Which, you know, makes a certain amount of sense.

Nick, for some reason you're writing on my screen. I don't think you want to be doing that.

I don't want to be doing that. Sorry about that.

Okay, so in this case here, how do we get the span, the before, after span? Do you understand what I'm saying?

Including B or not including B?

I'm happy to include B, I think.

With range negative 2 to 2.

How can that possibly work? Well, okay, let's try it. I mean, let's say, see Here. It doesn't like it. It doesn't like it. But I'm not even sure that take after.

From a design point of view, we could make it like it.

Right?

I mean, shouldn't the, shouldn't follow the precedent of take not an X prime. Minus 22 is a span. It's not a list of indices.

No, but it will be the wrong span because minus two means from the end of the list, doesn't it isn't the right span.

Yeah, it would mean before the, the right, I mean, anchor point, whatever you want to call B.

Right. But you can't do. But the point, Bob, the point that we're making is that you can't take a span from minus two to two. That would be an empty span. You can do the span from two to minus two.

Right. Which is not the span you want.

Here because those positions are relative to the anchor expression rather than the beginning of the.

Maybe we want an expressive list and list ability.

And just have the range there and have it be.

Could be a such a list.

Sure, but I mean, this is a relative part specification which we've never had before. Right? That's a new idea. And if we're going to have relative part specifications, where else could we have them?

Well, again, next prime.

Yeah, okay, but I mean, this is like, for example, we could say, and I don't even understand if there are three Bs in the list, which one are we talking about here?

Right, that's the other. That's the design question I have at the bottom of. What do you do for repeated elements?

I presume you do the first one.

Yeah, I think that's what it currently does the, the WF version.

But I mean, you might want different behavior whether it's take after or take before.

Yeah. Right.

So take, take before. Does the first one take after? Does the last one.

Yes.

Unless we want some additional argument that is the nth instance of expert. The current implementation of this, the fourth argument is a level spec.

Another, another issue is are we assuming that the list is sorted? If not, then, you know, Absolutely not.

Why, why would we make such an assumption?

I, I'm, I, I understand. We, we don't want to. Therefore, you know, gets a little weird.

What gets weird?

Well, suppose we say negative 2 comma 2. Are we anchoring this because it's take after. Are we anchoring it to the last occurrence of B.

Presume? Well, sure, but why, what, what, why does the sorting of the list have anything to do with that?

It, it doesn't. It's it's the question I'm asking is how are we interpreting like for. For minus two to two take after anchors at the last occurrence of B and take before anchors at the first. Is that correct? That what we want?

That. That is the proposal. I don't know what current functions do.

Okay, let's talk about some use cases for this thing. Okay. For example, we might want to take the things around are missing and I kind of feel like the thing we're going to want and maybe this is kind of crazy and it's more like given the five missings in this list, give me the little kernel around each missing. See what I'm saying? What are the flanking things of a given element? More so than this particular thing where we're just asking, you know, here it's okay, the thing hit zero or something. Show me what happened next. You know, for every zero, I mean it's more likely to be for every zero. I want to see what was around that zero. Am I making sense?

Yeah, I guess the use case.

I was thinking we could have three functions, right? A take before, a take after, and a take around.

Yeah, but what's being proposed for take around is then take around all of them.

I'm sorry, take around what?

What you're proposing for a take around what. What ITAI is calling take around would be taking the surrounding on all occurrences.

Yeah, yeah, yeah, I understand, but I think that's going to be the useful thing anyway. I think like select or any of these things. There is a case where there's a single argument one.

The string versions of these would be really useful too.

Which ones?

String versions of these functions.

Yeah, I was going to say particular word.

You want to see context for it.

Right. For a particular word. But I mean that, that is. That's more like text words around. Except I don't really like using the term around because we've used around for, you know, numbers with uncertainty. It's a different thing.

Neighbors or neighboring.

It's a bit. Take neighboring.

Adjacent.

I like adjacent.

Take nearby.

Maybe take window.

What else is a. Is a synonym for that kind of thing.

Take before. After.

Take a joining.

It takes. It's going to say something stupid. I know it's going to say something stupid. That takes elements around a specified element in a list. Oh, come on.

Well, you use the word element twice, it's gonna give it back to you.

What did it do here? Element equals four. Okay, that was. That was. I mean, I'm impressed that it managed to write it. Is it correct?

This is becoming a lot like moving map.

Which is a window type thing.

Which is a window type thing.

Yeah.

Yeah.

I mean. Right. It's a very naive version of the function, but it's not.

Right, right. It's like my moving map of identity.

Without moving well, except it's not identity.

It's.

It's only in particular places. Yeah, yeah.

I'm just thinking like the window sort of feeling to it.

Yes. Sandra on a live stream is suggesting take vicinity. I think vicinity is a very. Take. Let's see, Let me see. Well, okay, but let's imagine that we have this thing, whatever it's called. Take margins, take zone.

What about take neighborhood?

I think that's weird because it's not clear whether take proximate. It's very weird. We had take adjacent, which I think maybe making looking better. I mean, we've got other functions that are like split, for example, which is, you know, an adjacency story. All right, so let's say we're using take adjacent here. Let's look at what it does. So let's say a list, an element. And see, the problem is, what we would like it to return here is probably the before, after, before element after, which kind of makes it seem like take window is not the worst name. Because if what it was was take window, element comma, K, then that's saying find the K elements before, you know, find elements. Find a window that is K before the element K after.

That could also be a radius, maybe.

What's that?

That could also be a radius specification.

Yeah, that's. But, well, what I'm suggesting is it's like in cellular automata, where the R value is the distance before, after to go. So the full is two R plus one.

Oh, right.

Yeah.

And maybe like, I think we do this in cellular automata. We have, you know, and we certainly do that in partition. We have K left, K right. Whoops. K, L, K, R right. Which is. Then that allows one to give a window where it's, you know, the elements before the elements after. I think this is not completely silly if this is what we're trying to do. So then. But then it's going to have to have. Oh, boy. I mean, really, it's. Take windows. Right. Because it's actually going to have to be a list of lists. Am I making sense? Because there's no guarantee there's a single element like that. And am I making sense?

Yeah. And if you do only want one, maybe there could be a fourth argument that specifies how many. Yeah, kind of like.

Yeah, yeah, right. But now there's also the question of what happens at the ends. And I think it has to work the same by default. I mean, you know, it's either got to have a padding set up, like partition. Hey, that reminds me, something I would like to do with partition. And this may be more of an LCC thing, just like in cellular automaton, we now have this named association way of SETT cellular automaton. I think we should do the same thing with partition, you know what I'm saying? For the case.

What, you don't want to remember the order of all 9,000 arguments of partition?

That's what I'm saying. Yes.

Yeah, it competes with list convolve.

Completes with what?

List convolve.

Yes, but what I'm saying is this is. See this form here, right? This is an alternative rule spec. This one here, okay. Which I really like. I mean, I use this quite a bit, and I think we should support it the same kind of thing for partition as an alternative syntax. You see what I'm saying? Let's try to make a design of this kind, okay?

Where we.

Where we talk about, you know, I think we have, in the partition documentation, we certainly have names for all those pieces.

The.

Do you see what I'm saying?

Mm.

And we can have a named, you know, a string name for this. Allow no overhangs, et cetera, et cetera, et cetera, cyclic, et cetera. Can you guys make a. Make a candidate design for this, please?

I think the. I mean, I think the. The first question we should answer is would this replace all arguments after the first? Or do we want like the first two arguments and then an association?

I think we should allow the possibility that you can go. I think the way it should work is it should be partition, you know, in other words, if, you know, okay, partition, you know, list, N, you know, S or whatever you call it D or whatever, that's reasonably rememberable. But I think if you start off and you say. I mean, this is not ambiguous syntax. If you say partition and then you've got list, and then you start giving an association, then go for it. In other words, I don't see why we shouldn't allow an association at any stage in the sequence.

That is a considerable departure.

Well, the, the padding, right? The padding can be an arbitrary element.

So which one is the padding?

That is.

None of us know.

Oh, maybe that. Oh, I guess that's the last one. So I guess it's.

Look, I think if you're going to use an association. You will have used it by the fourth argument. Right. And I think. Right, so look, let's study this as not for right now. Okay. What we're looking at right now here is take windows or take window. I don't know which is the right thing. That. And what should it do at the end.

For this span case?

I call this output up. Okay. Yeah, but I mean that it's not going to work if they're two sevens in the list. Right, right.

I just did first position. You could make it something like Danny was saying, where, I don't know, you have to have some rule, some default rule.

Yeah, but I think the default should be all of them. I think that's going to be the most useful.

Yeah. It certainly aligns it with cases and other things like that. If it's defaulting to all of them.

I just feel like I'm going to be using this. I just think I'm going to be using this first at take window 95% of the time I use it.

Yeah, I know, I know. That's an annoying feature of these functions that have. But you see, you don't know in advance how many they're going to be coming back.

Right.

Yeah.

And also, it's not even obvious that take is the right story here anymore, that this is really finding, you know, windows around. It's really more like cases window. Or window. Yeah, cases window.

And you want it to be an arbitrary pattern. Do pattern matching.

Sure, why not?

Exact value.

Yeah, why not? So in other words, this is, You know, this is something which essentially reaches. It's like cases, But it's kind of reaching around. I mean, and then, then we could do, you know, unfortunately, I think string cases window is less and less interesting than. Some kind of text. You know, it's. It's more like text words window, so to speak. Do you see what I'm saying? Yeah, because that's what.

Right.

Which doesn't necessarily have to be words. Can be sentences or paragraphs or anything.

Yeah, well, I mean, so text cases window is a little weird. But I mean, to me, cases window seems the most promising thing. So in other words, it's like cases, but it returns a window. But I don't understand what it does at the end.

It's definitely like a different approach to like what pattern sequence lets you do.

Yes.

Yeah.

Yeah, right. But I mean, pattern sequence, it's an.

Outer approach instead of an inner approach to the same problem.

Right.

The cases with a rule second argument could be adapted for this, blank comma, pattern comma, blank goes to A, blank comma, pattern comma, B, blank.

What are you saying? You're saying cases. What are you saying?

So not for string cases, I guess, but cases where.

Well, to say what you were saying.

Yeah, I guess it's akin to what you have there with the repeated.

Only.

Supplying a rule so that what you return are the things surrounding pattern.

I'm totally confused.

The second argument. The second argument to cases can be a rule.

That's useful, especially if that could be a whole. I mean, I can imagine, you know, you want to find flanking sequences, basically.

Then a genetic sequence or something. Potentially.

Yeah.

I think Danny's arguing you can do basically the same version of this sans string by just using.

But by the way, I don't understand why this isn't a bug. Because A, there are four A's in here. Why did it only. No, there are five A's. Why did it only pick three of them?

Oh, I think because there would be overlaps on some of them and I didn't specify the option in string cases for it.

Okay, okay, makes sense. Sorry, what were you going to say? Somebody else was saying something.

I was saying Danny was basically arguing you can do the same thing with cases, which is true. You could basically.

Yeah, yeah. It's the name for the function. I. I'm sorry, I was just thinking.

What about flanking as the name for the function?

Maybe.

Flanking cases.

What happens if I go three away from this? Okay, just. It just ignores. In this case, it just ignores the one at the beginning that doesn't have enough flanking.

Yeah. So that.

The problem with flanking is that the flanking is the flank. It is not the core of the animal, if you understand what I mean. And this includes the core, you know, the anchoring element. Go ahead. What were you saying? Well, I mean. Okay, I think this is a somewhat interesting function and I think that. Windowed cases or something.

Yeah.

I mean, in a sense, it's more like cases window because it returns the window, if you understand what I'm saying.

Yeah. It's an evocative function name. It's not super snappy. I mean, maybe that's fine, but plus.

Window cases is a. Has a different meaning in the world.

What do you mean? Window cases like casements. Yeah, exactly.

Right.

Yeah, yeah. We have other functions that have window in. Right. Mature.

Yeah. Time series window.

My God, we have window frame. That's completely different.

Window.

Right, right. That's the reason to not use window, although it's used in plenty of these other Ones here.

Looks like. Well, no, that's not true. Everywhere where it's a prefix, it means like a notebook on the screen.

Yeah, yeah. We can't use it as a prefix here, but in these cases it means a statement of a window. As opposed to like this would mean.

The top of window is like the only one where.

No, no, no, look, look, look. These things here mean this is a symbolic representation of a window in a time series. Yeah, right. Which is not what this is doing. This is returning something. You see what I'm saying? So it's a different thing. I mean, and it's too confusing to call it something like cases sequence, because we've already got sequence cases and it isn't a sequence anyway. Well, okay, we made some progress here. Let us ponder that. Can you guys ponder this a little bit further? And look at the string and word cases. Let's go from there.

Yeah.

Key sort like.

So this is a BOB function, but the idea is that you have an association and you're giving basically a list of elements that specify a custom sorting order.

Right. I understand why. I mean, if you were to give a pattern, I mean, there's this kind of like, sort like. What am I trying to say? There's no point in saying sort like, because you're going to give how it sorts and you might as well just give that as the result. The only case that's interesting is when you're doing. I mean, in the case of a list, you can specify a permutation. In the case of an association, I don't really understand why.

I think the main thing about this is you don't have to specify all the keys so that you're just giving priority keys that you always want to come first in that order. And then you don't care about the rest.

Right. Mine allows data to not be in the rubric and it allows values in the rubric to not be in the data. So, you know, anything that isn't matching just goes to the end and the preserved order that came in.

Okay, but so this works right now. Right. So really what the issue is, I mean, so why isn't this then like sort like as well?

Oh, I have a function sort like in the function repository as well.

It just basically prioritizes certain things.

Exactly.

And then the rest is sort left to sort as it sorts. But I mean, in this case, if I take this thing here and I say key sort of this, I'll just get that. And I could equally well say key sort by and if I had a Predicate here.

Right.

I might even implement it that way where like I just thread the values in the thing with range of length. I think that might be how it's implemented.

Okay, Well, I'm still trying to understand. I mean we, we've. We've been interested for a while in these kind of templated specifications of code and other things which. I don't know. Give me a use case for this.

This is really useful for anything that has like metadata. Right. So like resource object metadata or like a packlet info file, things like that. You might want to always show the name and description first and then have the rest of the data however it appeared.

Yeah. When the data is ragged or extensible, so you don't know, the keys are always consistent.

Right. But this is, this is like show some stuff and then there's a tail.

Right.

Okay. All right. So this could perfectly well be. I see key sort like and then sort like. Well, doesn't seem crazy. So then the idea would be, if it's there, sort the things which are matching the things in that third element. Sort those things in that order. So I could perfectly well say something like. If I said sort like of. Underscore integer, underscore real, it would potentially sort all the integers before the reals. Oops, I meant sort like. Does that make sense?

Preserving. Preserving the pre existing order, where possible. All the integers.

That's correct. That's correct. So I mean it would just slide the integer collection down in front of the real collection in front of everything else.

Yeah, that makes sense.

Yeah.

And so then the default would be this comma blank and it would be. It would try to match the first element first. It would take all of those guys, stick them in front, take the next ones, et cetera, until it gets to the trailing ones at the back, which it just leaves at the end. Right.

So whatever order you give it is a precedence order.

Right.

That trailing blank is a fine mental model for how it works.

Yeah. What happens if you put something in the sort, like in the second one where it's not in the list, like if there's not that key just ignores it.

Okay.

Just like it would for a pattern. If there's no. If nothing matches the pattern, it just ignores it.

Does keystart like currently accept patterns or are we just.

No, I don't think it does.

Okay.

Why would it accept patterns? I don't think it has. I don't. We have a key sort by which is a predicate based one. I don't think we have a pattern Based one.

Okay, because.

Because it'll have a sort criterion that is a, you know, an ordinal sort function. Right. A comparator like sort does.

Sure. I'm. I'm just saying, you know, you're propos. What I think you're saying is you're proposing having a key sort like, and a sort like. And I'm commenting on the difference between one taking literals and the other taking patterns.

I don't see why key sort like couldn't take patterns. I don't see any reason it shouldn't take patterns.

It should be fairly trivial.

I can't think of a reason why I couldn't. Off the top of my head.

I'm also not crazy about the name because to me, sort like sounds like, you know. Oh, I guess. Okay, I think I'm starting to understand the name. It's saying sort. Like this second argument.

Exactly. So the documentation would say something like sort of, you know. You know, sort of list, comma, template or something. I shouldn't say pattern. I should say, well, okay, whatever. Sorts list in an order that conforms to template or something like that.

Right.

Should that trailing blank be optional? Should that always be implied?

Yeah, I think we're saying it's implicit.

Okay.

Yeah.

Because you don't. If you're sorting it, you don't want to just removing elements that don't match any of the patterns.

Exactly. If it's a sort, it's a sort and it can't drop.

Yeah.

Right.

I like this function. This is a useful function. This is something where. Because otherwise we're doing a sort by with all kinds of weird criteria and so on. Yeah.

I wrote that weird criteria, like, four times before I made the function repository entry. I was like, this is crazy.

Yeah. All right, let's keep going here just for a few minutes. Quiet.

This one is check, mostly a convenience function. It's a fairly common idiom of I want to quiet all or some subset of messages, and then I want to do something if a message occurs, either to recapture messages and issue them with a new head or to give some sort of failure state. It's not anything that can't be accomplished with quiet and check together, but it's a pretty common idiom, so it may make some sense to combine it into a single.

So I understand what. What it's doing here. It's just saying it's doing the same thing as check, but it is quieting when it does the check.

Yeah. So, yeah, I agree that this is a useful thing.

Yeah. The free Argument form of check. It's always tedious because you almost always want to wrap that with a quiet using the same messages.

A related need that comes up a lot in ILD is to replace message heads. I don't know if this is quite the right idiom for that in a general way, but it might be.

What do you mean? To replace message heads with the actual function being used as opposed to where the message came from?

Correct.

Yeah. So it's pretty common in at least the. The initial versions of ILD functions to. We're calling other functions from top level, but we don't want those functions to pass their own messages up. We want to capture them and reissue them with.

We need a. We need a wrapper that just says rehead the message or something.

Yeah, yeah, yeah. Yes.

I. I just linked a function in the repository that does this.

This also defining or I guess catching the message definitions when it does.

Is this some where you have power, Rick? Would that take blank.

I actually can't remember. It was a while ago when I did this. Okay, I think I probably did that.

I think we should have something like this. I mean, this is a. However, I don't really understand the relationship between this and confirms and, you know, confirm quiet and things like this. And we should look at that. In other words, if you replace something, does it know the source of the source or does it just go with what was there on its face? Do you understand what I'm saying?

Yes.

Oh.

If there was nested code somewhere that was explicitly checking for that power message, it wouldn't actually see that.

Or maybe it does. I don't really know. I mean, it's a question of whether, you know, it's like a dba, you know, doing business as whatever, you know, do you know what the actual underlying function is and under what circumstances do you kind of drill down?

Yeah, very much that.

I think it could get very complicated, but probably doable.

Right.

But I think this is a thing we should. We should take up in ILD another time, particularly when Christopher is around and can talk about how it relates to confirm and so on.

Yeah, well, maybe take a.

Okay.

But I think quiet check, particularly with its the third argument to check. I see. Unless those messages.

Yeah. So when I'm using that form of check with the three arguments, I almost always wrap that with a quiet using that exact same list of messages. So I just have to repeat that list of messages twice, which is kind of tedious.

Right.

Because those are the things you're looking for and you're Handling. So you don't want to spew messages about them because you have.

But now this thing about message groups, we have never properly handled that. That's part of the error handling working discussion. Right. To deal with that.

Yes. I don't know what the current status of that is, but we can maybe loop that.

You're not talking near term.

No, I'm not talking instantly.

I, I don't even mean intermediate term for what? This message groupings.

We've been talking about it in the error handling discussion.

The last time we talked about it, your opinion was that it wasn't really a useful thing to expand.

No, it isn't. It isn't. It's not. It's not. We needed.

Error handling is the more important by far.

We need a different strategy for these things and message groups, is not it? I mean, again, we've talked about this a zillion times. We've talked about the case where you want incredibly persnickety error handling where, you know, if anything could possibly go wrong, kill it to, you know, hey, if it's roughly right, I'll let it through type thing. Am I making sense?

Yeah. And that very much is error handling and very little message.

I agree.

Yeah.

We'll maybe have an error handling summit.

And ILD quiet check seems fine. It seems useful and it goes along with other, you know, quiet star functions.

So this, now that Rick brought it up, we should consider message replace.

Oh, I agree, I agree. Can we bring that back to another meeting like this, please? Please do develop it a bit more and bring it back here.

This is something I need incessantly for ILD stuff.

Fine.

And contrary to what Nick may have suggested, I don't mean needed just for first implementations. No.

Yeah, fair enough.

Right, yeah.

So this next one is a variation on round that rather than giving the, you know, an absolute value, you're rounding to, we're giving a number of significant digits. You know, the kind of common idiom of round this value to four digits. It's fairly popular in wfr. One possibility, Danny and I, and I.

Think I hate the name.

Yes. We don't like decimal round as a standalone function, at least by that name. But perhaps there's some merit to having a scaled headdress in round to represent relative error, effectively relative number of digits. I. I don't think it 100% fits, but there is an argument to be had that it is, you know, using that is incomprehensible.

Nobody will ever understand it.

Yeah, well, scaled may be the wrong headdress.

Yeah, I understand, but, Well, I mean.

What about using a list does round.

Yeah, I was just going to say N is already a precedent for accuracy.

I know it's a hard to understand feature of N. Look, I think this thing about make this a four significant figures thing.

I, I would just say that, I mean, even without understanding that. Right. With N you can give it a singleton list. So you know, round four means round to multiples of four and round list four, give me four digits. That's not hard to understand. Even if the full generality of the two are, you know, the two element list is more difficult to understand.

We might want that though. I wouldn't.

Yes, I understand, but what's this, this.

I'm proposing would be round PI to four significant digits. Because in N you can either give it a, a single element list, which means precision. Just give the precision.

You don't mean list.

No, you don't mean list. You mean a single element. You mean this?

I, I, I said singleton list, which is exactly what I mean. A list containing one element. Right. You can also put a, a singleton for there.

No, you can't. It's right there. It says it's an error.

Huh. Okay, so what am I thinking of?

I mean, we could make this work, but it doesn't work right now.

I'd like to know what you were looking at.

I think he was looking off into space and not at the screen.

Okay. I, I, I, I, I, I missed where that we skipped.

Okay, all right. Well, okay, well, okay, but so, so what happens if I say PI of n, of PI comma 4 comma 10. I don't understand what that does. 10 comma 4. I don't know what this is doing. A thousand PI. I don't understand this.

Or so four places.

Right. So it's accuracy four. So four digits after the decimal point.

So make it six comma four.

Okay. Then it's going to limit on.

Yeah, yeah, yeah. So it's the first. Whichever comes first.

And well, it's going to limit on the thing that is first constrains it. Yeah, yeah, yeah.

And decimal round could conceivably have a similar.

The thing that I don't like.

Round.

Yeah, but round right now does not have a digit count. It has a, I mean, what about something like digit round, round to some number of digits. Which by the way would have to have an accuracy precision type thing in it as well. We'd have to decide what the default is.

This is in some ways similar to decimal form, I think.

Yeah.

Which is probably why it was called decimal route.

Maybe.

Yeah, it's similar to this decimal form. Ben Comm. But that is a print form.

Yeah, that's the. That's a big difference. But nonetheless, the spec is very similarly.

Treated, which is why decimal round is not therefore that crazy a name. But it's a little bit. It's an. It's. I mean, but digit round doesn't seem crazy to me because it's like round this thing to four digits.

Is it clear that we don't want to use round with a different.

Because, Because I think round. Look, round takes a second argument which is, you know, nearest multiple of whatever.

Okay, sure.

I just don't see a way to do this.

Yeah, that won't. You're right, you're right. That won't play nice.

And it really is a digit based version of round, which is because round is part of the family of round, floor, ceiling. I mean, I don't know. And floor, you know, there isn't a lot of sense, is there, in having a ceiling comma. Go ahead.

Right.

Digit ceiling doesn't make sense, does it?

No. So that, that I, I agree that this is a good argument that put. Sticking this into round is a mistake. Yes. And I know what I was thinking. If, if you've defined an N value with just a single. With just a single number, it'll be stored as the two element list. And that's where I got. So I'm not completely crazy. I'm only 50% crazy.

Why doesn't digit ceiling make sense? It does. I don't think it would be commonly used, But here we have the same problem with that second argument.

So, so, so what, what, what, what would you want it to do? You'd want it to round to the. It would basically just round up the last digit to whatever precision.

Yes.

Yeah.

And down. So, yeah, it's the usual problem with fives, but otherwise.

I think digit round is somewhat useful. I think it's a.

Yeah, I think the. I think the other reason not to stick this in round is that, you know, round has, you know, function expand rules and differentiation rules because, you know, you can make sense.

Yeah, I'm convinced you guys were right. Don't put it in round.

I might just suggest digits round. So you're rounding to some number of digits.

Yeah, it's not crazy.

None of our digit functions currently are plural.

But what are the digit functions that.

Is in digit count, digit sum.

Digit round sounds cleaner.

Okay.

With. Without the digit round.

Without the s. Okay.

Yeah.

And put a pin in digit, floor and ceiling for now and think about the more.

Yeah, they're one of these things that in another century people make much more.

Obscure than use cases, I think.

Right.

Okay.

All right.

We should probably wrap up here. This has been good and fine thanks to folks on the live stream. Thank you, people here. See you all soon.

Thanks, everyone.

Bye.