Live CEOing Ep722: Language Design in the Wolfram Language [ChatGPT ILD functions and more]

All right, today is a day of many live streams. We now have another Wolfram language design review, part of our incremental language development series. And I'm sort of hoping we don't have too many things to go over here. All right, Select. So did we talk about these before?

Yes. So we started talking about this idea that having a conditioned version of some of the pattern based functions would be nice. Select is a conditioned form of cases. We don't have one for position and count. And where we left off was saying, okay, we should inventory which functions this would apply to. And it might be nice to have a naming convention that uses some sort of preposition like the by functions. So one thing I was looking at is we don't have any collisions if we just reused by. But I don't know that's exactly the direction we want to go here. Again, cases, position and count are the primary functions this would apply to, though cases we may not need because we already have select right position, potentially have position by or count by. And then there are just some other alternative options that I looked at that don't seem awful.

Well, I mean there's like position select would be. So what would they be? If, let's say it was select star.

What would we have? We'd have select positions and select count and then potentially select pick, but I don't think that one is quite as applicable. And then I don't know if we want to extend it to the predicates like match queue or member queue.

What would it mean though?

You.

We could basically have rather than a pattern based predicate, we could have a function test.

Well, I don't understand why that isn't just the function itself. I mean, if it's member queue of. I'm totally confused. Why isn't it just the predicate P of whatever?

Yeah, I mean the extension for member key would be, you know, do I have any members in this function which are integers? It could conceivably be written other ways.

Well, it's. That's any true.

Yeah, I suppose that's true. Okay. Yeah. So the predicates were one that I wasn't sure on, but I think it is probably true that we don't need that for member queue or match queue. And free queue is kind of complicated.

Right. But so the only cases we're really coming up with are position and count.

Right. And so this originally grew out of the suggestion to have a select position or select positions. That would be a condition based version of position.

No, you mean a predicate as Opposed to pattern based version of position.

Yeah, yeah.

And what about the possibility of a wrapper that turns. How do you go from. I mean, isn't it purely blank? Isn't it this. Isn't that always equivalent? Your. Your example there?

Yeah. Mm. Sort of even q.

I mean it makes me think that a more. A cleaner version of this would be a wrapper that is equivalent to blank question mark. Even Q just makes it slightly more attractive. And how would we say it? I mean, That's what we're talking, right?

Yeah.

I don't buy select positions anywhere as a name because it's suggesting you're selecting the positions. You're not using select and returning the positions. Right.

Yeah.

What would we call if we wanted to have a wrapper name for quest for blank question mark? F. What would we call it? My initial thought was something like to pattern.

Yeah. Predicate the pattern or something with test or. Is true is probably too general.

No, because that's not. That's.

Yeah, it's not exactly that.

It's not the right thing. It's a. It's a pattern object that matches based on a test, which is essentially what question mark is. Mm. Okay, I've got an idea. What is question mark anyway? Is it pattern test? What is it? What is its full form?

Yes. Button test.

Yeah, Pattern test.

Okay, here's a question for you all. What is the one argument form of pattern test? Does it have one? It doesn't.

Yeah.

So what's that the equivalent of blank comma f? If patent has to one argument matched blank question, you know, blank question mark thing, then at least this would work. And I'm not sure how obscure that is, but. I actually think that's a reasonably useful thing to have something which is just. A pattern that matches anything for which that argument for which that predicate gives. True.

We have the opposite direction in match Q. MatchQ converts patterns into predicates. So this would be the opposite of that.

Yes. And it's not inverse match queue either. Let's see, It's almost like match when. Or by actually match by it.

Certainly shorter than pattern test.

Yeah, I mean match if is perhaps slightly relevant.

We don't have very many match functions currently, so autocomplete would be pretty straightforward. You wouldn't have to tab around much.

I don't know. I mean that's another mechanism then for slash, semi, even qx. Is it useful or should we better document blank question mark blah blah. I mean blank question mark blah is much more. As much more flexible because you can make the blank be some more complicated structure and so on.

Yeah, it can be blank null sequence.

Let's find out whether blank question mark blah is properly documented. I think this is not surviving this idea.

Yeah, I mean, I do like the symmetry there of it potentially working in blank question mark both within the pattern based functions and within assignment. You know, the. As you said, the, the slash semicolon form is very useful when setting down values, but it's not always the most obvious.

Well, but is this more obvious? I don't think so.

I think. I think it's more explicit.

Well, let's consider it. I mean.

Okay.

Okay. Options with a conversion spec.

