Live CEOing Ep 776: Language Design in the Wolfram Language ["BC" date strings and More]

Okay. Hi, everyone. Welcome to a Wolfram Language Design review, part of our Incremental Language Development series. And we have a number of diverse topics here. First, BC date strings. Okay.

Yes. So this is a request you had made at a prior meeting, basically, where you didn't really like the signed -400 showing up in date objects.

I do not.

And so the proposal section has basically what I'm proposing. There's two ways we can go about it, one of which is to kind of fake it in date object. And the other is the proposal that I actually have, which is to change the way that we generate date strings for year, both in date object and date string, which basically will do what you were proposing. So for positive years, we will elide an AD suffix. And for negative.

Do we have ADBC yet?

Yes. Yep.

So the second example, do we have CEBCE as well?

Yes, we do.

Okay, so you get to choose.

Yep. So you can choose. It's basically, you know, the two things to figure out are, do we want to do this by default for all date objects and date strings, and then do we want to use BCE or bce?

Oh, God, I don't know.

I would vote for bce.

Yeah, BCE is the common modern convention. You know, there is some discussion about whether it's just window dressing on top of the original problem, but.

And what about AD? I mean, 400 is very obscure as a year.

Yeah, we could.

I mean, in Wolf Mala, we use AD up until you get into the 1200s, I think. Well, okay, so what's the question here? Whether we default the. Because we clearly got to have some default format for data objects. And so the question is, what is it? Is that correct?

Yes. So the proposal section there shows basically what I'm proposing, which is that we have a default cutoff for positive and negative years, where we would show BC in the past, and we would elide it for anything after 1 CE, we could change that threshold to be three digits. Or as you said, if.

Sorry, I'm sorry. I'm sorry. I'm sorry. I'm confused here. So this is. These are examples.

These are examples of what data object would look like with the change. So for all those are all negative data objects, and those are all positive or positive year data objects. So after.

Right. So the only question is, for something like this, I mean, that one is not necessary. But if it was. You don't have an example here. I mean, if this is the weak beginning, you know, 300 A.D. or something.

What else could it be?

Right? I mean.

Yeah, fair enough. By the time it's annotated with year. But do we ever get a case where it's raw? I mean, once it has a January 1st or it has a year colon thing, then we know it's. We're clued in that it's a date. So then we're good.

Right.

You see what I'm saying?

Yes.

Do we ever get a case where it's nakedly just a thing without a month day? You know, if we say January 13, 400, it's clear what that means.

Yes.

So do we ever not have that case where either there's a granularity indicator or a, an explicit year day?

The only times we allied the granularity marker are for months, days and.

All right, fine. So we're already clued in that it's a date, so we don't need to worry about that. Okay, so I'm good with. So now the only question is BC versus bce? Oh, I don't know. You have to ask somebody more culturally plugged in than me or something. Yeah, I mean, I mean, for me it's just. Yeah.

My preference would be slightly to go for bce. You know, maybe we could.

I don't know whether it's pandering or whether it's some.

It's the contemporary convention. So.

I'm looking at various people's.

We've had this discussion on the Alpha side before and just retained bc. We, we, we had the same.

Kind.

Of inconclusive conclusion and we retained bc. We recognize BC as an input, but we sign everything with bc.

I think that's what we should do here. I don't really know, but I'm, I'm, I'm, I'm not.

That doesn't mean I'm casting a vote for that. It's just where we ended up last time we had this conversation for Alpha.

Oh, the 2007. The world ulnite was. It says was the first to switch. The 2007 World of Night was the first edition to switch to bce. Ce Know anything about that, Alan?

Yeah, I think that was two years before I came in there, but. Or maybe. God, I can't remember my own life at this point.

No, I think there must have been.

That sounds right. Yeah, I mean, that was, that was.

We made.

Oh, yeah, we made that.

One small thing is that with AD, it is often the case that it is used before rather than after the year. It shows.

We're not going to do it anyway. We're not going to do that anyway. Okay, the only question is BC versus bce.

Okay. Those are both always after. Okay.

This seems to be a mess. This seems to be a total mess. I kind of think we should stick with bc. I think it's the least kind of, you know, it is the long time historical thing. There seems to be motion towards bce but you know, it's not clear. That's. I don't know, it's one of these. Maybe I just. Maybe it's just because I grew up with all dates being stated as BC rather than bce, but I don't know. Anybody feel strongly about this? I mean, do we feel like it's. It's sort of.

