Live CEOing Ep 791: Language Design in the Wolfram Language [DateObject Typesetting and More]

Hi there. Welcome to another Wolfram Language Design review. This is part of our incremental language development series. All right, first item here. Date object typesetting update.

Yeah, so we've been doing a little bit of refinement on the way that Data Objects typeset, and we wanted to get feedback on it. The first noticeable thing is that we're trying to de. Emphasize the information that isn't just the date string by making it smaller. It was already gray, but kind of in the same way that I like it.

I mean, I. I have a question. The space here, and I think this is easy to read. It's just. It feels like it's a little bit unspaced between. Where. I don't know. It doesn't super bother me. I just. I don't know what's quite, Quite going on. Is that the standard space in that font or is it something where we hack the spaces in some way?

It's the standard space in that font.

All right. Does Jeremy or anybody want to make any comments on that? Does it look okay to you? No, it's. It looks fine to me. Yeah.

And it's the correct spacing.

It's not tightened. Okay.

You should look at it 100%. That's 150.

Just to make sure you think the.

The gray text is readable enough.

I think so. I mean, I think. You could be confused. It's slightly small, you know, in some.

Of these long string cases.

Well, I think the long strings are less concerning because there's more kind of. You have a little bit more data to operate on. Just see. I mean, what I worry most about. Let me just see. You know, if somebody's saying, oh, I didn't notice it said GMT -18 or something. Oh, that can't really be right. But, you know, well, GMT's five or versus six, you know, in this case. Sure. What did it look like before?

Quite a bit bigger. You could just copy that into a.

Normal notebook, I think.

Right. Or. Yeah. In a different version, if you evaluate those. The case I was not 100% on is the last couple of cases where there's a little bit of a seesaw up and down because some of the information is in front of the string and some is after. Yeah. If you just. Original impetus is that it felt a little heavy to have this information.

There sure does. I mean, that's crazy. You even need to show the time zone.

If it's the current system time zone. I guess we probably want to avoid dynamics.

Yeah. I mean, we also. There's There's a different case for. If the time zone isn't shown, then it's implicitly none. Which means the. The information is.

But doesn't it say ET? I mean, GMT -5 is not. It should be saying ET or something like this.

Well, yeah, it depends on your dollar time zone. If you were to do that with, you know, if you. Time zone, convert now to dollar time zone entity, for example.

I'm sorry, what do I. If I do.

If you say. Yeah, if you say time zone, convert that to dollar time zone entity. Time zone convert. Yeah.

What's dollar. What are you talking about?

Dollar dollar time zone entity.

Why can't I just say dollar time zone?

Because dollar time zone currently is just a offset from gmt.

Okay, so if I take that over here.

You might have to reevaluate it in this case.

I don't know. I think for these short ones, this is a little bit small.

We could bump it up another.

I think for these ones, which are, you know, summaries, as opposed to astronomical French, which is not a summary, it's a whole long production. So I'm saying that could go small, seems to me. But these ones, like, you know, people are used to seeing times with an EDT on them and things like this that, you know, this is much more parenthetical, seems to me.

Okay, we could leave the time zone where it was and just modify the calendar.

I think so. And I mean, I think these ones here. Well, I'm not sure if you wanted to leave it where it was, but I mean, that would also. Well, it would partially solve this problem. It wouldn't completely solve that problem. It would still, you know, see saw if it was a. An astronomical French thing. But by the time we're doing, you know, minute, blah, blah, blah in the astronomical French calendar, I think we're. You know, the fact that we can do it at all is. Is lovely. Am I making sense?

Yeah, yeah. We can make the time zone bigger, maybe halfway between what it used to be and what it currently is.

That sounds reasonable to me. I think being able to parse the thing where that's a distinctly different object would be good. Okay.

And we do time systems the same. It's another, you know, abbreviated form where we have TT for teratime or dynamic terratime. So it basically occupies the same field.

What is tt?

Terrestrial time. That's time system. Like, okay, okay, fine.

Yeah, yeah, okay. I know, right? Like, okay, that makes sense. I don't understand why this says Julian date. I mean, this is Julian time. Right. This is the Julian.

That is the Julian date calendar in this case. So that that number is a Julian date, not to be confused with the Julian calendar, which is an unfortunate coincidence that they both use the name.

Okay, but when you say astronomical French, I mean, is that not really the French astronomical calendar, right?

Yes, that is the French calendar. There's an arithmetic version and an astronomical version. One of them is doing real astro computations under the hood, and the other is using a formula.