So this was something Jose and I had discussed a while ago. So the specific instance that kicked this off is that julian date and from julian date are functions that have a time system option. But because we don't have a dollar time system we run into an. Is the time system an input or output time system? And it's potentially useful to be able to change either one of those. But we didn't. The idea of adding another global dollar sign variable feels a bit old fashioned. Yeah, we could say there's an implicit time system for all inputs and you can block dollar time system to something else and set an output time system.

That's grotesque.

Yeah, but what we were thinking is that potentially using a rule to say this is the input time system, this is the output time system is both very explicit and, you know, reasonably flexible to extend to a couple of other places where, I mean, we're also using.

That for like translations, aren't we?

Yep. So that's the example there with transliterate is. Transliterate uses a rule syntax, not for option but for an argument.

It nests correctly with the option. Right?

It does nest correctly. Yeah. The precedence is. Okay, so there's an example at the bottom there too in column where base style doesn't explicitly document this because it normally takes a list of rules. But you can give base style with one base style specification that uses the same precedence.

Ok, so the basic point is you're saying time system arrow blah is a statement of what time system it's in time system arrow blah arrow blah is a statement of wanting conversion. Is that correct?

Yes.

But I don't understand if the thing that you've put in there has a time system. If this one has a time system, doesn't it know whether the time system. The outer time system, I mean.

Yes, you want the case in. In Julian date is less problematic than the one in from Julian date. So julian date Generates a number. When you say time system goes to tye, that means that output value should be in ty and whatever the input is has its own time system, either explicit from date object or implicit from whatever we specified as the input date.

What is.

You go to.

What is julian date?

There is now, in the example I.

Had, well, that would be a Julian date number. And from julian date that that date should be a JD number.

Okay, what happens if I say julian date of, date of now you get a number. Oh, I see. It's a pure number.

Yep.

Well, then you have done. This is a perfectly reasonable thing to do. And that should also work for, you know, for getting it from absolute time. I assume.

Right there we would have the. The same type of issue. And, and this could be extendable to time zones, perhaps.

Yeah, particularly in functions that are both constructors and containers where we sometimes do conversion. This sort of specification is nice. If you say, oh, I have this date list, it's in gmt, but I want it to be in Tokyo time. I can construct a date object and say it's in GMT and then call time zone, convert and convert it to Tokyo time. Or I could say, here's the data object, it's in GMT or it's in Chicago. I want it out in.

Yeah, I think this is perfectly reasonable. I don't have an objection to this. Okay.

This last section is looking at some of the functions that we've mined from.

Chat GPT queries that it invented.

Yes. These are functions it assumed existed and did not don't actually exist. Some of them are slight variations on existing functions. Some of them are.

You know, we are in a weird world where we are basically looking to the AI. Anyway, it's, it's all right. Let's take a look here. What it's got digit sum.

I mean, this is a pretty trivial function in and of itself. You know, it's just total of integer digits.

We had a thing that was called count. What is it called?

I mean, I think total at star. Integer digits is the right way to do this.

Probably. But isn't there a digit count?

There's integer length. Is that what you mean?

Oh, no. The number of D digits in base. Whatever. You know what? Digit sum is a common enough concept. We should just have it. It's silly. I mean, why not just have.

Well, but it's so. It's so easy to do. It's total of integer digits, which is.

I know, but, but, but it's also convenient when you see it.

I'm going to argue, I'm going to argue this is not a function to have.

So.

Because both. So okay, first of all, Christopher, you know, I think it's just kind of bloat. You know, it doesn't. It is so easy and obvious and readable to write total of integer digits and it's also just as efficient as this. The only reason to have integer length is the fact that it's more efficient because it's just doing, you know, floor of log based whatever than it is to do length of integer digits.

All right, well only what are the.

Use cases for digitsum.

That too word.

Problems or cute math puzzles, but otherwise not a whole lot.

All right, I think it's bloat. BLM has been overruled.

So we'll see in a couple of cases. One of the themes with some of the functions that aren't things I think we need to jump on immediately is that they are different names for existing functions. So like under that proposed but not likely useful section there is Cartesian product which is just outer or potentially distribute.

Yeah, well that's, that's just a question of documentation.

Yeah. And so I think, you know, some of it is documentation. Some of it would be, you know, it'd be nice to have an easy way where if I say digit sum either, I mean I don't think codesys is necessarily the right way way for it, but if I search for digit sum, if there was some way to link to an example that's in integer digits.

Yeah, right, right. But I mean also, you know, the LLM is going to get more sophisticated at looking at documentation when things don't work right. It's going to discover digit sum doesn't exist. Search for digit sum, you get the total of integer digits. So long as we can tell it that.