Not strongly? I mean there. Yeah, there are arguments both ways. Again, there's arguments to be made that CE is just window dressing on the problem of, you know.

Yeah, yeah, yeah, I know. We're not using CE by default anyway, so we don't have to care about that.

Right? Yeah, I am fine with leaving it as bc.

Okay, let's use bc.

So two small points. This change will also impact date strings. So, you know, if you ask for the year and the year is negative signed, it will show up as a string with 158bc like in that example.

It's a little weird, but I think it's less weird than having a minus sign there.

Yeah. What I'm proposing is that we basically introduce a new date string element which is I'm calling year signed here, which basically gives you the old behavior. We already have year unsigned. The only question is whether calling it signed means that you would expect a plus on it, which I don't think you do.

No.

Yeah. Okay.

Anybody want to comment on that? Anybody disagree with that? I don't think we need plus.

I'm just thinking whether we need the space between the 158 and the BC. It looks bit odd there with the.

Slash.

That this one here. Yeah, it's totally weird. But you know, let's be realistic. Nobody knows those dates anyway. You know, are we really going to give the ides of March as, you know, you know, 44 BC 03, 15? I don't think so.

Right.

Because. Because even that translation, knowing which day that really was, we don't even know that in terms of our time system. Am I making sense? I mean, it's purely. It was called the ides of March, but we're not going to give it as a date string because we can't align it with anything else.

We talked about AD and bce. There's a question about whether we want to have other variants besides year signed. I Don't think there's a compelling case at the moment, but we could have basically a version that does the same sort of thing that always includes AD or always includes cebce. But we already have the AD BCE and the cebce date string elements.

Look, the fact is the behavior we actually would want is what we've done in wolfmalpha, which is to give the ad when it's an early year but not give it later. I mean, it's absolutely stupid to say 2024 AD. Right, but it's not stupid to say 900 AD. Making sense?

I, I, well, I mean, I think the only case where it's, you know, useful to say ad is years. Less than 100.

1,000, you mean?

No, 100.

Why? I mean, I think less than a thousand. It's very obscure if you just say in 900, so to speak, it just doesn't parse very well. In 900 AD, you 900 CE. You know what you're talking about.

Right, but we're talking about things that are dates. Right? It's not like the, that were, you know. Right. It's right. These are date objects that look like dates. We know that these are dates less than 100. It's potentially ambiguous, you know. Are you talking 20, 24 or 24?

Oh, I see. No, but, but okay, but I think, I mean I, I had this issue in the NKS book, for example, and I wrote, you know, things like in 900 so and so did this and it's just unreadable. Right. Unless you qualify it just because you're not expecting it. If it says in 1492 or something, then you kind of know that that's a date. But when it's a three digit thing, it's very hard to know it's a date. So in any case, I would favor something where we say where we have a way of doing this which says display the year if it's less than a thousand. Display the AD marker if it's less than a thousand. Or C, if we're going to be.

Displaying ads by default. And I'm going to state that I feel strongly it should be cebc.

We're not going to do it by default. I just said this is a way of saying you want that element of a date string. Right. You want something where you are annotating it with either ADBC or cebc. Makes sense.

Any suggestions for the name?

I'm thinking, I mean it's a first millennium. Okay, who's got an idea for this? It's like it is. You give the ad or CE if you're. Let's see. I mean, I was thinking year, millennium A.D. b.C. But that's perhaps too obscure.

I was wondering about year year descriptive. I don't think that's the right direction either.

Year descriptor or descriptive.

Descriptive. I guess we could also say like year era maybe.

Perhaps we don't need to mention the millennium. We just keep it as it is. Year ADBC and document. This works up to year 1000.

That's probably reasonable because nobody's going to want it for, you know, 1922. Just nobody's going to want that. Fine, let's do it. Just year ADBC and cebc.

Okay.

Okay.

Yep.

Anything else on this section?

Nope. I think we're on to the next topic.

Excellent.

This is another thing, I think that came up in a different set of meetings. But the idea was that one, the visualization functions in particular, I think were what you were talking about. But they ought to be able to understand entities as dates. Timeline plot does.

Yep.

