The number (int)log(tmat[0][0]) that is stored in the file WILL be a negative number, precisely because "the actual probability is between 0 and 1". Log of any number between 0 and 1 is a negative number. You cannot make it positive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2000-11-23
Oh, I actually meant that why I got an positive number from the *.chmm file.
Here is an example. In the +BREATH+.chmm, the first transition probability is 105039,from state 0 to state 0.
This is within the function "hmm_tied_bin_parse(...)" and in the file "hmm_tied_r.c".
Is the number I got right?
Thanks,
Jun Liu
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, that looks like a byte-swap error. What platform are you running on? Sphinx should automatically handle byte orders in most formats, but it seems to be incorrect here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2000-11-27
I am running on Win32. The program has done byte-swap. The first transition value in '+BREATH+.CHMM' is 1335492864 before swapped and is 105039 after swapped.
And, I get the same result in Linux.
I have created a new project by VC in Win32 and KDE in Linux.
The recognition results both are 'GO FORWARD TEN METERS'.
Where is the problem?
Thanks,
Jun Liu.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My best bet now that i've seen this a couple of times is that WinZip tries to be "smart" about decoding the tar.gz file, sees the .chmm files as text, and inserts some control-Ms into it. But if you get the same result under Linux as well, I am at a loss without more data. Perhaps you could md5sum the models on both platforms?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the SCHMM_format file, the state to state transition probability is an integer in 4 bytes
and got by operation '(int)log(tmat[0][0])'.
[0 0 (int)log(tmat[0][0]) 0] (source, dest, transition prob, source id)
My question is that since the actual probability is between 0 and 1, how to get a positive integer
in the *.chmm files.
Thank you.
The number (int)log(tmat[0][0]) that is stored in the file WILL be a negative number, precisely because "the actual probability is between 0 and 1". Log of any number between 0 and 1 is a negative number. You cannot make it positive.
Oh, I actually meant that why I got an positive number from the *.chmm file.
Here is an example. In the +BREATH+.chmm, the first transition probability is 105039,from state 0 to state 0.
This is within the function "hmm_tied_bin_parse(...)" and in the file "hmm_tied_r.c".
Is the number I got right?
Thanks,
Jun Liu
Hmm, that looks like a byte-swap error. What platform are you running on? Sphinx should automatically handle byte orders in most formats, but it seems to be incorrect here.
I am running on Win32. The program has done byte-swap. The first transition value in '+BREATH+.CHMM' is 1335492864 before swapped and is 105039 after swapped.
And, I get the same result in Linux.
I have created a new project by VC in Win32 and KDE in Linux.
The recognition results both are 'GO FORWARD TEN METERS'.
Where is the problem?
Thanks,
Jun Liu.
My best bet now that i've seen this a couple of times is that WinZip tries to be "smart" about decoding the tar.gz file, sees the .chmm files as text, and inserts some control-Ms into it. But if you get the same result under Linux as well, I am at a loss without more data. Perhaps you could md5sum the models on both platforms?