But in terms of what we call it here, it seems to me it should be called French astronomical rather than astronomical French, even though the calendar type is astronomical French, which is probably correct. See what I'm saying? But when we describe it, it seems like it seems better part of speech to say French astronomical. But maybe I'm wrong.

French astronomical sounds weird to me without saying calendar after it.

Well, does astronomical French seem any less weird?

It's like saying that this thing is astronomical French somehow.

Anybody else want to comment on this?

Yeah, I mean, I think they're both slightly clunky, but I think we were trying to avoid being super verbose by having calendar.

I understand. When you've got calendar and time system and time zone and so on, how are you merging those together?

So if we have time system and time zone, we can pretty much merge them together. So if you take that TT example, that's down a couple, and you Change it to 0 to something like -5, it will say TT -5 instead of GMT 5.

I see. And then it ends with Julian date.

Yep. You could change the Julian date to a different calendar and it would do the conversion.

What's a good other calendar to use Coptic?

C, O, P, T, I, C. I.

Know how to spell Coptic. Is that all I have to say?

Yep.

That is obscure. That is deeply obscure.

Right.

Especially the time system. Okay, what's the. What's the most complicated named time?

They are all abbreviations, so.

I see. Okay, bye.

So they have like three letters at most.

Yeah. UTC would be our longest string.

Okay.

Okay. Okay.

Okay. Then nothing. I mean, that's. All right. Now, this our beginning set, whatever it is. If I say date, object 0, 00, comma, and then the granularity comes next, is that correct?

Correct.

Really? I see. BC is burnt into the date. What is century 99 to 0 BC? Why is it that century? I don't quite understand that. Why isn't it the century that begins?

So year zero is being canonicalized to year minus one, and so we are falling to the first century B.C.

Yeah. If that was one instead, you would be going to the first century.

I don't understand why this is 101 B.C. again. Oh, because this thing is canonicalized.

Yes.

To that year. Okay, let's do 10 AD. That's a moderately obscure thing. I mean, with no AD or CE after it. That's pretty obscure. Although you do know it's a date. Okay. I mean, and if I now were to say here rather stupidly, you know, Coptic minus 5 TT, it's probably gonna complain.

Yeah. In that case, because the. We don't have century mappings in all of the calendars.

Okay.

Yeah. So some of the calendars have entirely different units of time that don't align you. You could have that be year. For example, Coptic calendar has years.

Really? How could it be year 10 in the Coptic calendar and yet now is 1740?

Because the way you are inputting that it is assuming that date list that you're giving it is Coptic.

Yes. Okay.

If you changed the output, if you change that Coptic to Gregorian and then said calendar type goes to Coptic, it would do it.

I get it, I get it, I get it. Nice. Okay, what else do we have to talk about here?

I think that's pretty much it. On the. The visual design. There's just the question of do we like the granularity also being the smaller weight like the calendar?

I think so. I think that's, you know, most of the time you don't really need to see that.

Yeah, it's. It's theoretically to help disambiguate cases. Like the difference between second and instant.

Yeah, sure. Which is nice.

Or year just not being a blue number floating somewhere.

Yeah, I think it's nice. Anybody else with comments on this?

No?

Okay, good stuff.

Let's move on. If you want to skedaddle, you're welcome to Jeremy.

Okay, thanks. See ya.

Bye, guys. So we proposed these a few months ago and Danny has implemented them and we just wanted to do a once over before having them.

Okay, so this is the all true. This is the analog of all true, et cetera, et cetera, et cetera. This is as cases is to select. This is to all true, etc. Correct.

Exactly.

Okay, Nice. You can parallelize it.

I will ask Roman about making that. That's not implemented yet.

Why aren't you saying that first usage yields true if all of the EI match the pattern form. Why do you have to say it in that convoluted way?

I was following all true. But your suggestion also reads nicely.

Okay, okay, So just so I understand. There's no pattern matching operator that represents this. Right. In other words, if you're saying, so any match is vertical bars, is it not? Is alternatives. No, no, sorry, I've got it the wrong way around. I've got it the wrong way around. This is checking for a list. Does everything match? Blah, blah, blah. So, for example, yeah, if I say zero, one missing, you know, two, three, and I say any match. Underscore missing. So how does this relate to free Q and member queue?

So one of them. Yeah. Any match is essentially the same as member queue.

Okay.

I guess none match would be analogous with free Q.

Yeah, this is one of these cases in which introducing a family generates a duplication with one existing function. It happened with the contains family too.

And what ergonomics are different?

Well, the fact that we have the three together, so before we had only member queue, which is any match.

No, I understand, but if you look at the details of member queue in terms of its level specifications and things like this, can we at least make sure that these are orthogonal to that?

I think it's very similar. If I remember correctly.