So I have this basic proposal that date object and or date interval be able to consume entities and produce a date. There are various hitches, such as we only have four domains that actually have a date property. There are many domains that have properties which are dates, but the naming conventions are not the most consistent and there are potential questions about where we would want to align them. So the analogy I have with geoposition is that if you take a geoposition of an entity behind the scenes, geoposition checks both for a position property and a polygon property, and then depending on what comes back, does something intelligent. So for date object or visualization functions, et cetera, we could basically do the same thing. But look, I think we should a start date, an end date and potentially an interval. Yeah, and sorry, just to clarify, it's.

Geographics, which checks for both position and polygon, not your position. Your position is always position.

Okay, fine. But I think adding a property to these entity types that don't have a unique sort of anchor date is a reasonable thing to do. We could have date and date interval, and it checks for, you know, date interval first. And if not that date, would we. And if it's date object, then it just checks for date. Go ahead, Alan.

For either date or the. The date interval, would we want to always have those things in inherit the value from only one property or in the case of the data, one set of properties each? Or would we want there to be potentially kind of a cascade of things like fallbacks?

No, what I'M preparing if we don't.

If we don't, you know, because like there's construction, start date, groundbreaking date or opening date could all theoretically be right.

Here's what I'm suggesting. I'm suggesting that the, the, you know, we make as a curation type step for every entity. We just decide here is its canonical data interval and date. Okay. So. And just. That's a decision made for every entity. So for example, if it's a building that broke ground, took a hundred years to get built, was finished, then was destroyed 300 years later. Okay. And we're asked what's the date object associated with that building? I would think the thing we do is when it was the default. In that case, we want to finish construction. And if we ask for the date interval. Go ahead. What?

The example at the bottom of the page is exactly that.

Oh.

It's kind of a worst case scenario. It's a building that has six different date properties and they're all different, but. Yeah.

Right. So I think that date is 1932. Oh, gosh.

Yeah. This is, this is the worst case scenario I could come up with looking through the examples.

Okay, well, I don't know if we have, you know, a, A, an entity for Jewish temple or, or equivalent. Right. But then, you know, you could have something that's built, survives for some hundreds of years, is destroyed, then is rebuilt some hundreds of years later and then destroyed a second time.

Yeah, yeah. What do you do with that?

We surely have that with like countries or wars or whatnot.

I mean, it's one of those. Usually we identified, We've had to figure it out on a, you know, a case by case basis. Like we have, we have more than one Yankee Stadium entity, just to take a more pop culture example.

Right, right.

Some, some things have been, they've been constructed, but then they've been added on to.

Yankee Stadium is a religious reference for some of us.

Well, fair enough, but not if you're a Mets fan.

So, okay, the. Okay, what do we. Look, the answer is if you are insisting give me a date, it's got to be one date. We got to do that on a case by case basis and we'll just make an arbitrary decision in some cases. Similarly, date interval. But we have the best chance to do that at the curation stage, not at the stage of, you know, we're making a picture. I mean, yeah, if, if this thing shows up as a dot in some scatter plot somewhere and you are confused by that dot, you got to go in and look at what it did, and then you find out it has, you know, six dates associated with it.

Perhaps someone.

If someone wants to specify a specific date property, then they can always do that. We're just doing this as a convenience for people who want to just drop the entities in.

Right. Because that will be the vastly most common case.

Right.

And this association is very interesting, too. So perhaps there can be a dates property that returns the association with all the dates. And constructively, somebody can take bounds or first or last.

We don't have a lot of entity property classes, but that would be a good entity property class to add in general.

Yes. Well, dates, it would be basically dates. What. What will we call it? Dates. What will we call it? Dates. Rules would be our usual way of doing it, but that's pretty weird. Okay, I think we've got a solution here. And, you know, I do think we should make sure we include, like, dinosaurs with their, you know, dates from 65 million years ago, whatever it is.

Right.

You know, date intervals and so on.

Dinosaur T. Rex. Yeah. You don't want dinosaur or date object of T. Rex to be sometime in the 1800s because that's when the first skeleton was found.

We do not want that.

Intuitively.

We do not want that. Yes, you are correct. We should be the first. You know, when the T. Rex first appeared in the fossil record should be its date, and its date interval should be its span where it occurs.

We expect all the date visualization and other functions are gonna. They should all handle granularity sensibly. Right. Because we do have some cases where we have. We might have a date down to the year. In other cases, we might have it to the decade.

It shouldn't be a problem.

You know, 10 to the sixth year.

I mean, the dinosaur stuff in timeline plot may get weird. I don't know how often I've looked at.