Sorry, going back to the previous function, we have a function called divisorsigma. It does the sum of the divisors and it uses the opportunity to raise to a power. So I wonder whether the same thing can be done with the digits themselves. It's a whole different operation though. One is extremely difficult, the other is triviality.

Well, there's a different point. Divisor sigma. You know, there's math literature going back 150 years full of that function.

Yeah.

That is also something people talk about and have talked about back into the 1800s and sort of puzzle math.

Does it have a name? Digit sigma?

No.

That'S. It might be less.

With divisor sigma. I think the question is, you know, how many number Theory theorems. Does divisor sigma show up in.

The answer is lots.

Yeah, so.

Which. Both is because it's, it's a useful concept, but also because it's useful to have something called divisor sigma. Because if I'm reading through a number theory paper and I see it says, oh, here you use divisor sigma, it's nice to then just have that function. But if the number theory papers aren't saying digit sigma, if instead they're saying the sum of the digits, which they're not saying nearly as much as they say divisor sigma, by the way, you know, then not as much.

You effectively mean not at all.

Right.

It's not used.

Not true.

I mean, not a number. You're right, but yeah, exactly.

By the way, we have a divisor sum too. I'm just learning these things right now. And it has additional arguments. Again, we could use the opportunity to do the same thing with the digits.

You know, mathworld certainly has an entry that says. Oh, well, look, actually MathWorld claims it has even a notation, a digit sum. SB is whatever.

I feel like that the standard should be. If we can find a bunch of papers that have a standard way of referring to this, that would be an argument for having a function for it.

Agree.

But if it's just a cute thing that people use words to describe, then it's not really.

Well, honestly, I mean, we've seen enough cases. I've seen this a million times in, you know, recreational math type stuff. Is that what the hell happened here? This should be reported, please.

But the thing is, for recreational math, it's no harder to write it as total of integer digits. Right. If you're doing recreational math, that's a trivial and obvious thing to do. And in fact, I bet most people will do that. Even if we have an integer or a digit sum function, they won't know it exists. The argument for having it would be the case where it would actually help you do the math is if you're reading something and it refers to a.

Piece of terminology, turns out digit sum seems to be a commonly used term. There's a lot of places which use the term digit sum.

Well, are we just assuming that because the LLM spit it out?

No, I'm looking on the web. For example.

Can I ask another question about this agenda here? It are these things sampled from the list that Michael Trott sent out?

Yeah, this is a subset of those.

Yeah.

There was also a lot of stuff on there about elliptic curves and calculus for elliptic curves and and then one.

Okay, but that's not what we're talking about here.

The other one that was on Michael's list that said it was the. There was some popularity ranking that Venn Diagram was the most popular.

Yes, but this is not what we're talking about here. We're talking about the ones that we're talking about here. There's a separate discussion of. Look, I. I have to tell you, I'm looking at digitsum. It is all over the web. There's. There's just tons and tons of people who use that to that name and they mean that this thing. We should have this. The LLM was useful here. It's silly not to have it. It's just like. Like everybody calls it that. People know what it is. We should have it. And MathWorld seems to even call it S sub B. But we could just call it Digit Sum. I think we need this. Let's keep going for the things here. Why is Venn Diagram not on this list?

Yeah, we don't have. We didn't have availability for the visualization team.

Okay, fine, fine. That's the only reason then. Okay, Digit Sum. We should have. Sorry, guys. We should have it. It's just too common. It's like. Okay, capture graphic. That's a really weird one.

I can see this being potentially useful for generating something like form functions. You know, we have.

Sure, we. I thought we had a thing like this. I mean, is this. Is capture really a thing? In the modern world.

It'S usually not. I mean, in the modern world there's lots of different verification systems, you know, match said picture, captcha, you know, conceptual diagrams, notably.

I think a lot of those things also, they're not, you know, they're also doing things like tracking your mouse and looking at the timing and doing stuff like that to try and guess.

Yeah. Seems a bit old world. Seems like a good thing for wfr.

Yeah.

Commonest words.

So we do have a list of commonest words that's available through Word list and Word data. We don't have a standalone function.

No, but what we do need and what I've needed a zillion times is somehow words ranked by frequency. So I can pick off the 10 commonest words.

I think that would be easy if word frequency data worked better.

Well, but you don't want to be generating 40,000 of them every single time. I mean, it's also very undefined. You know, you say one of the commonest words in an article in articles about cats and the answer is cat will be very Common, but you know. Right. I mean, there is sort of another.

Way you can do it, which maybe you could get through. Control equals is just a little thing with, you know, what, you know, sampled entity class of, sorted entity class of word.

What the heck would that be?