I assume that the documentation pages point to each other.

Pointed to match Q.

But that's not right. Oh, that's for all. So if I go to any match, I hope that this links to member queue. Yes. Okay. But if we look in detail a member queue, The level spec works the same way.

No, any match takes a level, not a level spec.

And Ben McHugh takes a level specific. Yep. So any match is specific to a level, whereas member queue can go over a range of levels. Is that correct? Right. I'm not thrilled about the synonym stuff, but I guess it's okay. I mean, this is a. This is a Rubicon that we have not crossed so much before. We have. We do have some examples of this.

Yes, I do remember that. I think it's this joint queue and subset queue have some contains family equivalent.

Yeah. Contains any, contains all. I mean, look, that kind of synonym stuff seems to work okay for natural language. I guess it can work. I mean, I think. I guess it's okay. All right, let's do it. But maybe we should explain in the notes for both member queue and any match that they are the same. That they're basically the same has. So that people are not confused. What's different between these? Well, okay. They're basically the same.

Yep, Yep.

Any match has similar functionality to member queue, but is part of the match family or something. Does that make sense? Something like that. Just saying. It's the same functionality as member queue is like, well, why the heck is this here? Okay, onward. Fixed point graph. We seem to be finding this useful a bunch.

Yeah, Brad mentioned that you had suggested we bring this back again. We also have Charles here. I guess the question that I had, which Ian also brought up is is there any meaningful difference between fixed point graph and nest graph with infinity as a final argument? The only one I really saw is that fixed point graph has the potential to have a same test option like fixed point does.

The idea that nest graph with infinity would even work was not one that had occurred to me.

I think previously it did not work, but it does now. Okay, but people, two identical outputs are the two different input forms of the same thing? The first one.

Well, but does nest work with infinity?

I don't believe nest does. No.

Maybe it should. How can it know that it should work? Well, because, you see, it's a little bit.

If application of. If application of the function at some point doesn't change the expression, then you could terminate.

Yeah, we just assumes no side effects in the function and things like this. Yep.

Which I believe infinity is doing.

Say it again.

I believe that's exactly what nestcraft with infinity is doing. But Charles could speak to that.

Sure. So I mean, basically, I don't know why nest. Okay. Nest list clearly doesn't have an infinity setting with ordinary except with an infinite list, which is a different story. Right. Because nest list. Somebody's got their.

That was me. I just switched my meeting.

Okay.

I now have.

Hello again. Okay.

Hi again.

Okay. Anyway, hello. Okay, so nest list with infinity argument would generate an infinite list, which.

Not necessarily.

Yes, necessarily. Nest list would generate an infinite list. It's not going to stop.

If the function at some point doesn't change the input, then you could terminate early.

But you shouldn't. It will be a mistake.

Yes, it's kind of abusive notation is what I would say.

Yeah, I mean, nest list of blah blah blah comma n should give a list of length N or n plus one or whatever it is.

Yeah.

And fixed point is a list of unknown length and that's its point. And fixed point has the rule that if it stops changing, then it assumes it's reached a fixed point. Makes sense.

Yeah.

Because you.

You wouldn't want nest list to terminate early in the final case.

No, no, no, you definitely don't. So now nest graph. Like nest, I mean, okay, so nest could terminate early. Right. If it didn't have side effects, it could terminate early. Am I correct?

That seems really wrong to Me like what if you want to use it to just run something indefinitely with some state in a function that changes that state. Yeah, like as an open loop, you mean? Yeah, I mean, so a common thing that someone might do is like while true comma and then a thing that you just want to run indefinitely for some reason.

Well, but you do that with Nest, with infinity you'll say, yeah, and if.

It just stopped at some point, that just seems wrong. I asked it to go an infinite number of times.

All right, well those are all arguments for why Nest graph shouldn't. With infinity just shouldn't be. We don't care about it. I mean, in other words, it's a, it's a well using. But go ahead.

Nest tree supports infinity. How once the tree doesn't change.

You.

Either return none or an empty list for all of the leaves and then that's it.

Well, that's like it's implicitly an up to specification, right?

In that case, yes, yes. Well, so what about Nest Graph?

Well, what about the name nest tree implies that it has an early ending condition.

Yeah, I'm not wild about that. Honestly. That seems like an invitation for bugs. And fixed point tree seems like a better concept if you really want to have that.

Yeah, yeah. But also the fixed point graph, if you provide it, the correct iterator will get you a tree.

Well, that's fine, but won't get you a tree tree. It'll get you a graph tree, so to speak.

Yeah, I'm sure there's a converter between graphs, obviously.