No, let's check it.

Geologic ages.

By the way, I noticed a comment from Sandra on the live stream here about list plot and noting that list plot works with date objects. And I don't know how well documented that is, but we should make sure that some basic examples somehow makes sense.

Yes.

Okay. All right. Any more that we need to talk about here?

There's a couple quick discussion points at the bottom. This is just an inventory of.

Okay, listen, I am not big on discovery dates here being the dates that occur. That seems.

Yeah, we could potentially just say those are not domains which return a date.

I mean, famous gem. That's. Okay, I think that's definitely a. No, no, well, famous.

Famous gems are individuals. Right. They're not types.

They're indeed.

Yeah.

Pulsar is.

Maybe they weren't famous before someone discovered them.

Planetary moon.

Oh boy. Look, there's many that are controversial.

Go ahead.

Yeah, I was just thinking we were only looking. We were just doing kind of a crude search for properties that had date in the name and I'm wondering if we have other properties for. I don't know if we have anything for planets or other things. If we have like age related properties, we have something else that indicates some temporal aspect that we could represent as they can feed into these things.

No, other than we're 4.6 billion years old here.

Yeah.

Nobody knows squat about anything else with that in terms of that. And I think you know, doing things like so I mean that argues for the date defaulting to discovery date for something like an exoplanet. Humph. Yeah, I think I'm not wild about that. I don't really like that very much. Go ahead.

Yeah, I'm thinking we're probably going to have, you know, half of the domains will have a straightforward answer for what dates are there. Some of them will have a case we can argue and we'll probably just need to eventually review some of them case by case. For the weird ones, just say whether it is a date property. I think the final question is just whether we want to accept entities as date specifications everywhere in the language or we want it to be specifically date object and date interval. Know what to do if you want to feed in sunrise of, you know, the Mona Lisa. Sunrise doesn't necessarily need to know that's a date specification. But if you wrap data object around it, you'll get what you get.

I think it would be nice to have the, you know, I don't know what sunrise of the Mona Lisa is going to mean other than when it was painted type thing. Although that's pretty silly because I'm sure it's not known today.

Well, I mean does Mona Lisa have a position as well?

I think it has a position property, but I don't think it's populated.

I mean because I'm wondering if there's cases where you run into ambiguities of whether it's a time or a location for the entity.

Okay, right.

So if you did sunrise of Mona Lisa, you know, might.

What do you think that is? Is that Paris or what? Is that where it is now?

Could.

You.

How curious. Well, fair enough. I mean that's more. But clearly the date, you know, the date when it made its way to the Louvre is not going to be the same as the date you actually want, which is when it was painted. Right.

My, my initial thought with it was have data object and data interval support it, have the visualization function support it as best we can. And then if there's a compelling case after that maybe we expand the functionality.

But Sandra is going. The position could be where the painting is now, where the painting was painted or where the person was. Where the person who is pictured in the painting was when it was painted. Yes. Okay. Any. Any further things on this for right now? I mean, there's some we should put in all the uncontroversial ones. Okay.

Okay. Yeah.

And I think it is a useful courtesy to support the entities as proxies for dates and so on in as many functions as possible. Just seems courteous to do that.

Yeah, we'll, we'll try and inventory places where it's potentially ambiguous. This next one is potentially a bigger discussion.

At least let's dive into it. I mean, this is computational phonology. Okay.

So I believe last year we talked a little bit about phonetic symbol data, which is still under development. IPA codes and generates entity property tables for them. We had wanted to think about what we were actually going to use that for. I've kind of done a deep dive on what the difference between phonemes and phones are and how we might want to represent them in the language and what the actual top level applications might be.

Okay. Well, you know, since we started thinking about this more than a decade ago, well over a decade ago, it's actually closer to 20 years ago, we started talking about this. The world has changed a bit in terms of voice synthesis and so on.

So this, you know, what I've been basically outlined here is looking specifically at phonemic data and ways in which it still is applied that are not necessarily tied into LLMs or to machine learning. There's a lot of stuff that has overlaps and there's different approaches. So basically the high level distinction between phonetic and phonemic is that phones represent all sound and phonemes are the collection of sounds that are meaningful in a given language. And when you're doing transcription, phonemic transliteration or transcription is generally going to be broad. So the example there is like the word little, the phonemic transcription of it doesn't include a lot of diacritics and basically the pronunciation would be familiar to anyone who speaks the language. But the way that it's actually pronounced in different locales or with different accents changes a little bit.