Well, no, I mean, you can represent this in the whole entity class framework. You can use sort entity class, you can sort word entities by frequency and then use sampled entity class to get the first N of them. Okay, I think control equals could do that. That would also be fine.

Right. But the bigger problem here is that the problem is undefined. I mean, the following thing is true. Given the training set of an LLM, there is an answer to what are the commonest words. That's a ground truth for commonest words. But if instead you're just saying, well, I pick cats, you pick dogs, we're not going to agree on the commonest words.

Yeah, I mean, we talked about this idea of having word frequency data have. Be weighted by the corpus. We're measuring against it for things like being able to generate a random word that is based at least on. On usage to some.

Well, random word based on usage would be useful. That would definitely be useful. I would have used that many times.

Yeah. And I believe Francisco and his team looked at it to one degree or another. But I think there, you know, there were some technical complications and then there were just some logistical complications of getting people to spend time on it.

And I can solve that. Well, okay, But I mean, you know, in a sense it's ridiculous to say, you know, it's like people say I is the most common word, but clearly not in written English.

Yeah, it depends on the, the corpora.

Yeah, the. In written English. Right. But I probably in spoken English, I, I wouldn't be surprised if I is more common than the. Certainly more common than the. Well, I don't know, the. As in you in the old English version of you. So I think this is a question partly for Alan of is there a reasonable definition? Because I must say I would have found this useful many times even to get assorted commonest words or something in word list.

Yeah. Or the, you know, rank the 100 most common according to our word frequency data or 1000 or whatever.

Well, right. Which is analogous to brightest stars and other such things. Right. Yeah. Having a hundred common words, even if we, I mean, they'd clearly be somewhere. It's pretty arbitrary at the boundary. Yeah, I think that's an issue for Alan about those things. Okay, now the plumbing of word frequency data is an Interesting question, which really needs to be raised again because that was messy last time I talked looked at it.

Yeah, I will check in with Alan and Francisco and maybe we can collect a few things to talk about there.

What on earth is this about? I mean, we have bra. Ket.

Yeah, we have bra. Ket. We have ket and brah.

This is a Michael question. If Michael says we should have it, we should have it.

Michael was on the fence. Itai was not very enthusiastic about it.

Ask Mads. Ask the quantum. Quantum framework people. Okay. I don't have an opinion. For me, this is like really, I don't know.

Yeah, I, I don't see a pressing need, but I didn't see the statistics on where this usage was coming up. So.

We can round out random polynomial. I don't know. How do you define a random polynomial?

You give degree variable a range for the coefficients. It should be integer. I think maybe we can allow rational and possibly a sparsity.

But I think that gets tricky.

And I think it gets harder with multivariate.

I think I feel like it would.

Be useful if maybe people studied random polynomials and there were known random polynomial distributions.

Yeah, exactly.

And then we have a giant system for it.

But I do actually use that stuff from time to time. But, you know, it's a wheel I don't mind reinventing for myself because I.

Think every time you reinvented it's going to matter how sparse it is and things like this.

Yes, that they're, they're all the subtleties. It's just I don't think worth trying.

To make a function.

I think it's hopeless. Random string. I kind of think it's the same thing. It might write Shakespeare. Is this useful?

I mean, I've found myself generating random strings, but they're generally with some specific purpose in mind.

Well, okay. The one thing I can see that might be useful is something like random string of, you know, ATCG, for example, comma 10.

So that would be the final example there with the, the resource function. So it, it takes a list.

Yeah, that's a list. But I'm saying give it a string, an initial string or an initial list for that matter.

So it'd be, it would be equivalent to string join a random choice of.

Characters, comma n. Yep, that's what I'm suggesting. I mean, I have to say I have found string tuples useful many times, but that's for rather specialized purposes.

I've never heard of string tuples.

It's a, it's a wfo. Oops. It's just that, I mean, it's useful for specific things I've done, I think.

In general, I think. I think cute little functions like this are sort of, you know, they're only really useful if they're more findable than it is easy to write them, but, you know.

If you use them enough that you can remember them, then it makes sense.

I guess.

Yeah.

I mean, random string strikes me as a prime candidate for stake and wfr. Unless there's a strong case for.

I kind of think that it will be.

I mean, it reminds me of the REX function in snp. It's like, what the heck is this doing? Like, what, what, what is this sampling from?

Well, I know, but this kind of distribution, it will be around, as you say, it's a random choice of the. Of the characters of that string.

So it's like some kind of uniform distribution of strings of length n. Well, what's random integer?

Random integer is a uniform distribution across the integers.

