WEBVTT 00:00.000 --> 00:19.280 So yeah, I thought it was going to be very short presentation to actually present the language, 00:19.280 --> 00:27.520 which is called H hat and breaks the rule that Nate said about having Q on everything 00:27.520 --> 00:32.520 in quantum related, yeah, that's the idea. 00:32.520 --> 00:39.480 So I thought, yeah, maybe talking about something that is very different from everything else, 00:39.480 --> 00:46.320 which is the quantum type system that I've been developing on it, and yeah, maybe having 00:46.320 --> 00:49.760 some more discussions later on. 00:49.760 --> 00:57.180 So just a quick summary, just briefly talking about H hat and then quantum systems and Q 00:57.180 --> 00:58.180 on it. 00:58.180 --> 01:12.140 Yeah, H hat for those who are physicists, H hat is kind of a big name or big expression in physics, 01:12.140 --> 01:16.500 and yeah, it seems they write an N2 to give it. 01:16.500 --> 01:23.180 So basically it's a high level abstraction quantum programming language, and that means that 01:23.180 --> 01:32.340 you have the user facing layer on the quantum stack right below the user, and the idea 01:32.340 --> 01:39.220 is basically to be data for your internet, and it means that you don't have to think about 01:39.220 --> 01:48.420 physics, which is strange at first, but today it's to evolve to something else and actually 01:48.420 --> 01:57.060 think more in terms of what we already know about programming, and that's in the end. 01:57.060 --> 02:01.900 The ones that are going to build software will be the software engineers, so it makes sense 02:01.900 --> 02:11.620 to actually make things more structuring the way that we are also to do. 02:11.620 --> 02:19.860 So yeah, first defining quantum data, so everything that has a hat in front of it is quantum, 02:19.860 --> 02:27.100 I think all of that, so you kind of can differentiate between literals and quantum, of 02:27.100 --> 02:32.340 course you have to encode and so on and so forth, but that's the next step that basically 02:32.340 --> 02:39.260 you need to define and compose the data structure, and then the quantum data types, such 02:39.260 --> 02:46.700 as quantum Boolean, quantum integer, so on and so forth, and of course you can have user 02:46.700 --> 02:56.300 defined types with structs or in norms, etc. For instance, you can have some like a source 02:56.300 --> 03:04.500 and target of Boolean, so they are basically part of a single data type, or something more 03:04.500 --> 03:15.860 structuring or more complex, you can do as you wish, and yeah, that's basically it. 03:15.860 --> 03:25.100 So the first step is similarly to what we have on classical computing, you basically need 03:25.100 --> 03:33.620 to define some limits from what you can actually have in terms of quantum resources, so instead 03:33.620 --> 03:41.360 of thinking of registers or bits, we need to think of in terms of qubits, in the language 03:41.360 --> 03:47.400 I call it indexes, because they don't want to make people, they are not used to quantum 03:47.400 --> 03:54.040 to start having to think about quantum, so I try to strip off all these physical concepts 03:54.040 --> 04:04.840 and try to make them more computer science related, so it's simple, if you have a quantum 04:04.840 --> 04:12.600 integer of size 2, so you have two qubits in the end to work with, you have more, you have 04:12.600 --> 04:19.720 more, if you have less, so they do suit computers and try to reach the point where you cannot 04:19.800 --> 04:25.280 go further, because the quantum computer does not have more memory or resources to do the 04:25.280 --> 04:33.280 computation, and then it can be calculated during the type checking basically, if it's 04:33.280 --> 04:42.720 possible, but usually it is, and of course you have to define quantum variables, and they 04:42.720 --> 04:49.160 are kind of different from the usual variables, because they do not execute or do anything 04:49.160 --> 04:54.840 at first, they just are pending instructions, because we need to remember that quantum 04:54.840 --> 05:04.280 computers, they are very slow in the sense of during computation, compilation and computation 05:04.280 --> 05:11.280 going back to the CPU, so we need to get as much resources or as much algorithm in one batch 05:11.280 --> 05:19.120 and execute it at once, so a variable is just accumulating all these instructions, and 05:19.360 --> 05:29.120 for instance you have a variable queue of type quantum Boolean, and it will have a function being applied 05:29.120 --> 05:38.160 to this literal quantum false, this is basically translated as having these instructions 05:38.160 --> 05:47.200 inside of its data, so in the end it will be converted to something useful that we are going 05:47.200 --> 05:58.560 to talk about right now, because once you have this quantum variable or quantum anything, 05:58.560 --> 06:05.760 it's quantum, so you cannot print it, you cannot do anything other than accumulating things 06:05.760 --> 06:12.400 inside this quantum variable, but what you can do is basically, I want to cast this quantum 06:12.480 --> 06:19.280 variable into something that is classical, in that sense, I'm just saying, yeah, I want to cast 06:19.280 --> 06:31.840 this operation into unsignet 32 integer, and from this part on, basically what happens is we are 06:31.840 --> 06:41.120 going to have some steps to be accomplished, the first one is to actually compile those instructions 06:41.200 --> 06:47.600 inside the quantum variable into something that the quantum language can actually understand, 06:48.480 --> 06:54.640 in this case I took an example of Kiske, it's open quantum, so basically that instruction 06:55.600 --> 07:04.240 within a three at YouTube, it's basically this simple instruction in open quantum, 07:04.400 --> 07:12.320 after that, you basically execute this into a emulator, or keep you, and you may have these 07:12.320 --> 07:23.520 sites of resulting data, it can already be strings and probability are counting of values, 07:24.640 --> 07:32.080 and in that we have to work with these results, but remember that we want to have a unsignet 07:32.160 --> 07:43.440 integer of 32 bits, so we need to convert somehow this into this U32, and the way that we do this 07:43.440 --> 07:50.560 is basically we can define right now it's kind of implicit, but we can define like the way that 07:50.560 --> 07:58.880 we actually want to represent this result, so yeah we can have this as a raw result, or we can 07:58.880 --> 08:05.520 have a weighted average, or the highest value, or the lowest value, we can kind of define how we 08:05.520 --> 08:12.800 want to interpret this, and depending which kind of the resolvers protocol we choose, 08:13.520 --> 08:23.680 we have different outcomes, and after that we basically guess this resulting to the actual type 08:23.760 --> 08:30.240 that we want to convert to, so in this case of the raw we cannot convert, because it's a dictionary, 08:30.240 --> 08:38.080 so it's not compatible, but in the other cases we can actually have something that is kind of 08:39.520 --> 08:50.240 convertible, yeah, there are some other points that I would like to discuss, but maybe we can 08:50.320 --> 08:59.200 do on the Q&A session, which is the index manager, basically how you can actually manage the 08:59.200 --> 09:08.880 qubits throughout your program, for instance, how you actually have this quantum functions converted 09:08.880 --> 09:17.840 into quantum instructions, and for instance how you define the quantum instructions order, 09:18.480 --> 09:27.680 it's important when you consider that you may have in case of the last talk, we may have distributed 09:27.680 --> 09:35.600 systems like quantum networks, so you may want to ask some other computer to execute some 09:35.600 --> 09:42.400 command at some specific time, so you actually need to have like this track of which instruction 09:42.400 --> 09:50.480 should be performing the first or later, and yeah, there are many other points, but basically the 09:50.480 --> 10:02.640 idea is there, and yeah, which me out if you want to know more about the project, I deliberately decided 10:02.640 --> 10:12.640 to choose a fast talk, so you open for questions, maybe you have a lot of questions, 10:13.520 --> 10:20.800 if you want to know more about the project, I should push the last changes that we will make 10:20.800 --> 10:27.600 actually this example of feasible in a few days, I was finishing it, but a little buggy, 10:28.160 --> 10:34.160 but yeah, you can check that out there, yeah, let's see 10:34.160 --> 11:03.360 you have the compiler of the language, or I don't have the definition, well 11:04.480 --> 11:12.720 right now let's say that because we have many dependencies on the current stacks, 11:12.720 --> 11:20.240 SDKs and quantum in most of them rely on Python, I decided to start having this interpreter in 11:20.240 --> 11:28.080 Python, also because it's easy for people to see the code and collaborate or discuss, but I also 11:28.080 --> 11:36.640 have another branch that has rust code on it, and there it is basically to have like the documentation 11:36.640 --> 11:44.800 of how the language should behave, and Python and rust being compatible for benchmarking, 11:44.800 --> 11:54.320 and in the future having like a full probability, uh, language, because quantum, yeah, you cannot 11:54.400 --> 12:00.240 like compile basically everything, you have to actually execute most of the things that are 12:01.120 --> 12:22.640 inside this quantum variables in time, yeah, and one of the points that I still want to address 12:22.720 --> 12:31.040 is basically like you don't have to freeze all your classical programming side while the 12:31.040 --> 12:38.400 quantum is working, the same way that GPUs does not freeze like your CPU, so yeah, you can think 12:38.400 --> 12:44.560 of keep you being basically another driver that you can send very specific instructions, and then 12:45.440 --> 12:55.040 somehow or sometimes they will come or not, so they are just waiting for being synced again, 12:57.840 --> 13:04.000 and one just to complete one of the ideas that I had is basically to try to use the 13:05.360 --> 13:13.600 rationale behind airline to the language, because I think the best distributed programming language 13:13.680 --> 13:22.400 out there is a relank, because yeah, you can make things break and they still work nicely, 13:23.120 --> 13:29.920 are gracefully the stop working, but yeah, it's kind of a interesting point. 13:30.800 --> 13:40.240 Another one that I had a lot of time trying to figure out is you can have two quantum variables, 13:40.320 --> 13:47.840 and then you say, yeah, I went to entangle them, but then I do something else with one of them, 13:47.840 --> 13:54.640 and it interacts with other parts of the code, how I can ensure that things are connected, 13:55.680 --> 14:02.400 because remember I am just saying that this quantum variable is a holder for all the instructions, 14:03.040 --> 14:10.480 so now you are in this cascade of dependencies from different variables, and you may not know 14:10.480 --> 14:19.920 like which ones you need to execute first or later, so that's why I think having these quantum 14:19.920 --> 14:26.160 types are very useful because you can basically say, yeah, everything inside this quantum variable 14:26.240 --> 14:32.160 that belongs to this quantum type will be executed just once, like just at that time, 14:33.360 --> 14:39.280 so you can basically protect from like undesired or side effects, again. 14:41.280 --> 14:54.880 Yeah, yeah, yeah, sure. 14:56.160 --> 15:01.520 Yeah, actually it's much more simple, it's far not too overflow, 15:03.520 --> 15:10.960 oh yeah, to talk a more about the index manager in the language, it's very simple, actually, 15:10.960 --> 15:17.200 because like in computers you have the alignment of your type, right, or it's throat, or you know, 15:18.560 --> 15:25.920 but in quantum, since you barely have like resources, you shouldn't like align 15:25.920 --> 15:37.280 everything with one size only, right, so if I'm working with quantum YouTube, yeah, just too 15:37.280 --> 15:45.280 cube, it's very simple, very dumb, but you can do some working examples, and you have another 15:45.280 --> 15:56.480 like type that actually uses, yeah, for instance, this quantum-type will probably is bigger than 15:56.480 --> 16:04.720 just one cube, so I need to account for this one cube, plus this, whatever more cube it's it has, 16:04.720 --> 16:12.000 so it has to recursively look for like how many cubes it needs to allocate in one execution, 16:12.960 --> 16:20.960 so it can decide whether it's a valid execution or not, because let's say your quantum computer 16:20.960 --> 16:30.960 has 20 cubes, and it requires 30, so it should not execute, that's the idea, and this part of 16:31.040 --> 16:40.400 quantum, it's basically how you define this type separated, we can discuss later if you want, 16:40.400 --> 16:50.160 but yeah, it's interesting topic, yes, so I'm going to say directly if you want to 16:50.640 --> 17:07.280 make a cast with a function, let's say then I cannot make two quantum variables and take them with 17:07.280 --> 17:15.920 other objects together, because that would there would be the problem that half of the measurement, 17:15.920 --> 17:33.920 the other stages is for it, and that you, that just over that way, that you have all 17:33.920 --> 17:42.800 circuit in one type, right? Yeah, the question is basically there is this problem with entangling 17:42.800 --> 17:49.840 two quantum variables for instance, and then you measure one and then the other is kind of loose, 17:50.640 --> 17:57.760 and trying to solve that you basically have these like quantum data types, yeah that's true, 17:57.760 --> 18:05.360 and you can think as a functional programming paradigm basically, because now we are like in this whole 18:05.360 --> 18:11.840 box, everything just happens inside, there's no like outside side effects, at least on quantum, 18:12.960 --> 18:19.200 so it's basically contained, I mean it can be remotely, like you can do a teleportation, 18:19.200 --> 18:26.800 but it's still it's contained in this quantum data type, so it solves a lot of problems, 18:26.800 --> 18:32.400 because let's say that in the middle of the computation you need a previous value that you actually 18:32.480 --> 18:41.920 measured, or cast into the next quantum computation, so if they are separated quantum variables, 18:41.920 --> 18:49.680 you kind of have to cast both, but not really just have, so how do you decide that or what you should do? 18:49.680 --> 18:55.760 I think it's quite confusing what this is, but it's very difficult for a software here. 18:55.760 --> 19:02.880 Yeah, and I didn't cover anything like, because I'm kind of destroying physics here, 19:03.520 --> 19:09.520 there's no concept of cubits, there's no measurement, there's no superposition, 19:10.400 --> 19:18.160 angle measurement, everything is kind of to sound like computer science and data being transformed, 19:18.240 --> 19:32.880 basically, like this, yeah, this reading, it's basically a hardware, but I'm basically 19:34.240 --> 19:42.400 like, um, redimensionalizing it to have space for a more things, but that's the way that I 19:42.480 --> 19:48.480 could find, it's not talk about physics, talking about physics under the hood. 19:48.480 --> 20:18.400 Yeah, in this case, I didn't explicitly show anything, but in this case, it's just, 20:18.480 --> 20:27.040 the highest value, but after the cast, you should have like this pointy squares and say, 20:27.040 --> 20:31.440 like the kind of protocol you want to use to actually convert the data. 20:42.320 --> 20:47.840 Yeah, it's a dictionary, right? I mean, it's like adding string with 20:47.840 --> 20:58.640 integer in Python, it doesn't work. Yeah, I mean, if you have a hash map or a dictionary type, 20:58.640 --> 21:10.400 you can actually have your role value. Yeah, thanks.