Okay, so wait a minute. Potato versus potato.

Yes.

Is that phonemically the same, or is that already phonemically different? It's certainly phonetically different.

Yeah, it's phonetically different. On a phonemic level, it's similar. So, like, another example would be like the tea in water. You know, you might say water or water or water. It's all spelled the same, but they're different phones phonemically. Those generally are not significant in English for that particular subset.

But you're saying in English it means the same thing.

Yes.

In something like Chinese, it might not.

Right, exactly. So another one would be like the T in tall versus stall. They both sound like tea. In tall, it's aspirated, so there's a little puff of air that comes out. In English, aspirating a T doesn't make a morphological difference in what the word means. But in Nepali and a lot of Southern Asian languages, they'd be totally different phonemes. So the word. The word meaning would change whether you aspirate the t or not. It's like tones exist in a lot of Southeast Asian languages. They don't in most European languages.

Yep.

So the application for this basically would be. There's a lot of basic bits. So, like, word syllables is something we've talked about before. There's a WFR function for it that basically uses consonant vowel pairing, but it's done in a Romanized text transcription, and that doesn't actually accurately reflect the way that the syllables are formed in the word. So being able to transcribe things in something like IPA and handle IPA natively are useful for doing things like accurate rhyming, accurate syllable parsing. There's, in general, two approaches. One is you make a big dictionary and you just look things up in the dictionary. And the other is looking at things like, you know, finite state automata or finite state transistors for things like spelling. Dictionaries typically have things broken into roots and suffixes and, yes, other things.

But we live in the time of LLMs where those stories have changed. Like telling an LLM to. The. You know, it's much more realistic. Well, let's see. I mean, we've done quite well telling LLMs to produce phonetic representations of things with different, you know, what can I say? With different accents and things like this. Okay, let's go back again to the top. First thing is, we've already got ways to have generic IPA for a word. Is that true? Which is some. What you're describing. Okay. There's several things I can imagine here. One is Given an audio, turn it into ipa. Right. That's a thing. Another thing is, given this ipa, how might you spell this ipa? Do you see what I'm saying?

Yeah.

Another is just properties of the ipa, properties of IPA symbols. Like is it a voiced, you know, labial, Whatever it is.

Yeah.

Yes. Right. So that's, and, and all the diagrams associated with that and so on. So I mean, that to me is a very straightforward thing which I thought we had already sort of handled, which was the entity property table for, for IPA symbols.

Yeah. And I believe, you know, that's still in the process of getting built.

Okay, but that's. So that's a definite thing. So that's one thing we know we're going to have. Now there's the audio to ipa, which is another thing that I think should be possible nowadays. Another is spelling to ipa. Right? That's what you're talking about here.

Yeah.

Okay.

And to me there is, you know what? What? In a perfect world, what we would do is we would have the spelling, although it might not be just the spelling because it might need context to know how that word is pronounced. It might not be good enough to just say. Re A D. Right.

So that word read or read.

Right. And you know, with context, you know, but otherwise you don't. So if we just feed it in and we say, you know, give me the IPA for this. Even if we say, well, I mean, I think what we probably need to do in the end is it's going to wind up being something like. And I think we needed this for something else. Here's the word, then here's its context, then here's the locale.

Yeah.

Now I assume that if we look at the different voices, I assume we have Shoddy or Carlo here. Yes.

Shoddy wasn't able to attend. And I don't have.

Is Carlo here? Nope. Well, he should be. Okay, so if somebody could try and get oncology, that would be good. What was I going to say? The. There's got to be a relationship to the voices that we use for speech, synthesize. See what I'm saying? Because each one of those voices will have a different IPA representation for a given word. Now, I assume it's the case that in the world of ipa, you know, this probably isn't the case. I mean, the five year old kid who doesn't have great, you know, diction probably is generating something that we represented as different IPA from the carefully enunciating adult. True or not true?

True. I mean, it again depends on the Resolution at which you're, you know, this is sort of the, the broad and narrow transcription system of. A narrow transcription system gets a lot of detail. Like the difference between the way a Canadian or an American might say little and the way an Australian says it is very similar, but there's a lilting in the eye that if you're transcribing in a narrow band with lots of information, you get something like that bullet point that has a lot of diacratic markers on it.

But so what we don't have like for dates. We have the notion of granularity.