Yeah. And when I write code to convert different kinds of expressions into a tree, infinity is what I want because I want to go through the whole expression. I can't specify a depth at first because it's supposed to eat an arbitrary.

Expression, but there's a certain argument the fixed point tree is the right way to do that. I, I'm liking fixed point graph. I see no problem with it. I think it's a good thing.

Can we look at the WFR page? There's some bigger usage examples under applications and neat examples there.

So that's in a sense an up to usage of Nest Graph.

Well, the reason that that's there is because you might be, you might want to have this Iterator. You don't know what it's going to do and you want to test it for a few levels before you potentially hit a hang up or something like that.

Okay, what's all this stuff here?

This, this is also explaining that the fixed point graph function has a. Has A built in canonicalization of states feature. So in, in the like games context or in the the say building polyominoes context that you could automatically filter out some states according to their symmetries. And this is the sorting thing that I think we talked about before briefly where if you're going to introduce different fundamental operations for how to shift or transpose elements in a list, then.

You.

Can have all sorts of different paths to obtaining the.

Yeah, it's nice, it's nice. It's a very nice example. Why is it so complicated with all this release hold nonsense?

Just. I think it has to do with the way that the function evaluation is working.

Okay, well I mean I wouldn't do it with necessarily the function evaluation like that. But we get the point here. I mean this is a thing where you're going, you're doing a fixed point graph.

So fixed point graph also takes an N in the third argument. But it's an up to.

Yes, just like fixed point does and.

Also just like nest. While that's just a safety feature. Basically an extra safety feature which is convenient. Yeah.

So in addition to the normal graph options, should we also have a same test here?

I think so, but. But let's understand what Brad has done with canonical and sort and so on. I don't understand those.

We definitely test with the canonical signature thing. I think that is. That's happening in a neat example.

If you scroll down, can you explain to us what.

Yeah, yeah, yeah. Well, remember when we did the games post, we calculated the whole game graph for Tic tac toe. But that was before we had bothered to filter out canonically equivalent game states. So now this is the new game graph for Tic tac toe. Once you filter out canonic states that are equivalent by rotations and reflections of the game matrix state matrix.

That's there but that's a feature that we could have a nest graph as well.

We could. Yeah, I think so.

Which is. But I don't quite understand why that isn't just part of the function that does the nesting and nest graph and fixed point graph.

Well, you mean why it's not part of the. The first argument. Yes, well, I mean it could be, but.

Okay, fine.

But this is, you know, one way to.

Yeah, okay, fine. But I don't think. I mean I think it's one of these things where for somebody, if they want to have only canonical things produced given that at every step they are, you know, there might be 15 things they could produce but they want to canonicalize those. I really Think that should be part of the first argument generically?

Well, what's wrong with providing an option to separate?

Because it's more complicated and it just isn't. It isn't. You have to explain that and it isn't in the right place. Let's understand the other.

Well, but somebody might think that it's less complicated because instead of trying to cram a bunch of junk into their first argument, they've. They've got a little bit of junk.

Hold on.

A little bit of junk?

Yeah. But you don't even know whether it should be canonicalized or whether it should be equivalence testing or what it should be. Let's just understand these other arguments that you have here.

Well, no, I mean, I know what it should be because I wrote the function.

Yes, I. I know, I know.

And the people who go in here and read the details.

Yes, well, absolutely.

Presumably they will.

It's a fine thing to have. Okay, okay, let's look at these, please. What is sort function? So wait a minute, that's again something where if I just put sort in the first argument, function, I would get the same behavior.

I think that you'd have to take some time to really study these definitions and understand them because I've done something new and interesting here.

Can you explain why it is different from just sort of the first argument?

Well, what this is actually doing is it works with the canonicalizer to try and choose. Because remember when we did the Polyomino post, we wanted subsequent items to be rotated in a particular way that they looked like the pre. The previous vertices they were built off of.

Yeah, okay, I understand. So that's what does canonical transform do?

The canonical. The canonical transform is an alternative to the canonical signature approach, which doesn't necessarily get the best. In this previous example I was explaining, it doesn't necessarily get the best rotations.

Here's what I think. I think we should have fixed point graph as built in function. I think we should not initially put in these options. I think we should have a same test and I think we should try to document, you know, if you want canonicalization, put it in the function that is generating the things to be produced. Because we could have the same issues of canonicalization in any of the. I mean, you know, anything nest list could have canonicalization too. We just don't do that because we put it in the first argument. So I think for this, you know, this wfr, these are lovely things to have and they lead people in a certain direction, but I don't think we need that for the, for the built in function, at least at the beginning.

Okay, so do you want to talk about how the same test works? Because that's going to be a similar issue to.

