next »

[Crimsontide]

Well thank-you for the insightful responses.  Seems I have a lot more to learn about quantum computing...

[gimymblert]

I still don't understand properly, it's not ready for prime time anyway, but damn we have a definitive step toward it.

[ferreiradaselva]

My 3 2 cents:

1. This is the kind of thing that I will love using with my researches. Might be very useful in computational biology.

2. I don't think it's particularly useful for most programmers. Binary state is widely useful for being simple.

3. I hope when this becomes widely available, it's in the form of a QPU. Like a GPU, but with a Q . And that an open language is made for it, QL, like GLSL, but also with a Q . That way it could be used from any other language.

ps: I still didn't watch the whole video.

[J-Snake]

Here we go, it start to be close



Microsoft Quantum Development Kit: Introduction and step-by-step demo

Who is a human? Someone whose feet are stuck in the dirt, but his head is floating above the sky.

[gimymblert]

Any idea how to implement Rock paper scissor in quantic programming?
I know it's not useful, but since it's new and nobody has any best practice, all simple problem is fascinating again.

[Ordnas]

Any idea how to implement Rock paper scissor in quantic programming?
I know it's not useful, but since it's new and nobody has any best practice, all simple problem is fascinating again.

I found someone that made it:
https://medium.com/@decodoku/introducing-the-worlds-first-game-for-a-quantum-computer-50640e3c22e4

[NoLocality]

"Free Public Quantum Computing!"

!!!!!!

Brb, gotta download something.

[NoLocality]

!!!!!!

Brb, gotta download something.

Nevermind, 500$ is a bit much for Visual Studio 2017 atm.   

[JWki]

!!!!!!

Brb, gotta download something.

Nevermind, 500$ is a bit much for Visual Studio 2017 atm.   

There's VS community.

[Ordnas]

!!!!!!

Brb, gotta download something.

Nevermind, 500$ is a bit much for Visual Studio 2017 atm.   

Visual Studio community is free but has the same features, no worries.

[NoLocality]

Visual Studio community is free but has the same features, no worries.

There's VS community.

Oh nice!  Last time I downloaded VS the 2010 version was the free one, didn't know till now "VS Community" was a thing.

Thanks for steering me towards it you two!   

[InfiniteStateMachine]

Yeah there's currently no difference between VS community and VS pro anymore. Even down to using commercial extensions (VAssistX yay!).

The only condition is that if you make over 1000000$ revenue you have to buy a copy of pro for 500$. Seems like a fair deal to me

[Crimsontide]

I remember a few years ago a MS employee was on some indie game dev forum asking people to sign up for something or another to get a free copy of VS (before community was out).  I told him I (and a few others) weren't interested because we don't trust MS and if they were serious just release a reasonably priced version.  He got angry, but surprisingly a few months later we had VS community come out and I honestly was quite surprised, and a bit impressed, that MS listened to some random indie devs on some game forum that told him off (or at least I like to believe I had a little bit of influence... probably not but one can always dream : )

[JWki]

I remember a few years ago a MS employee was on some indie game dev forum asking people to sign up for something or another to get a free copy of VS (before community was out).  I told him I (and a few others) weren't interested because we don't trust MS and if they were serious just release a reasonably priced version.  He got angry, but surprisingly a few months later we had VS community come out and I honestly was quite surprised, and a bit impressed, that MS listened to some random indie devs on some game forum that told him off (or at least I like to believe I had a little bit of influence... probably not but one can always dream : )

Haha prettyyyyyy sure that might be unrelated

[Crimsontide]

Ok I got theoretical a question for you guys...

Quite often I find that when creating classes (C++ but this can apply in general to other languages) that if they aren't trivial, that there is a sort of implied state.  For example a class could have the conceptual states of being uninitialized, constructed, initialized (if a 2 step initialization is required), valid, invalid/null, deconstructed state, etc...  Invalid/null I come across a lot whenever I implement move operators/constructors for a class, as when moving from a class you should leave it in a valid (i.e. null) state.