Right.

We don't have the notion of IPA granularity and it doesn't have that notion. Is that a true statement or not? Does it have granularities for different IPA symbols?

It doesn't have granularities, but there are lots of diacritical markers that basically modify.

I see that is this core. If I look at this, I don't see the same core there as I do here. It's not like this with diacritics, is it?

Yeah, I mean the L. So the first character is actually still an L. It's hard to see because it's small, but it has basically a diacritic through it for the lilting and a.

I see. So you're saying in a first approximation, which doesn't seem right here because I don't see the T, for example, I don't see this one having.

Yeah, so that's a American pronunciation. So. Yeah, little. Yeah, as opposed to little or little. Like the, the southern English pronunciation has a glottal stop there, that backwards question mark below there is a.

Okay, stop. But so it is not the case that there is a coarse version that is the phonemic version and finer grain versions which are simply diacriticed up. Is that true?

There's not a one to one translation like that. And again, like what phonemes are available is language dependence. English has about 44 phonemes in it. You know, some languages have much more. Most languages have less, some have only like 11. Like Hawaiians. An example only has 13 phonemes in it.

Okay, okay, but so essentially two, you know, something like phonetic form or something of a word has got to be qualified with many things. Potentially.

Language and locale, like you said would be.

And, and is it a five year old kid, for example, and do they have, you know, a lisp? Doesn't that affect us?

Never thought about IPA representations for, for lisping or not. I guess it.

I, I'm sure that the people who do, you know, Speech pathology stuff, know that. I mean, they, they must have a notation. I don't know what it is. I'm quite certain that when they note down, you know, this kid showed up and was slurring this, that they have a notation for that. And it's probably an IPA based one.

IPA does have some limits and it's not universal, but it's far.

But we should determine what they actually use because it's probably because again, you know, one naive way to do this would be you generate a voice with speech synthesize and then you run a, you know, speech to phoneme analyzer. You see what you get. I mean, that's the. That in a sense should be our ground truth for what comes out here. There is a voice of some kind and you know, it has this phonetic structure that makes sense. I mean, that's a way of providing ground truth.

Okay.

Whereas these other things are all. Okay. So, I mean, yeah, turning things into syllables is clearly useful. It's clearly useful to turn it into syllables in ordinary notation, not ipa, as well as doing it in ipa.

Yeah, I mean, there's kind of two different. You generally have consonant vowel pairs to determine it, but if you're using just text based things, it can be tricky to have robust rules. So, you know, like an fs, most spell checkers use some sort of FSA where they have things like notes and stems.

Yeah, I know.

What I was basically looking at sort of from the high level is that there are not a lot of systems, including like speech synthesizers and other things that cover the entire array of computational linguistics, from phonetics and phonemics all the way up to pragmatics and syntactic things. You generally have an application area you're more focused on. Okay. This is automatic.

Okay, look, the morphology thing in a language like German. Right. Is a totally horrifying business.

Yeah. Some language English is relatively morphologically sparse. German is a nightmare. Chinese morphology doesn't really exist. You know, there. There are no tenses. You just have particles that say, this is past tense, this is future tense.

I. But, but now in English we have this project to try and get inflected forms. Right. Alan, how does that relate to this?

My understanding and I guess, Alan, you can speak up if I'm saying wrong, but I think our general notion of inflected forms that exist is basically built using a dictionary rather than something like a finite state automata.

Yeah, yeah, definitely, definitely. Right. So you know, the term phonemeing, for example, would not be accessible to us. Right. A made up word.

So I guess the, the parent question I have is, do we see merit in having a first class system object that is a phoneme that is either we're going to have phonetic symbol entities that are based on ipa. Is it useful to have a semantically meaningful phoneme structure? And do we want to have phonetic data as kind of the next level up from that?

I don't understand why we need this thing in addition to the entity. What is this giving us that the entity for that critter is not.

In and of itself?

It's.

It may not be that different. It would mainly be if we want to syntactically differentiate, you know, an arbitrary entity or looking within an entity. You know, if you're trying to string together phonemes into phonetic data, having a big list of entities is maybe less useful than having something where we can have individual characters. You know, maybe it's not worth having phonemes as stand a standalone first class object and we just say it's a string that has an IPA character in it.

In it. Or is it. I mean, how do you put the diacritics in there? Are they just part of the sequence? I mean, is IPA always written left to right or is it. Does it have things which are hats and feet and so on? Diacritics.