Yes, I want to talk about how it works. How does same test work for fixed. For fixed point, Fixed point list.

I think the result of the first argument has to be. I think it feeds the result the previous two results of the like. If you call each item in the list a result, it checks the most. The two most recent items and.

Yeah, and it quits when same test is true.

Yeah. So since the result here is a graph, I think that the function should be a function of the two most recent graphs that have been produced.

I understand the claim.

So it would just be saying applies s to successive pairs of results. But, but in this case, the, the type of those results is a. It's a graph object.

Well, hold on, hold on, hold on, hold on. This same test is just the leaf results. What you're proposing is something which would be for fixed point. The equivalent thing would be.

No, well, there's no leaf. There's no leaf.

There's no leaf because it's in time, successive in time.

It's a path graph, basically.

Yeah. Right. So whereas fixed point graph, there could be a whole giant frontier that's been added at the step.

Yeah, but what I'm saying is we got into this as a little bit of an argument last time. The frontier is not the result. The result is previous graph, the frontier.

One version of fixed point graph is it stops when the frontier is empty. Right. So there's two possibilities. The frontier is empty or the frontier is. I mean, I don't understand this. I don't understand. If the frontier is repeating nodes that have already been visited, why aren't you getting self loops for that? You should be.

No, because it filters those out on the next step.

But maybe it shouldn't. I mean, in other words, it doesn't.

It doesn't make duplicate edges. Okay. And if you get back to somewhere you're at previously, the only thing that's going to happen is you're going to potentially make duplicate edges.

I understand that, I understand, but. Or nominal or most trivially, a self loop. Right. In other words, if you start, there are self.

If you look at the WFR example notebook, there are self loops, but the self loops don't stack and become multiple repeat self loops.

Okay, but it's not clear that.

Oh wait, we passed one. There was one right there on the zero there.

Yeah, okay, It's right to have one self loop, it would be completely wrong to not have one self loop.

Does nest graph give a self loop for that? Just try the same input.

Yeah, let's try it.

Add nest graph.

Well, I think you have to set the infinity though, right? What's the infinity?

Yeah, I know. So let's set 30 steps here you can do.

But infinity should work too, right?

It does.

Okay, so we get the same thing. That's good.

So what's notable here is that we don't keep looping on the zero node, right? Because we could with Nest Graph with 30, for example, it's going to go 0, 0, 00.

If you did, then you could never reach a fixed point.

Indeed. But nest graph, it's not clear why it should. I mean, this is the same argument as with nest list or nest. Nest could reach a fixed point and stop. But we're saying we don't want it to do that. We want it. If you said nest for 10, 10 nestings, you really want 10 nestings.

Well, I mean, what's. Charles is here. What's his definition of a graph? Do we give priorities to graphs that have. That don't have duplicate edges?

Well, it's not a matter of having duplicated edges. Right. So here the way you is more the way you define the construction of your end result. And by definition we map it from the input to the output without counting the number of iteration of appearance of the edges. So it's more a choice in the way you construct the graph than anything else. Okay, so, okay, the main point here is in terms of the same test, the issue is, does the same test apply by isomorphism presumably to the whole graph? Or is the same test. I mean, maybe we shouldn't have.

It's actually not even. It's actually not even isomorphism. That would be too costly.

Would it make sense? Like usually same test is just you're only testing something once. Would it make sense to say that it's terminating test gives true across the entire frontier?

The terminating case here is that the frontier. Okay, so one test which is not right. Okay, so one test is the frontier is empty. This graph here would fail that test. It would not terminate.

Yeah, but if you say that the frontier is all is either empty or it contains only vertices that have already been seen before, that's probably fine.

Okay, hold on. If the frontier repeats itself, you know, but I'm worried about a case where there are edges that should be crisscrossing, knitting things together. Even though maybe I'm wrong. Even though the Nodes are the same even though the nodes. Yes, yes, yes. The following is true. Let's say you've reached node 7 or something. Okay. And there's a connection from node 2 to node 7. Okay. And let's say you're adding nodes in order. Okay. But there is no direct connection from Node 3 to Node 7. It went through Node 4, which went to Node 7. Okay. But on the next step, Node 7 wants to generate Node 3 and it says, no, no, no, you're done. You don't need that because node 3 already exists, but it's an edge before it.

Before it says you're done, it will sew an edge from seven to three.

Okay. And that says, I've been here before. Go ahead.

Does that mean the same test should be applied to edges?

No, I don't think so. What Brad is saying is, okay, same.

Test is applied to both vertices and edges because the same test is applied to the graph, because the graph is the result. The same test is replied to a pair of successive results and the result is the graph. So it could be that, yeah, edges and vertices are the same because at the basic level, that's what the graph is.