The idea with C++ and classes is that you have essentially only 3 states if possible, uninitialized/not yet constructed (more of a pseudo/virtual state as the object doesn't exist yet), valid, destructed.  You could visualize it as something like:

(uninitialized) -- constructor --> (valid) -- destructor --> (destructed/uninitialized again)

And this is handled automatically by the language.  As soon as you add new states though, there's no language support.  I usually find myself adding a ton of assert's at every function accompanied by a fair amount of documentation (after calling X() don't call Y() or Z()).  It works, it just feels... tedious and error prone.  A small change to class functionality often leads to huge amounts of work to keep the asserts/documentation in line.

How do you guys handle this?  Is there another language that handles this better (not saying that I necessarily will use said language, but I'd love to see how they are solving the problem)?

[JWki]

Ok I got theoretical a question for you guys...

Quite often I find that when creating classes (C++ but this can apply in general to other languages) that if they aren't trivial, that there is a sort of implied state.  For example a class could have the conceptual states of being uninitialized, constructed, initialized (if a 2 step initialization is required), valid, invalid/null, deconstructed state, etc...  Invalid/null I come across a lot whenever I implement move operators/constructors for a class, as when moving from a class you should leave it in a valid (i.e. null) state.

The idea with C++ and classes is that you have essentially only 3 states if possible, uninitialized/not yet constructed (more of a pseudo/virtual state as the object doesn't exist yet), valid, destructed.  You could visualize it as something like:

(uninitialized) -- constructor --> (valid) -- destructor --> (destructed/uninitialized again)

And this is handled automatically by the language.  As soon as you add new states though, there's no language support.  I usually find myself adding a ton of assert's at every function accompanied by a fair amount of documentation (after calling X() don't call Y() or Z()).  It works, it just feels... tedious and error prone.  A small change to class functionality often leads to huge amounts of work to keep the asserts/documentation in line.

How do you guys handle this?  Is there another language that handles this better (not saying that I necessarily will use said language, but I'd love to see how they are solving the problem)?

My solution is to not write classes that have lots of states. When it's constructed, it's usable.

[InfiniteStateMachine]

That's what I strive to do but I can certainly say I've felt that pain.

I cringe everytime I write code like this


void Update()
{
if (firstUpdate)
{
firstUpdate = false;
Init();
}

}

[Nikolas]

Ok I got theoretical a question for you guys...

Quite often I find that when creating classes (C++ but this can apply in general to other languages) that if they aren't trivial, that there is a sort of implied state.  For example a class could have the conceptual states of being uninitialized, constructed, initialized (if a 2 step initialization is required), valid, invalid/null, deconstructed state, etc...  Invalid/null I come across a lot whenever I implement move operators/constructors for a class, as when moving from a class you should leave it in a valid (i.e. null) state.

The idea with C++ and classes is that you have essentially only 3 states if possible, uninitialized/not yet constructed (more of a pseudo/virtual state as the object doesn't exist yet), valid, destructed.  You could visualize it as something like:

(uninitialized) -- constructor --> (valid) -- destructor --> (destructed/uninitialized again)

And this is handled automatically by the language.  As soon as you add new states though, there's no language support.  I usually find myself adding a ton of assert's at every function accompanied by a fair amount of documentation (after calling X() don't call Y() or Z()).  It works, it just feels... tedious and error prone.  A small change to class functionality often leads to huge amounts of work to keep the asserts/documentation in line.

How do you guys handle this?  Is there another language that handles this better (not saying that I necessarily will use said language, but I'd love to see how they are solving the problem)?

I think a nice way to handle this, is to model class states with different classes/types.
An example class Player, which may have a constructed and an initialized state, can be split into a PlayerTemplate and a PlayerInitialized class.
With PlayerTemplate just holding the data needed to initialize a PlayerInitialized object.
Methods which require a initialized Player object can take PlayerInitialized as a parameter, or can be member functions of PlayerInitialized.
Initialization logic can be put into an extra class like a PlayerInitializer with a method signature like this:

Code:

PlayerInitialized init(PlayerTemplate template){...}

[qMopey]

Well the language C++ does not provide any state whatsoever. Those must be coded for you. The only thing C++ provides is a constructor and a destructor, which are functions (but we cannot get a pointer to them) that can run arbitrary code. The rest is up to the programmer.

In this way, if a bunch of state arises it really is the fault of the engineer. There are ways to separate problems and break them down into fundamentals. There isn't always a need for state to solve many problems. It just so happens that when engineers create big blob stateful classes they A) aren't really reflecting or introspecting on their engineering habits and B) have no clue how much memory or where in memory their code even uses.

It won't be a popular opinion, but I would recommend never even using constructors or destructors. When state starts arises, especially alloc/free init/destroy etc. I would treat this as a warning that something is likely going wrong.

[Garthy]

As soon as you add new states though, there's no language support.  I usually find myself adding a ton of assert's at every function accompanied by a fair amount of documentation (after calling X() don't call Y() or Z()).  It works, it just feels... tedious and error prone.  A small change to class functionality often leads to huge amounts of work to keep the asserts/documentation in line.

Checking for preconditions is a fairly normal thing. As is automatically calling dependent methods. If you have a number of methods that rely on a similar mechanism, you can abstract them away into a single call, or set of calls. This helps keep things tidy.

For example: Suppose you have an object that has an expensive second-stage initialisation that you only really perform when needed. Five methods require this second-stage initialisation. You put all of the checking into an ensureFoo() call, like this:

Code:

void Bar::ensureFoo()
{
  if (!fooInitialised)
  {
    performTrickySetup1();
    if (!performTrickySetup2())
      performTrickySetup3();
    if (!performTrickySetup4())
      throw FooException("Cannot proceed without Foo set up correctly.");
    fooInitialised = true;
  }
  checkPreconditions();
}

// This call doesn't need Foo.
void Bar::call1()
{
}

// This call needs Foo to be set up.
void Bar::call2()
{
  ensureFoo();
  // Blah blah
}

// This call needs Foo to be set up.
void Bar::call3()
{
  ensureFoo();
  // Blah blah
}

// This call doesn't need Foo.
void Bar::call4()
{
}

// (similar code for the remaining methods)

The ensure* calls can contain a combination of pre-condition checking and calls to initialise the proper state. They can even throw an exception with an appropriate message pointing to the problem if the object cannot create the initial state on its own.

The idea with C++ and classes is that you have essentially only 3 states if possible, uninitialized/not yet constructed (more of a pseudo/virtual state as the object doesn't exist yet), valid, destructed.

I would not suggest viewing it in this way. C++ provides poor state management when relied upon in this manner, as you can't even query the state unless you track it yourself, and pre-construction and post-destruction you would have to track that state externally.

Perhaps think of construction as destruction as follows: (i) A way to ensure that, unless you have gone out of your way to avoid it, any new object has been through a constructor; and conversely (ii) a way to ensure that, unless you have gone out of your way to avoid it, any disposed object will have gone through its destructor.

As soon as you add new states though, there's no language support.

Enums work great for simple state tracking. You can also use objects within objects to track more complex state. There are a lot of tools that you can use to build up the ideal state tracking solution for your problem.