It does have hat and feet, diacritics. You know, it has graphemes that will combine together.

Ugh. And are those represented independently in Unicode or are they. Is it a grapheme type story?

I believe it's a grapheme type story. I ran into a couple of issues with like the example, most of the way down the page has a Japanese transliteration into ipa and some of the graphemes didn't translate well into Wolfram language, so I alighted them. But like on the do, the O should have a foot on it that extends under the two triangles.

Okay, so that's a rendering issue. I don't understand how we could fail to render the Unicode with its graphemes.

But I'll try and dig into and figure out what was actually. It may be a copy paste error on my side. It was a little before this. I didn't dig in all the way.

All right, so look, next steps here. We clearly need the audio folk involved. Go ahead. I'm here.

I joined five minutes ago, so I don't have the full context, but I think I got what we're talking about.

Okay, what's the status of going audio to phonemes?

I have not seen anything convincing recently. I also haven't looked Specifically for it. The problem is that all of speech recognition at the moment seems to focus on a fully integrated audio.

I know. Nobody cares anymore, right? Yeah, nobody cares. I don't know.

I would have to look more specifically and get back to you because I.

Mean, the thing we need there would be both speak and then a piece of IPA and speech recognize going to ipa.

So for the text to audio, there are some facilities, even in the code that we have now, they are not immediately accessible. They will need some work to be effective. The OS speech synthesizer on Mac and Windows, they do accept ssxml, which is speech synthesis markup language, which also should. And this is part of the specification. The specification unfortunately just says should support IPA characters.

I see. So we're going to need an import format for this SS XML that goes to ipa.

We could. We could just. We could just take the IPA string and convert it to this.

No, I understand that, but I mean as a. We would need. We would want to have also something which is an actual import export for that. For that SS xml.

I haven't seen these files a lot in the wild. I'm guessing they are most used internally.

So I understand they're mostly strings. So it mostly is not an import export for files, but import string, export string.

Yeah, yeah, correct.

Okay, we're not going to get this solved, right?

Investigated a little bit. We've looked at this several years ago and then switched to other priorities. So we need to look again and see what is the current status. But Nick, are you the one.

Yeah, I'd reached out to Julio also, but get back to me. But yeah, I'll send this along to you and maybe.

Yeah, and we can meet and see what the requirements are, the directions are.

I mean, I think we want to at least make sure that we cover things that people talk about in phonology courses, which I don't think is that difficult for us. So. Okay, let's have a very quick hit on these other things. Strings to vectors, Is that for embeddings or what? I mean, is this a precursor to a vector database or is this something completely different?

No, it's different. It's given a bunch of strings, create vectors based on those strings. Useful for clustering and the like, comparisons.

What does numeric vectors mean?

Numeric vectors real valued.

But using a neural net embedding system or just taking ascii.

No, it's. It's based on the ascii, it's based on the engrams. So the strings, for example, could be, you know, genomic.

I'm totally confused. I mean, this looks like a junior version of some neural net style embedding.

It probably is in some sense a junior version of that. But it runs reasonably fast and it.

Can be.

Do reasonably useful things with phylogenetic treatment.

But I don't understand that. So this seems like something for another time. So let's just take another couple of minutes on the phonetic stuff. Okay? Okay, so the things we know, we need entity property for all the ipa, both IPA and presumably these grapheme clusters. But that's where you're introducing, you're talking about introducing. I mean, it's like molecule. You know, we could say we're going to have an entity for every consumable molecule in the universe, but we decided not to do that because the set of molecules is unbounded. So let's talk about, you know, phonetics. Is the set of phonetic forms unbounded or is it bounded?

It's unbounded in. You know, you can have an arbitrary combination of diacritics on an individual IPA character. You know, there's about 800 phones that exist in all languages that are used, but there are many you could synthesize that are not used any known languages.

I understand, but there's only a finite number of. Well, okay, so the question here is, do we have something where we have a fixed set of entities whose properties we know, or do we have a phoneme object that can be synthesized from multiple IPA characters and diacritics and so on, and then look at properties of that. It's kind of like molecule value. Expects to take a molecule which is not, you know, which is a. What can I say? It's, it's the, You know, it's not. It actually does a computation and it can have an arbitrary thing inside. So that to me is the choice here.