Okay, so hold on, hold on. But another thing is the set of vertices that I have now visited is a set of vertices, all of which I have seen before. Yeah, then that constitute a termination condition.

Yeah, I think so. But you do have to be careful about potentially picking up one last backwards edge at the end. Yeah, I mean, you know, the. It doesn't. It's not going to matter to. Oh, no, I guess it will matter to the user how you specify it. But I mean, in the mechanical details of the things. Yeah. Maybe you are checking the frontier, checking the edge set. But just from a user point of view, I think you should say that. I think that the check should be on the graphs because the graphs are the result.

Okay. But any user specified check that isn't. Are the Graphs identical? Right. G1 equals. Equals triple equals G2. Yeah, it's going to be graph isomorphism, which is going to be dog slow. Or maybe it's going to be something like, you know, vertex list of G1 equals vertex list of G2.

Yeah, yeah, that would be perfectly fine.

Okay. I'm not convinced this should be a user modifiable thing because I think it's too complicated. And I think explaining what it is that we're actually testing and the fact that we have an optimization of how we're doing the testing means I don't think it should be User modifiable least not at first because I don't know.

It also doesn't do the job that Brad's canonical signature option was doing.

Right.

Which is treating vertices as equivalent, not the whole, not entire graphs.

Right. But my claim is that the way to achieve what Brad is doing is in the function that is doing the iteration. So you don't generate the tic tac toe ball that aren't in canonical form.

So we're not trying to capture that with same test.

I don't think we can.

I think no, those are two separate things.

So I think no same test for now. I think same test is too complicated a concept. Please note in the. In our private, you know, design notes on that function page why we're not putting in a same test and then let's do it without the same test with the same mechanism as. What are we saying? The same mechanism as Brad has implemented here. Make sense? That's going to be a fine new option.

So. So basically, yeah, no, we're not doing any options other than the graph options.

Correct? Correct. But otherwise it's exactly your design. Great. Let's move on. Directionality and origin in first position.

Yeah, so this was another thing. It's been independently suggested a couple of times. But I think Brad had also mentioned, you know, we have first position, first case, select first that all operate on a vector or an array and hunt through for some given.

I know. So the question is, could you make them hunt from the end? I've wanted that many times. Or hunts. What does the argument structure of these things look like in first position? It's got a lot of stuff there. This is not looking promising to me. Got a lot of arguments that specify things that you want to specify. Does anybody have an idea how to do this?

My initial thought was that having an option gives us flexibility for the fact that there's different argument structures in these. But then how it interacts with them the arguments is potentially I'm thinking of.

The direction options.

Like we have in sun position also.

So we have direction in limit and time direction in the ASTRO functions. Time direction cannot be used here. But direction perhaps.

Yeah.

What does direction mean? If you have a range as your.

Level specific, don't you need a tree.

Traversal order if you have something on more than one level?

Yeah, I hope not. Yes, you obviously do. I mean in that case I just.

Don'T know what left to right means in isolation.

No, it's not going to be very meaningful in that case.

But perhaps each level has a right.

I Mean it's like leftmost outermost. Is it the. You know, the direction is the leftmost part of it. The outermost part is a different. As a tree traversal order separate from the level from the direction spec.

I don't actually know. Does first position go in like bottom up, depth first?

I don't know. But the level spec thing seems pretty surplus to requirements here.

We'll just keep whatever the normal traversal order is and modify whether it's right.

To left or left to right. But. So the concept will be direction to minus one means go from the end, I guess.

So.

A start position other than at the beginning, how would we specify that? I mean you could just use take on the expert or drop rather on the expert. I don't know if we have an example of that, but I. That has been a thing that I have needed much less often.

Yeah, I think directionality there's a fairly strong argument for. I think the specifying a start position is nice in these first cases because we don't need to duplicate the expression which if it's very large using take is can be not expensive.

Yeah, okay. I mean that's a problem for this year. I don't think we should change the language for that optimization.

Yeah, I think that that's the primary case for it as far as I can see.

So let's raise the question, does last position make sense? Do we forget the direction option, which seems very weird to me and just say we'll have last position, last case and so on. How many of these do we.

Believe? There's only the three.

Well, select first.

Yeah, select first and first case.

First position, first case, select first. I mean, I don't know, maybe we should just have a last version of this. It would be very clean in code to say, you know, last position of whatever. It doesn't seem. I mean, you know, the whole question about the replication of functions is here's the general rule. If it is, if there is no additional cognitive load associated with the new function, then you might as well introduce it. The difficulty is when you have to understand the new thing to understand the new function.

