|
coffeetable posted:when i quote this elsewhere, should i cite it as [Cookie 2013] or what lol if you cite anything from the forums, steal that poo poo like ur a gta protagonist son
|
#
?
Nov 25, 2013 03:40
|
|
|
|
| # ? May 17, 2024 18:56 |
|
|
coffeetable posted:when i quote this elsewhere, should i cite it as [Cookie 2013] or what nah I'm just stealin that joke anyway
|
|
#
?
Nov 25, 2013 05:25
|
|
|
suffix posted:same, except a file compressor that tries every possible program and picks the shortest one that matches the file isn't that kolmogorov complexity
|
|
#
?
Nov 25, 2013 05:29
|
|
|
Max Facetime posted:having just 4 verbs and all the nouns in the world makes for a terrible api. it's actually worse than not having the api in the first place, because not only do I still need to figure out how to do my one special thing, in addition I also need to figure out those verbs before getting to that help, bad apis are hard because i only have to understand four things and that's hard so we should have special snowflake apis for every loving minor change and thus avoid useful common ground
|
|
#
?
Nov 25, 2013 07:34
|
|
|
Max Facetime posted:it was really a reference to how in HTTP you can do everything with just GET, to the extent that the imperative word "get" becomes a formality or a matter of convention, or politeness like with the word "please" Like how with Haskell you can do everything by passing around function pointers to do lambda calculus with church encoding? If REST is about anything it's about not simply jamming your API into the transport layer in any old way and actually displaying a bit of taste in your design.
|
|
#
?
Nov 25, 2013 12:06
|
|
|
unless a function pointer can capture context and environment (or that a closure has no required environment), a function pointer =/= a closure  
|
|
#
?
Nov 25, 2013 13:51
|
|
|
function pointers that capture context are known as "munction pointers" :tmyk:
|
|
#
?
Nov 25, 2013 15:17
|
|
|
tef posted:help, bad apis are hard because i only have to understand four things and that's hard so we should have special snowflake apis for every loving minor change and thus avoid useful common ground the apis you're writing on top of those 4 things are the real problem and will always be special snowflake that changes all the time. the transport and serialization are trivial and have been solved about 100 times
|
|
#
?
Nov 25, 2013 15:19
|
|
|
Mr Dog posted:please post more windows things hackbunny don't know what else to post, also everything I say may be inaccurate because it's been years since I've worked for ReactOS or on Windows code at all on SSPI, I guess the only really interesting thing that's left to be said is how it's an example of Microsoft's boner for having identical API/ABI between user and kernel mode. usually it's limited to low level stuff, but it's cool/unsettling to see it in realtively high level APIs like SSPI. a similarly high level API that's almost 100% shared between user and kernel mode is the GDI driver API: in kernel mode, it's used for font drivers and optimized display drivers (display drivers are traditionally split into a hardware driver and a high level graphics driver that uses proprietary escapes to optimize some high level operations; Windows Vista added a further split but I'm unfamiliar with it); in user mode, it's used for printer drivers, and yeah, drawing to a printer driver is yet another case of kernel->user callback generally though, the API compatibility is limited to two function groups: Nt/Zw and Rtl (the <subsystem abbreviation>FunctionName naming convention comes pretty much straight from OS/2, while the system runtime library being called "RTL" is a VMS thing - where the naming convention was an insane SUBSYSTEM$FUNCTION_NAME thing - and there you have Windows NT's heritage in a nutshell) NtXxx functions are what are usually called "system calls" in other OSs (in Windows the term is "system services"): in user mode they are syscall stubs of the "put function number in register & trap" kind, in kernel mode they are direct calls into the kernel's executable (ntoskrnl.exe). there is no automatic capture of syscall arguments: each Nt call decides whether to capture/memlock the arguments based on the "previous mode" flag set by the trap handler. if the call came from user mode, the previous mode is set to user, and the system calls capture. this is a terrible design with a glaring flaw: what if you want to call a system call within a system call, passing arguments allocated in kernel memory? ordinarily you cannot: the previous mode stays set to user, so any nested system calls will keep believing the arguments come from user mode, rejecting arguments that were put e.g. on the kernel mode stack enter the ZwXxx functions: in user mode, they are the same identical thing as NtXxx functions, while in kernel mode they are no longer direct calls, but syscall stubs. so when in kernel mode you need to call a syscall, you call the Zw variant, which goes through the trap handler a second time, which sets a previous mode of "kernel", which disables any probing/capturing/locking of arguments passed by pointer... and any access control checks. so there is no way to act on behalf of the user mode caller when you need to: ZwXxx calls always grant you full access to anything and everything always. well-designed subsystems provide lower-level equivalents to system calls that let you specify whether security checks should be performed, but even then you'll have to do all the probing/capturing/locking by yourself a lot of the time, unless you are a vanilla boring I/O driver with polite functions that fit into a few narrow categories. kernel mode development in Windows is a miserable slog of boilerplate code, unless again you fit into a narrow polite I/O driver category for which you can use the johnny-come-lately standard driver framework, or you drop insane cash for the third party frameworks, and I do mean insane. Windows (NT) is not a platform for kernel hacking and it never has been (unlike say the extremely tinker-friendly nature of message-passing Win32 or component-based COM/OLE) Nt/Zw functions are not entirely garbage though. the API itself is very consistent and well designed, with notable exceptions (no real equivalent of select/poll the biggest for me). it's very biased towards verb/noun semantics (to the point that almost all functions names are in the NtVerbNoun form) and it sucks a little where it can't fit an operation into verb/noun the RtlXxx functions are cakewalk on easy street in comparison. almost the full set is available to both user and kernel mode, and it's almost the same identical binary code. major notable difference: memory allocation. it's a pretty terrible API though, very inconsistent and organically grown, and not always does useful things. it's a kitchen sink of all kinds of functionality, from data structures to string handling to memory allocation to utility functions for handling some of the toughest system data types (the security descriptor stuff. my god). to the best of my knowledge, Microsoft does not have secret internal libraries that make it all better: all evidence suggests that they actually use the full naked horror of them and maybe even enjoy it, the sickos. I'm sure they looked downright sci-fi compared to the poo poo you'd find in SysV at the time, but objectively it wasn't that good. it's also a lot of typing the single biggest upside of kernel/user API/ABI unification is that you can prototype your kernel mode code in user mode with relative ease. take my BS thesis for example: I implemented a mandatory access control policy for Windows, something of a world first if you can excuse the smug. since the Windows kernel doesn't expose the right hooks, and my school didn't have a source code agreement with Microsoft, I implemented it as a modification to ReactOS. since debugging on ReactOS was a dreadful affair, the whole thing was tested in user mode on Windows XP, with some glue code to simulate the kernel hooks. since building on ReactOS was a chore as well (buggy SDK, stupid compiler, obtuse build system), I just copied over a DLL compiled in Visual Studio that contained the implementation of the policy, and modified the ReactOS kernel to link to it. yeah, you aren't supposed to run code compiled in vanilla Visual Studio in kernel mode, but there is no magic to it and you can do it if you know what you're doing. thing was stable enough that on dissertation day I demoed it live (don't do it at home kids) without a hitch. actually, it took a little sleigh of hand to demo, because while working on it I discovered that the Windows architecture is, in fact, unsuited for mandatory access control, but to the best of my knowledge I was the first to document exactly why - usually, it's just presented as a matter of fact. but that's another story for another day hackbunny fucked around with this message at 17:40 on Nov 25, 2013 |
|
#
?
Nov 25, 2013 17:38
|
|
|
i seem to recall that the power management ioctls within nt are a bit of a nightmare to deal with. reading the DDK documentation is like hacking through a rainforest with a machete, but the impression i get is it's rather rtos-ish passing "IRPs" around and doing everything in a non-blocking way, which is quite nice. except that kernel threads are, of course, pre-emptible anyway. i'm guessing they had to retrofit that once they hoisted the gui into the kernel and started calling back into user-space. linux, by contrast, has clear roots in its student hobby project beginnings and blocking i/o in kernel mode is the rule and not the exception. irps don't exist, they're implied by the call stack. even now all the async i/o stuff is kind of grafted on (you still can't do async socket i/o afaik, just async file i/o, which has limited utility. doesn't help that the posix standard that linux sort-of-but-not-really follows uses signals as message queues. doing zero-copy i/o is possible but torturous). also ugh i'm getting hella mccullough effect from this stupid loving stylesheet thanks for taking the time to type that all up 
|
|
#
?
Nov 25, 2013 18:28
|
|
|
then what happens when you set o_nonblock on a socket?
|
|
#
?
Nov 25, 2013 18:37
|
|
|
tef posted:help, bad apis are hard because i only have to understand four things and that's hard so we should have special snowflake apis for every loving minor change and thus avoid useful common ground I know you're trying to troll but please consider: how would you do HTTP ROLLBACK by combining HTTP GET/PUT/POST/DELETE into a correct sequence? is it impossible? are you sure? maybe there's some combination of additional headers that would do the job? maybe all that's needed to make a transaction is something like... start transaction: code:code:code:code:whereas without the simple HTTP GET/PUT/POST/DELETE API existing point B) is where you get to start from!
|
|
#
?
Nov 25, 2013 18:47
|
|
|
just open up port 3306 on the firewall and make sure your tables are innodb, bam transactions
|
|
#
?
Nov 25, 2013 19:09
|
|
|
Nomnom Cookie posted:then what happens when you set o_nonblock on a socket? Nonblocking IO just makes IO operations return immediately if said IO operation cannot be initiated right away, i.e. the kernel buffer for that IO channel is empty/full. If the IO buffer is not empty/full then the kernel will memcpy the data in/out immediately and then proceed on its way. Asynchronous IO kicks off the IO and doesn't wait for it to finish. They basically mean the same thing for streams (i.e. network sockets), but if you're dealing with a large file on disk then you can kick off multiple simultaneous overlapping transfers using async IO (the user-mode data structure for this on Windows is even called OVERLAPPED). So, asynchronous IO is strictly more powerful than nonblocking IO, provided that you have a unified mechanism to gather completion/availability on those channels. POSIX began life with just blocking IO and then bodged non-blocking IO on afterwards, but then never agreed on a "gather" mechanism. Well, there's select(), which is a schoolboy solution to the problem, and BSD added poll() which isn't really much better (but at least doesn't use enormous fixed-length bitfields). BSD then developed kqueues and Linux went through several iterations to develop the epoll_* family of syscalls. NT on the other hand is exclusively nonblocking at the core, the usermode APIs can just block on your behalf to save you the trouble for unimportant poo poo. It had "completion ports" since day one, which are, as the name implies, kernel-mode queues of asynchronous IO completions that you can block on. Also, in NT everything is a HANDLE: threads (they get signalled on completion), files, sockets (well, formally they aren't, but every non-toy network application depends on them actually being HANDLEs), completion ports, event objects. You have a single, scalable event gathering mechanism that works with everything, and all IO APIs are designed for async IO first and a NULL lpOverlapped blocking case available as a convenience to the programmer. This is literally the one thing about NT's architecture that is better than Linux/BSD/whatever.
|
|
#
?
Nov 25, 2013 19:09
|
|
|
Shaggar was right
|
|
#
?
Nov 25, 2013 19:12
|
|
|
win 7 has a magic file enumeration api that's asynchronous behind the scenes so you can iterate over it as if it was any other IEnumerable and it doesn't block while enumerating the directory like before. its so nice
|
|
#
?
Nov 25, 2013 19:13
|
|
|
Windows has one way to enumerate the contents of a directory and it is a loving horrid abstraction inversion: you have to iterate through the results of a wildcard match against a path, and it doesn't even work correctly (from MSDN: searching for C:\RandomShit\*.ISO will match C:\RandomShit\blah.ISO-8859-1)
|
|
#
?
Nov 25, 2013 19:22
|
|
|
works on my pc
|
|
#
?
Nov 25, 2013 19:31
|
|
|
Mr Dog posted:Nonblocking IO just makes IO operations return immediately if said IO operation cannot be initiated right away, i.e. the kernel buffer for that IO channel is empty/full. If the IO buffer is not empty/full then the kernel will memcpy the data in/out immediately and then proceed on its way. i meant o_async, i get those 2 mixed up. linux man pages say you can set o_async on a socket and get sigio just fine
|
|
#
?
Nov 25, 2013 19:32
|
|
|
Mr Dog posted:i seem to recall that the power management ioctls within nt are a bit of a nightmare to deal with. seems so, they even used to have their own dedicated request chaining routine (PoCallDriver vs IoCallDriver), but I don't know anything else about it, never had the pleasure to write hardware drivers Mr Dog posted:reading the DDK documentation is like hacking through a rainforest with a machete try the IFS DDK. it's literally undocumented. there's an API reference but no documentation on how to structure an actual filesystem driver/filter. officially, you had to take vfat (if you were writing a disk filesystem), iso9660 (if you were writing an optical media filesystem) or mrxsmb (network filesystem), fork and customize. you mean you want to write a real actual first class disk filesystem like ntfs? have a lawyer ready because these patented storage APIs ain't cheap they actually started including third-party documentation from OSR in later editions - still nowhere near good enough because OSR has consultants to feed Mr Dog posted:but the impression i get is it's rather rtos-ish passing "IRPs" around and doing everything in a non-blocking way, which is quite nice. except that kernel threads are, of course, pre-emptible anyway. i'm guessing they had to retrofit that once they hoisted the gui into the kernel and started calling back into user-space. it's a VMS thing actually. the Cutler-designed operating systems (RSX/11, VMS, Windows NT) are very similar to each other. like how NTFS is basically a modernized FILES/11, or the Windows scheduler was identical to VMS's. or the whole deal with NT's object namespace, a very VMS solution to the problem of mapping DOS device names win32k calling back into user mode didn't factor into the design, it didn't even exist until NT 4. besides, it isn't an issue: waiting on I/O completion doesn't pump messages, it just stops the current thread at the scheduler level. the only kind of events that can interrupt the wait are DPCs and kernel APCs, asynchronous signals that execute entirely in kernel mode, and at an IRQL higher than PASSIVE, where callbacks to user mode are disabled Mr Dog posted:linux, by contrast, has clear roots in its student hobby project beginnings and blocking i/o in kernel mode is the rule and not the exception. irps don't exist, they're implied by the call stack. even now all the async i/o stuff is kind of grafted on (you still can't do async socket i/o afaik, just async file i/o, which has limited utility. doesn't help that the posix standard that linux sort-of-but-not-really follows uses signals as message queues hey now, enqueued real-time signals are a very different beast from classic UNIX signals. besides, there's no excuse for limiting yourself to the standard completion notification mechanisms - QNX for example extended AIO to integrate with its proprietary event notification system
|
|
#
?
Nov 25, 2013 22:24
|
|
|
Mr Dog posted:Windows has one way to enumerate the contents of a directory and it is a loving horrid abstraction inversion: you have to iterate through the results of a wildcard match against a path, and it doesn't even work correctly (from MSDN: searching for C:\RandomShit\*.ISO will match C:\RandomShit\blah.ISO-8859-1) FsRtlIsNameInExpression see DOS_DOT, DOS_QM and DOS_STAR? whenever you use ".", "?" and "*" in a wildcard at Win32 level, they are actually replaced with those characters before being passed to the driver (which passes them to FsRtlIsNameInExpression). basically the shittiest regexp language ever. even not counting DOS 8.3 alternate names
|
|
#
?
Nov 25, 2013 22:32
|
|
|
the answer to anything related to sockets in Windows is "it's irrelevant". sockets are just files in a special sockets filesystem, which is free to implement as many bizarre semantics, extensions and IOCTLs as it wishes, especially since all interactions are mediated through an abstraction layer. Windows has no built-in support for sockets (or pipes) in the kernel, it's an uplifted plug-in which is also a way to deflect questions about Winsock/AFD which sadly I don't know a lot about
|
|
#
?
Nov 25, 2013 22:38
|
|
|
Whoa, I was already basically writing this thread off, but then there was a bunch of good discussion on versioning and isolation of things that started off with Notorious b.s.d. saying something I strongly agreed with (color me shocked!):Notorious b.s.d. posted:having a standard format on day one is brilliant abraham linksys posted:yeah that's pretty up there too Notorious b.s.d. posted:this would be very not-awesome. it perpetuates the problem. artifact versions are not necessarily code versions. conflating the two gets us gems and cpan and pip and all the other vile things scripting languages have used to distribute code Alas, my high spirits were soon brought back to this mortal plane with comments like: Notorious b.s.d. posted:if you use windows you have much bigger problems than artifact versioning or release management Notorious b.s.d. posted:you would be surprised how many of those problems disappear when you get the gently caress out of a windows shop Still, somewhat more seriously (and more serious than I probably ought to be in YOSPOS), I mostly agree with what Notorious b.s.d. said about versioning and isolation of stuff in production, and that Go "feature" bugs me enough for me to basically never use it. But I only ever play/tinker with Go right now, so who cares. In other news: Gazpacho posted:i know that, as I understand the history the public-facing web teams got to banish the old (obidos) code and rethink everything years ago, supply chain has never had that chance afaict hackbunny posted:don't know what else to post, also everything I say may be inaccurate because it's been years since I've worked for ReactOS or on Windows code at all Also: do I know you?
|
|
#
?
Nov 26, 2013 05:07
|
|
...
|
minidracula posted:holy poo poo kill yourself
|
|
#
?
Nov 26, 2013 05:29
|
|
|
minidracula posted:Whoa, I was already basically writing this thread off, but then there was a bunch of good discussion on versioning and isolation of things that started off with Notorious b.s.d. saying something I strongly agreed with (color me shocked!): nice content-free meta post about your vote on the thread. i am so glad we could get a ten paragraph explanation of your choice to click "1" 
|
|
#
?
Nov 26, 2013 06:02
|
|
|
skipping hundreds of posts to say that c++11 is a Good Language
|
|
#
?
Nov 26, 2013 06:03
|
|
|
hackbunny posted:don't know what else to post, also everything I say may be inaccurate because it's been years since I've worked for ReactOS or on Windows code at all hack bunny, you are scaring me. please don't stop I about died reading that uniform kernel/users pace interfaces were a design goal and yet they even hosed up that crazy line in the sand
|
|
#
?
Nov 26, 2013 06:06
|
|
|
Notorious b.s.d. posted:nice content-free meta post about your vote on the thread. i am so glad we could get a ten paragraph explanation of your choice to click "1" so notorious b.s.d i am not saying this to be funny or yospos-y as a joke. you are the worst poster in this thread. you have some really terrible opinions.
|
|
#
?
Nov 26, 2013 06:36
|
|
|
minidracula posted:More than once, too! obidos begat gp (Gurupa), and I think there's at least one other newer rev behind retail after that too, if not more (or they've just decided to hide gp behind more layers). i think it was two months after i got there that i asked one of the colleagues where i could find documentation or a tutorial for the console UI library that the whole division was using. he said he didn't know, which is fine if he didn't, but besides that he didn't seem to understand why i might be looking for it, and i promptly had a fit Gazpacho fucked around with this message at 07:02 on Nov 26, 2013 |
|
#
?
Nov 26, 2013 06:45
|
|
|
FamDav posted:kill yourself Notorious b.s.d. posted:nice content-free meta post about your vote on the thread. i am so glad we could get a ten paragraph explanation of your choice to click "1" But, speaking of content: TIL about "hypercomputing", which apparently is actually a thing. Or, at least a term. Definitions of what it is -- if it is even anything in the first place -- seem to differ. This being the PL YOSPOS thread, I wondered what programming languages might be like on such a computer, if it could exist. I guess I was prompted to go down this line of thought after reading a bit (and some fiddling with) some PLs that try to tackle quantum computer programming (e.g. Quipper site, paper (PDF), .tgz) and some quantum circuit simulators (e.g. QuIDDPro site). But, qubit-model quantum computers don't satisfy the available definitions of a hypercomputer, since they can be modeled in classic Turing machines (albeit in PSPACE complexity). minidracula fucked around with this message at 06:53 on Nov 26, 2013 |
|
#
?
Nov 26, 2013 06:50
|
|
|
hackbunny posted:hey now, enqueued real-time signals are a very different beast from classic UNIX signals. besides, there's no excuse for limiting yourself to the standard completion notification mechanisms - QNX for example extended AIO to integrate with its proprietary event notification system as did Solaris, although it is (or was?) unusably broken
|
|
#
?
Nov 26, 2013 06:52
|
|
|
dude minidracula we're cool with gays in yospos ( holla at ya boi ) but you need to stop fagging it up.Gazpacho posted:gurupa had filtered down to us, the switchover deadline for internal sites was in 2009 but most supply chain software is console apps talking to services, both layered over an unbelievable number of unowned and undocumented platform libraries this just gets more and more depressing.
|
|
#
?
Nov 26, 2013 07:00
|
|
|
Gazpacho posted:gurupa had filtered down to us, the switchover deadline for internal sites was in 2009 but most supply chain software is console apps talking to services, both layered over an unbelievable number of unowned and undocumented platform libraries
|
|
#
?
Nov 26, 2013 07:02
|
|
|
FamDav posted:this just gets more and more depressing.
|
|
#
?
Nov 26, 2013 07:15
|
|
|
correction: "mostly console apps + services" doesn't describe all of supply chain, just the parts that run in the warehouses let's see, i don't think i've told the story about the warehouse manager who opened a ticket because he was running out of preprinted barcodes to put on the boxes and could we order some more? this ticket went straight to the devs and became the problem of the dev on duty at the time (me), because that's how he'd gotten the labels in the past. thing was, whoever had known how to respond before seemed to have moved on and nobody knew how to get them, nor why this warehouse out of all the others worldwide had gotten in the habit of requesting labels from the software developers. the ticket ended up being closed in a ticket bankruptcy shortly before the shopping season and i wasn't around to see what happened afterward
|
|
#
?
Nov 26, 2013 07:19
|
|
|
minidracula posted:Yeah, but, you know, $61 billion in 2012 revenue, so some people aren't that depressed. Sure, it's gross, but is there a company at that scale that isn't? Isn't that why we all hate programming? i just find it sad because there are legitimately enjoyable parts and it seems to have given you a lot of misery.
|
|
#
?
Nov 26, 2013 07:23
|
|
|
minidracula posted:TIL about "hypercomputing", which apparently is actually a thing. Or, at least a term. Definitions of what it is -- if it is even anything in the first place -- seem to differ. This being the PL YOSPOS thread, I wondered what programming languages might be like on such a computer, if it could exist. hypercomputation is a very vague term that CS guys use when they want to mess with the philosophy end of the discipline. it can mean any one of a dozen things, so if you're interested in it pick one author and run with their + their associate's writings rather than googlin' around. my favourite of the bunch is aaronson's stuff on computation near closed timelike curves, but that's just me quote:I guess I was prompted to go down this line of thought after reading a bit (and some fiddling with) some PLs that try to tackle quantum computer programming (e.g. Quipper site, paper (PDF), .tgz) and some quantum circuit simulators (e.g. QuIDDPro site). But, qubit-model quantum computers don't satisfy the available definitions of a hypercomputer, since they can be modeled in classic Turing machines (albeit in PSPACE complexity). quantum computers are not hypercomputers in any sense i've seen. like you said they can at most solve problems in PSPACE, and the inclination in the field at the moment is that they're almost certainly in NP too. in fact, while no-one's expecting it i don't think anyone would be ~too~ surprised if it turned out that BQP = BPP and they're only as powerful as probabilistic computers. if you're interested in the "practice" of this stuff, the best intro i've seen is kaye's An Introduction to Quantum Computing. if you wanna know more about the complexity theory side, then chap 10 of arora & barak's A Modern Approachmight need to read some of the other chapters first suffice it to say that we're a long, long way from a general programming language for qcomps. mostly because it'll be a long time before we need one - as far as we can tell there are only a handful of problems that they make noticeably easier, so if qcomps ever make it out of research it'll be as lil' black boxes with coffeetable fucked around with this message at 09:35 on Nov 26, 2013 |
|
#
?
Nov 26, 2013 09:32
|
|
|
coffeetable posted:hypercomputation is a very vague term that CS guys use when they want to mess with the philosophy end of the discipline. it can mean any one of a dozen things, so if you're interested in it pick one author and run with their + their associate's writings rather than googlin' around. my favourite of the bunch is aaronson's stuff on computation near closed timelike curves, but that's just me Can't say I'm too surprised to find out some serious people in computability think it's bunk though. Right now I've skimmed over a couple of Davis's papers arguing against hypercomputation being anything real (other than, at best, a flashier name for un-computability; Davis also discards that there are any possible results in "hypercomputation" in the sense the peddlers of the term assert there are), and one of Andrew Hodges's articles rebutting an original hypercomputation paper. Like you said, I think I need to pick a thread and see how deep the rabbit/k-hole goes. coffeetable posted:quantum computers are not hypercomputers in any sense i've seen. like you said they can at most solve problems in PSPACE, and the inclination in the field at the moment is that they're almost certainly in NP too. in fact, while no-one's expecting it i don't think anyone would be ~too~ surprised if it turned out that BQP = BPP and they're only as powerful as probabilistic computers. Regarding PLs for quantum computers, yeah, I agree. So far all the actual language work isn't focused on what a language might look like to "program" a quantum computer, but rather how to model quantum computations in the qubit model (but to be simulated on traditional computers). There doesn't seem to be a whole lot separating things like Quipper from more quantum circuit simulator things like jQuantum other than approach and notation. Again, that seems fine for the reasons you point out. You have any opinions, thoughts, whatever on D-WAVE and their claims?
|
|
#
?
Nov 26, 2013 10:29
|
|
|
my opinion's that their salesmen are far more successful than their engineers, and at most they've got a qannealing implementation (which is a loooong way short of shor's or grover's or anything else fun). im basing that entirely on posts by CS theory bloggers though so ymmv another (tad more ridiculous) point is that as the NSA seem to have done everything but break SSL, and if they don't have a practical qcomp then some rinkydink lil research outfit certainly doesn't.
|
|
#
?
Nov 26, 2013 10:47
|
|
|
|
| # ? May 17, 2024 18:56 |
|
|
coffeetable posted:… a qannealing implementation (… grover's ) … 10 ADD LOAD-BEARING DRYWALL 20 SHAKE HOUSE 30 ADD LOAD-BEARING DRYWALL WHERE IT FAILED 40 GOTO 20
|
|
#
?
Nov 26, 2013 12:08
|
|