Yeah, I mean, it. Yeah, it really depends on the resolution. If we want to stay both mostly at the level of phonemes, then we can have a finite set of IPA based phonemes that exist. If we want to really drill down and have proper phones that can have, you know, arbitrary diacritics, you can have rounded consonants that have aspiration inside them. Then things get more complicated and having a.

So this is analogous to the chemistry situation. In the chemistry situation, we have both. I mean, if I type in molecule of, you know, ccc, I get that, and I suspect I say molecule name of that. Okay. But I can also say pentane. Okay.

Yeah.

As an entity. And if I say molecule of pentane, I should get that same thing there. See what I'm saying?

Yeah. But you could conceivably make a molecule which does not have an entity associated with it.

Absolutely. Easy enough.

Yeah. And so I. I don't know enough about the. The level of detail that speech synthesis currently has or what it may want to have in the future, whether it's useful to drill down to that level of having a phone or a phoneme wrapper, which can be a. A combination of things if we don't care about the. Interesting.

Okay, I lost out there if I say.

I have one quick question that maybe was discussed when I wasn't in the meeting. Does the front end have support for all the IPA related characters already?

It's just Unicode. Except that we were. There was a claim, you know, Nick had a claim that there might be some problem with rendering those graphene clusters.

That's what I vaguely remember from several years ago, but I don't remember.

But I understand, but that was before we did emoji and things. Now we have emoji, so emoji should allow us to display.

So I miss. I wasn't looking at the screen specifically when you were discussing that rendering issue, but it.

Put a copy in chat.

There can be, you know, there could be, you know, obviously font substitution issues or whatnot.

If.

Right. If the characters don't exist in the font, you know, in our default font, etc. But, you know, so. But in terms of, you know, being unable to render them, period, I, you know, I don't see that.

So what was.

What was the alleged problem?

Well, here we've got a. I'll put it in. I mean, this is going through so many different layers of zoom and this and that and the other.

Yeah.

What's wrong with this? I have no idea because I'm not.

So actually, that shows up fine for you. On LinkedIn Linux, for example, the foot on the O gets migrated over to a separate character. So that may be, as ITAI was saying, a font.

I think this is a cute issue that we've been dealing with. You should report that as a bug and assign it to Jason A. Feel free to CC me.

And.

And yeah, we. We have had. I think that might be an actual rendering bug. Not a. Not a. Not a font substitution issue. Although, who knows? Font substitution may be coming in into play.

All right. But it's sounding to me like there is some argument for having a phoneme wrapper just like we have a molecule wrapper. Do you agree?

Yeah, I think there is a case for it. It's mainly you know, is it going to be stub functionality where you can look up basic properties about the phone?

Well, I think that initially it's going to be that there are just like we can have properties of pentane here, that's one thing. But there's also molecule value that allows us to dig in and do things for more arbitrary molecules. So I think we can just model it on what we did for molecules where there are named ones and then there are sort of synthesized ones.

Yep. And then there's an obvious correlation between the two.

Yeah, I mean, sometimes we've got. I mean, this molecule name thing, I mean, that goes to a string. So I don't quite understand that, but I think if I were to take this. Don't know how I get the entity out of this two.

Entity of it.

Yeah, let's try.

If it doesn't work, it ought work.

Yep, works. Yeah. So we could do exactly the same thing.

Okay.

And some of them won't have an entity. So, I mean, if I take this on line 18 and I say to entity of line 18, I need to go in a moment, it will probably say, no, no, no dice.

And I'm assuming this will allow us to represent like a longer bit of speech using phoneme and just reserving the entities for the single. The single items there.

That's an interesting thought.

Yeah, I mean, I think there's a question about, you know, whether you want a phoneme should be a single sound effectively.

I would think so.

Yeah.

Yeah, I see. I see. I see what you mean. Is there a way to represent like a full speech, for example, as something.

I assume it's a list of phonemes, and I assume you feed the list of phonemes to audio and it would then make. Would then synthesize that.

Yeah, I'm just thinking just a string with IPA characters and that just. Should that have a representation in that system as well?

Well, I assume that if you type phoneme of that, that it will turn into some kind of list of phonemes or something, I don't know, that requires thought.

Okay.

But you certainly should be able to just type a list of ip, a string containing IPA characters, just like. I can do this here.

Yep.

All right, sounds good, guys.

Excellent.

Thanks a lot. Be good to finally get this fanatic stuff done. Okay, see you later. Bye for now.