I was looking at position just in case we find the need there too. And it has an N argument and I'm a bit surprised that it does not accept minus two to say the last two.

I see it should. I thought it did.

No, apparently it wants a positive but non negative integer.

Well, so that's a thing that should be fixed. But then last position and first position. Position becomes simply sort of simplifications of position.

If you said position of -2, would you get the last two elements in their original order or in reverse order?

I would say reversed order.

Yeah, that's what I would say too.

That was my thought too.

But. Okay, so three of us all independently think it should be reversal. I think it should be reverse order. All right, so my proposal is we look at last position, last case, select last. Okay. And we make sure that position works with negative specs for the M argument. Okay, move on.

This is something that's come up a couple of times. We have a UNIX time function. It gives you the UNIX timestamp in GMT by default. By default, it's current implementation. It gives you the timestamp in seconds that are floored. So we have an integer number of seconds. Yeah, there have been times we've wanted to be able to return a real value. And there are also variants of it where instead of giving you a number of seconds, it might give you a number of milliseconds, nanoseconds, microseconds, et cetera.

That sounds useful to me. So my data argument would be a.

Yeah, the date argument can be a reference date. So like Julian date. If you say modified, it gives you the current modified Julian date. But you could give a second argument of a reference date and it will give you that date in modified Julian days.

Julian date has a second argument like that?

Yes, it has an optional first argument that is the type. Because if the value changes, then from Julian date. Also needs to know that this is a modified Julian date or a truncated Julian date and not a.

By the way, I have a minor comment, but we should make sure that our formatting is such that these open bracket closed brackets get slightly separated. Or if necessary, run some post processing pass on documentation to put a small space in that.

Okay, we'll pass that along to Brian.

What the heck happened there? That's like the founding of UR or something.

Isn't that a prominent eclipse?

No, no. The point is that that's a Gregorian date. If you put that in. In the Julian calendar, it looks nicer.

Oh, what is it? Julian Kell. So if I, if I go this.

The year is similar, but I think the date is like first off of.

But even so, what the heck is that year? I mean.

Oh, oh, that. Yeah. Yes. So this was decided by who designed this? It was a combination of various astronomical events that happened on that point.

What were they?

I don't remember. Alignments of various planets or things like that. He thought it was a nice.

That's also some biblical date for the origin of the world. Right. If I remember correctly, it was about that time, maybe.

Yeah, he might have some sort of objective around that.

When was that date decided? When was that?

I think this comes from the 1500s.

Huh. Oh, well, then they would have been thinking about that. Although I think that estimate was done later. Wow. I didn't know there was anything around that time. Wow, how cool. Okay. You can find a tablet from zero of Julian dates. Okay. I mean, that, that. Yeah, there probably isn't a lot of writing from earlier than that time.

Right.

Okay. In any case, be that as it may, so the issue here is an origin date, and I don't see why we shouldn't support the exact same thing here as here.

Yeah. So I think there, the question I don't have a perfect fix on is the difference between the first case, which is I want a Julian or I want a UNIX time in seconds, but I want to include fractional seconds. We can say instant in the. The case that I have here. And the other case is I want a UNIX date or UNIX time that is still an integer, but I want it to be an integer in different units.

Sorry, does that come up for Julian date or is that always.

Not at the moment. Julian date is always a number of days. There's just different origins for it. So this is a.

So the issue here is in milliseconds.

Do you want milliseconds precision or units of milliseconds? And we don't have a unit wrapper to differentiate the two.

Well, maybe. You said millisecond count.

Yeah, I guess there's the analog to byte count, et cetera, where we're expecting an integer to come back. So millisecond count, nanosecond count, etc.

Right. And second count is.

But do we need that, Nick? So, I mean, we could keep second as what we have right now. Millisecond return an integer in milliseconds, which is very much used in computer science. And instant as real. And if people want to do something else, they can change things and do something else.

Yeah, I suppose that's true. I was just wondering about the difference in ambiguity, especially moving forward when we have millisecond granularities, that one's a granularity and one's a precision.

But sorry, for millisecond granularity, meaning for the duration of this millisecond? Basically, yes.

If you are in prototype build, you can say, you know, current date of millisecond and it will give you A date that is instead of an instant down to arbitrary precision.

By the way. That's nice. Okay, so hold on, let me just understand this for you next time. I mean, I think UNIX time is not the same thing. I don't think it has a granularity. I think UNIX time is a. You know, I don't. Julian time doesn't have granularity, does it?

The tradition with julian time is always to use reals and in days. So I think that the problem with UNIX times is that sometimes you want an integer of seconds, sometimes you want an integer of milliseconds, even of microseconds, depending on the computer what is reporting.