Right, but I'm just. In that case, it's pretty easy to imagine what that is. But in the case of strings, I just think it's sort of like. For example, the one place I could imagine using random string is for testing. So it's something like, I just want to generate. I'm testing some functions and I want to test it on a thousand random strings. Then maybe I would use this. But then it defeats the whole point if I have to write three arguments about what kind of random string I want. I mean, it's just like I would just write it myself.

I was kind of thinking the same thing about random polynomials. Of that, when it seems useful is if you need to test some algorithm.

Yeah, I know, but. But then you need characteristics of a polynomial at the point. Whereas with random string, there's a pretty obvious. Okay, so let me give you an.

Actually, no, sorry. Strings have the same problem. If you're testing things, you know that take strings, you want to test things with, you know, weird Unicode characters and with, you know.

But the much more common case is I want to generate a random molecule, for example, or a random. You know, we wanted a random biosecur.

Pretty difficult.

What's that said?

It's pretty difficult to generate a random molecule because you don't know if the binding energies will all work out.

Well, it's easy enough to generate a random biosequence because guess what? The brilliance of DNA is that it always works out.

But why, first of all, why do you want a random bio sequence other.

Than for making Demos for making demos.

That's not a great reason.

Well, I don't know, maybe there are some. We don't know what the biologists are doing. Maybe they have to train some things on random sequences.

Yeah, which they. The, the generation of the random sequence is a microscopic part of the whole problem.

Some sort of Monte Carlo method.

Yeah, but I mean, this is a. Look, my only argument for random string is it's very obvious what it does.

I was going to say I had sort of the same reservations about random date when we first proposed it and it sat on the back burner for a little while and then we finally came around and said, oh, we should have a random D. And since we've implemented it, I use it pretty much daily. You know, granted a lot of that's testing things, but it's.

Yeah, well. And similarly random point in a region has turned out to be very useful.

That one would obviously be useful though, because that's non trivial to do.

Yeah, I know, random point is great.

I, I think random string is not dead yet.

We won't consider it priority one, but we'll keep it.

Yes. All right, we should probably wrap up from this meeting, I think. Let me just see. How do you get the month names?

So calendar data for a given calendar will give you the names as strings. Date value will also give you the month name. We don't have them as symbols. It asks for Japanese calendar or Jewish calendar.

Something more exotic. They even have months. So they did.

They have a counting step that is closely related to months.

19 of them.

So you do Babylonian calendar.

All right.

Nice. Modular differences in transliteration potentially.

And interpolation. But that's probably a thing with a lot of these.

Yeah, that we have separate intercalation. Why did these transliterate into English?

Well, so we don't. We typically include transliteration for the date. So you know, if you said calendar convert of now to Japanese, you would get a transliterated form rather than a Kanji representation.

Can we not say language are a Japanese?

We can within date string. You know, you could say date string of now and.

So what's the question here? So, so, so the question is, do.

We need a dedicated function that gives you month name like we have for day name and if so, would we.

What does day name. What does day name do?

Day name gives you a symbol corresponding to and you can see.

Oh boy. But we don't have month symbols, do we?

We don't. And the main reason for that is may. We were concerned that may would be useful for a different symbol at some point.

The others are pretty straightforward.

Yeah.

March might be useful as well.

I suppose so.

Yeah.

Could you say that more augustly?

Maybe we'll just have all the months of symbols except for May. I mean, is there even value? And I mean, I feel like, I mean, well, one having them as symbols instead of strings is maybe of like marginal value, but maybe you'd get the same value. If you really for some reason thought that it was useful to disambiguate that this was a month, you would have a wrapper that's like month of quotes, May, month of quotes, April. I don't know what that would be.

But I don't know what that is. I mean, I think we've got date value. I mean if we, if I say date value of month, I would hope I get that. It's kind of.

Yeah, the. All, all of the date element names are also keyed into date string elements.

Yeah, I understand.

You could ask for month name shorts or month Roman numeral.

Right.

So I tend to think since there's a couple of different ways to access this information, which doesn't need a standalone function.

Yeah, I'm not that I. I think date date value is a fine thing to have. Okay. I think, look, mostly arguably we need to start generating documentation for the LLM to tell it things that you know and then feed it as. As you know, eventually as fine tuning training to it and then it won't be confused. I mean, it's a funny twist on the kind of human documentation side of things. Yeah, I don't think we need this, but we should absolutely keep the list of how the LLM was confused because we really should generate a, a thing for the LLM to tell it how to unconfuse itself. Does that make sense? Okay.

Yeah.

Also, as we segment the prompting more and more, you know, there may actually be specialized prompting in these specific areas. All right, we should wrap up for now. Great, thanks. See you guys later.

Thanks everyone.

Bye. Bye.

Bye.