Dead ALEX after requesting departure_time without necessary info

[michlikv]

Dialogue:
s: hello()
u: request(departure_time)
s: ...
u: inform(alternative=2)
s: Dead, there is no connection info.

After we request departure_time or departure_time_rel, it probably somehow creates 'route_alternative' slot in DState "slots" -- with value = none, even though the user did not provide enough info to find connection.
Then when I ask for any alternative, it crashes.

Using: hdc_policy with google info.
(hopefully this is the right place to put this :))

[tuetschek]

Yes, this is the right place, thanks. I'll look at it.

[tuetschek]

OK, this is actually a result of a deeper inconsistency...

@jurcicek: Why is dialogue_state['route_alternative'] initially a D3DiscreteValue like the other slots, even though this is not used as a regular slot? You added it to the list of slots in ontology.py in 90ac9d0 .

The variable is initialy an empty D3DiscreteValue, but it is changed to an int when directions are found. This is very counter-intuitive. I think that initially it should be None, or – perhaps better – not present in the dialogue state variable at all, same as conn_info (i.e., a special member variable of the dialogue state, not in its slot dictionary).

[tuetschek]

Actually, now it seems to me that we should separate conn_info and route_alternative from the dialogue state completely and keep them as member variables of PTICSHDCPolicy...

Or we should introduce a way to initialize them in DeterministicDiscriminativeDialogueState at the start of the dialogue – otherwise they are not there at the beginning and we have to test for them using hasattr, which is rather ugly.

[jurcicek]

DeterministicDiscriminativeDialogueState automatically create all accessed
slots as D3DiscreteValue initially. You can change them as you wish later.

The automatic creation was chosen because I did not want to use hasattr.

Best regards,
Filip Jurcicek

---

Work tel. (CZ): +420221914402
Personal tel. (CZ): +420777805048
Skype: bozskyfilip

http://ufal.mff.cuni.cz/filip-jurcicek

On 27 May 2015 at 11:36, Ondrej Dusek [email protected] wrote:

OK, this is actually a result of a deeper inconsistency...

@jurcicek https://github.com/jurcicek: Why is
dialogue_state['route_alternative'] initially a D3DiscreteValue like the
other slots, even though this is not used as a regular slot? You added it
to the list of slots in ontology.py in 90ac9d0
90ac9d0
.

The variable is initialy an empty D3DiscreteValue, but it is changed to
an int when directions are found. This is very counter-intuitive. I think
that initially it should be None, or – perhaps better – not present in
the dialogue state variable at all, same as conn_info (i.e., a special
member variable of the dialogue state, not in its slot dictionary).

—
Reply to this email directly or view it on GitHub
#165 (comment).

[jurcicek]

On 27 May 2015 at 11:41, Ondrej Dusek [email protected] wrote:

Actually, now it seems to me that we should separate conn_info and
route_alternative from the dialogue state completely and keep them as
member variables of PTICSHDCPolicy...

Conceptually, I want to keep them as a part of the state. The dialogue
state is the place where all information should be stored. The policy
selects actionsbased on the information stored in the state.

Or we should introduce a way to initialize them in
DeterministicDiscriminativeDialogueState at the start of the dialogue –
otherwise they are not there at the beginning and we have to test for them
using hasattr, which is rather ugly.

You mean all variables or only the conn_info and route_alternative
variables?

—
Reply to this email directly or view it on GitHub
#165 (comment).

[tuetschek]

I mean only conn_info and route_alternative – these relate to the current dialogue state, but are not used as slots (you don't need probabilities there). Are there any others that work this way?

Yes, I know that I can change them to whatever I want later, but calling isinstance on them (which is what we do now) seems to me almost as ugly as hasattr. Using them as a D3DiscreteValue would not make much sense either since they're not real probabilities.

I think that we can give a list of these variables in the ontology – they will then be initialized by the DeterministicDiscriminativeDialogueState constructor (to None, not D3DiscreteValue) and we won't need hasattr.