No, I understand that point. I'm just saying that.

I think it is clear, except that someone who looks at a input that says UNIX time millisecond may think, oh, this is a real value, precise down to milliseconds rather than a count of milliseconds. If you look at the result and we document it, you can figure it out. But just.

I think it would be best to call it millisecond count then, because I think it is obscure that you just have an integer number there. It doesn't look like a time at all.

I see, okay.

But on the other hand, if you say millisecond, what the heck are you going to get? Other than seconds with a decimal? Which also isn't very helpful because the seconds are not very helpful. They're also just an arbitrary count from a certain time.

But actually millisecond count sounds better as a type. I was worried that putting first degree in reality is not that nice. But if we call it millisecond count, it looks more like a type and then it follows better julian date.

Okay, well, so the default will be second count.

Second count, exactly.

What's the difference?

What about instance?

No, what's the difference in instant time? UNIX time? An instant time of any other time except for the base state. In other words, we could perfectly well have a thing that is a. A time origin for date object, could we not?

Yeah, in Prince. I mean, you can convert. You can do calendar convert of now comma, UNIX time and you'll get a data object which has an instant granular UNIX time that's just a single floating point value.

Well, I think not. For data object, for absolute time, we could have an. An origin for absolute time.

What is it called?

Calendar convert.

That's obscure.

It is a little obscure.

It's not crazy. I mean, it makes sense, but it's just. Okay, so what are you Suggesting. Jose, you were just saying something.

Yes, I was saying that I don't think origins in date object are useful, but in absolute times they could be useful.

Yeah, definitely. Could be.

Like it's a difference of absolute times, and then UNIX time becomes a particular case of that.

I agree. I mean, absolute time as it is right now is kind of obscure.

Yeah. And it is often confusing because it's not really absolute because it's giving a. A count in your time zone rather than gmt. Whereas UNIX time, by the way, that.

Specification there, date specification that it shouldn't be called date there because that. What we're calling date in other cases is some kind of origin date, isn't it?

No, it's a reference date. It's. It's the date you want to turn into.

I understand it. This is not a reference date here, is it?

No, this is acting as a converter.

Yeah.

So it's. You're converting that date.

I get it. Okay, then it's correct. Yes. Okay, but then what we should have, which we don't have right now, is a second argument to this where you say the date you want now. So you could say absolute time of now, comma, and then some particular date, and that would give you the number of seconds.

Right.

So in a sense that we are using a reference that is the beginning of 1900, and that could be the second argument by default is beginning of 1900.

Is it the beginning of 1900? Whereas Unix time uses 1970.

Exactly.

Yep. I had no idea that Julian time used 4700 BC. I. It's actually a piece of trivia knowledge that I should have and don't. Now you do. Okay, what's that? Now I do. I just have to make sure it's committed to memory. Okay, so that's what I would propose a second argument to absolute time as well. And then. Okay, so has that got everything that we needed here?

Yeah, I think so.

Okay. All right, last up, I need to go in a second here. But this is true regular expression.

Yeah, this is a utility that I find periodically useful. You know, we have our string patterns in our string functions under the hood. They ultimately compile down to regular expressions.

Why aren't we just calling? I mean, when you say to regular expression, maybe the answer should be, you know, a regular expression. In other words, will you say to regular expression this thing here? Right. Yeah, I kind of would agree with this. But why not have the regular expression wrapper around?

Yeah, it should definitely have the regular expression wrapper.

What about compile string expression.

I don't like it because I think that suggests the compiler and it's got a whole can of worms around it.

Yeah.

I mean, the other thought I had was export string to regular expression, but that also feels like a little bit of an abuse.

I think it's a hack and it's unnecessary. I don't see why we shouldn't have a thing called two regular expression. I mean, I'm not sure how it's one of these things that's cognitively not high load. It's clear what it means.

Yep.

Now another question from the regular expression that returns a string pattern. Do we have that functionality somewhere?

I'm not sure if it's comprehensive. You know, there. There are instances of regular expressions which may not have a string pattern.

Yeah.

A canonical string pattern form at least.

Well, I think two regular expressions seems useful to me.

Okay.

In terms of an export string play, I don't think there's a file type that is regular expressions, is there?

No, there isn't. No, it's a.

There could be, but I don't think there is.

Yeah, I don't think there's a standard one at least, or a commonly used one.

Right. Okay. Anything else to cover here?

No, I think that gets us set for today.

Very nice. Thank you for having a well, well timed agenda. Good stuff. All right, see you all soon.

Thanks.

Bye for now.

By.