Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create arc_indexes from arcs, add a duplicate of final state #27

Merged
merged 1 commit into from
May 5, 2020

Conversation

qindazhu
Copy link
Collaborator

@qindazhu qindazhu commented May 5, 2020

  • Add a constructor which creating arc_indexes from arcs.
  • Add a duplicate of final state to arc_indexes to avoid boundary check in many implentations.

Please merge this PR ASAP before other PRs if there's no other issues as:

  • There may be conflicts as I have changed almost all .cc files.
  • Other algorithm implentation should be based on new structure of arc_indexes.

k2/csrc/fsa.h Outdated Show resolved Hide resolved
k2/csrc/fsa.h Outdated Show resolved Hide resolved
k2/csrc/fsa.h Outdated Show resolved Hide resolved
k2/csrc/fsa.h Outdated Show resolved Hide resolved
k2/csrc/fsa.h Outdated Show resolved Hide resolved
@danpovey
Copy link
Collaborator

danpovey commented May 5, 2020 via email

@qindazhu
Copy link
Collaborator Author

qindazhu commented May 5, 2020

Final-state should always have the largest state number, yes.

On Tue, May 5, 2020 at 1:41 PM Fangjun Kuang @.> wrote: @.* commented on this pull request. ------------------------------ In k2/csrc/fsa.h <#27 (comment)>: > std::vector<int32_t> arc_indexes; // Note: an index into the arcs array is called an arc-index. std::vector arcs; - StateId NumStates() const { return static_cast(arc_indexes.size()); } + Fsa() {} + // just for creating testing FSA examples for now. + Fsa(std::vector fsa_arcs, int32_t final_state) { Shouldn't the final state always have the largest state number? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZFLOYSRBMZKHJKDFFN2OLRP6RJXANCNFSM4MZI42BA .

Yes, but @csukuangfj 's question is really another question. We can't get final state from a non-co-accessible FSA. Just image an FSA with arc 1->2 and the final state is 3

@qindazhu
Copy link
Collaborator Author

qindazhu commented May 5, 2020

@csukuangfj do you notice that checks now are running with huge long time? Maybe we should remove some version ? Install cppcheck takes a lot of time..

@danpovey
Copy link
Collaborator

danpovey commented May 5, 2020 via email

@csukuangfj
Copy link
Collaborator

you can remove cppcheck.

the average check time per request is 10 min.

@qindazhu
Copy link
Collaborator Author

qindazhu commented May 5, 2020

I agree with you (Actually I just agree on following consistent style)

Ready to merge if there's no other issues.

@danpovey
Copy link
Collaborator

danpovey commented May 5, 2020 via email

@qindazhu
Copy link
Collaborator Author

qindazhu commented May 5, 2020

Our current style is C (instead of C++/OOP that including fsa-related operations in a class, i.e. fsa.empty(), fsa.ArcSort()), so I tend to keep Fsa structure very simple with only public members (and only a few const method and consturctor).

I see what you mean RE style. But also I'm not sure that I want accessors for the members; and for those function members, it does seem to be the natural place to put them. Any ideas about the best way to handle it?

On Tue, May 5, 2020 at 3:15 PM Fangjun Kuang @.> wrote: @.* commented on this pull request. ------------------------------ In k2/csrc/fsa.h <#27 (comment)>: > @@ -77,13 +79,43 @@ struct Fsa { // contains the first arc-index leaving this state (index into arcs). It is NOT a good style to define a struct in c++ that has both public data members and public methods. @qindazhu https://github.com/qindazhu @danpovey https://github.com/danpovey what do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27 (review)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZFLO224PCP4YHZZA6UMIDRP64ITANCNFSM4MZI42BA .

@danpovey
Copy link
Collaborator

danpovey commented May 5, 2020 via email

@csukuangfj
Copy link
Collaborator

+2

@qindazhu
Copy link
Collaborator Author

qindazhu commented May 5, 2020

Please merge if there's no other issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants