kaldi-developers — Kaldi Developers

Re: [Kaldi-developers] python wrappers for Kaldi

[Jan C. <jan...@gm...>]

Hi All,

the wrapper is built during Kaldi compilation. I build it using provided 
Makefile. The build depends on:
1. Python and numpy (by default it queries the python interpreter found 
on the path for header file location)
2. Boost with Boost::Python library. It is quite heavy to build, but 
most Linux distributions ship it. Boost python doesn't require any code 
generation steps, the wrapper is defined in a normal c++ code file.

During build Python and Boost libraries and Kaldi object files are 
linked into a CPython extention module, 
kaldi/src/python/kaldi_io_internal.so. It works with both static and 
shared Kaldi builds. Further usage requires that python finds 
kaldi_io.py and kaldi_io_internal.so on the PYTHONPATH - it can be for 
example added to the PYTHONPATH variable in the path.sh script of a recipe.

Jan

On 12/13/2014 3:33 PM, Daniel Povey wrote:
> Also, Jan- could you send us an email explaining how this works-
>    How does Python "see" the C++ headers?  Do you have to invoke some
> special program, like swig?  Do you have to write some special kind of
> header that shows how the C++ objects are to be interpreted by python?
>   A brief example would be helpful, if so.
>    How is the resulting program linked, if at all?  If you require
> functions C++ libraries, are these obtained from the .a or .so files
> at runtime, or compiled into some kind of executable-like blob at
> compile time?  Does your framework require that Kaldi be compiled
> using dynamic (.so) libraries?
>
> Dan
>
>
> On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski <jan...@gm...> wrote:
>> Hello Dan,
>>
>> thank you for the comments. I tried to make it in the Kaldi spirit,
>> consistency is important. Of course, the scripts can be removed and replaced
>> with some more useful examples. I don't have too much experience with
>> bridging Python to C++, so any critique on the wrappers and the approach
>> taken is welcome.
>>
>> Jan
>>
>>
>> On 12/13/2014 2:55 PM, Daniel Povey wrote:
>>> Hi all.
>>>   From a first look, it does look very impressive, and nicely documented.
>>> I would appreciate it if people on the list who have Python experience
>>> would comment on this- you can either reply to this thread, or to me.
>>> I don't know if this has been done in the "natural" way, or if there
>>> is some reason why people in the future will say, "why did you do it
>>> this way, you should have done XXX".
>>>
>>> Jan:
>>> in the scripts/ directory you seem to have some examples of how you
>>> can create python programs that behave very much like Kaldi
>>> command-line programs, using your framework.  This is very useful.
>>> However, the programs
>>>    apply-global-cmvn.py
>>>    compute-global-cmvn-stats.py
>>> are perhaps a little confusing because they provide the same
>>> functionality that you could get with "compute-cmvn-stats ->
>>> matrix-sum" and "apply-cmvn" on the output of that command; and they
>>> do so using different formats for the CMVN information.  I know the
>>> format of storing the CMVN stats in a two-row matrix is perhaps not
>>> perfectly ideal, but it's a standard within Kaldi and it would be
>>> confusing to deviate from that standard.
>>> Of course, this is a very minor issue that doesn't affect the validity
>>> of the framework as a whole.  I am just pointing this out; the main
>>> discussion should be about the framework and whether people feel it's
>>> the "right" way to do this.
>>>
>>> Dan
>>>
>>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski <jan...@gm...>
>>> wrote:
>>>> Hi all!
>>>>
>>>> I've written wrappers to access Kaldi data files from within Python
>>>> using boost::python (the code is on github
>>>> https://github.com/janchorowski/kaldi-git/tree/python/src/python). If
>>>> you think this would be an interesting addition please instruct me how
>>>> to contribute.
>>>>
>>>> Best Regards,
>>>> Jan Chorowski
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Kaldi-developers mailing list
>>>> Kal...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>

Re: [Kaldi-developers] python wrappers for Kaldi

[Daniel P. <dp...@gm...>]

Also, Jan- could you send us an email explaining how this works-
  How does Python "see" the C++ headers?  Do you have to invoke some
special program, like swig?  Do you have to write some special kind of
header that shows how the C++ objects are to be interpreted by python?
 A brief example would be helpful, if so.
  How is the resulting program linked, if at all?  If you require
functions C++ libraries, are these obtained from the .a or .so files
at runtime, or compiled into some kind of executable-like blob at
compile time?  Does your framework require that Kaldi be compiled
using dynamic (.so) libraries?

Dan


On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski <jan...@gm...> wrote:
> Hello Dan,
>
> thank you for the comments. I tried to make it in the Kaldi spirit,
> consistency is important. Of course, the scripts can be removed and replaced
> with some more useful examples. I don't have too much experience with
> bridging Python to C++, so any critique on the wrappers and the approach
> taken is welcome.
>
> Jan
>
>
> On 12/13/2014 2:55 PM, Daniel Povey wrote:
>>
>> Hi all.
>>  From a first look, it does look very impressive, and nicely documented.
>> I would appreciate it if people on the list who have Python experience
>> would comment on this- you can either reply to this thread, or to me.
>> I don't know if this has been done in the "natural" way, or if there
>> is some reason why people in the future will say, "why did you do it
>> this way, you should have done XXX".
>>
>> Jan:
>> in the scripts/ directory you seem to have some examples of how you
>> can create python programs that behave very much like Kaldi
>> command-line programs, using your framework.  This is very useful.
>> However, the programs
>>   apply-global-cmvn.py
>>   compute-global-cmvn-stats.py
>> are perhaps a little confusing because they provide the same
>> functionality that you could get with "compute-cmvn-stats ->
>> matrix-sum" and "apply-cmvn" on the output of that command; and they
>> do so using different formats for the CMVN information.  I know the
>> format of storing the CMVN stats in a two-row matrix is perhaps not
>> perfectly ideal, but it's a standard within Kaldi and it would be
>> confusing to deviate from that standard.
>> Of course, this is a very minor issue that doesn't affect the validity
>> of the framework as a whole.  I am just pointing this out; the main
>> discussion should be about the framework and whether people feel it's
>> the "right" way to do this.
>>
>> Dan
>>
>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski <jan...@gm...>
>> wrote:
>>>
>>> Hi all!
>>>
>>> I've written wrappers to access Kaldi data files from within Python
>>> using boost::python (the code is on github
>>> https://github.com/janchorowski/kaldi-git/tree/python/src/python). If
>>> you think this would be an interesting addition please instruct me how
>>> to contribute.
>>>
>>> Best Regards,
>>> Jan Chorowski
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Kaldi-developers mailing list
>>> Kal...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

Re: [Kaldi-developers] python wrappers for Kaldi

[Jan C. <jan...@gm...>]

Hello Dan,

thank you for the comments. I tried to make it in the Kaldi spirit, 
consistency is important. Of course, the scripts can be removed and 
replaced with some more useful examples. I don't have too much 
experience with bridging Python to C++, so any critique on the wrappers 
and the approach taken is welcome.

Jan

On 12/13/2014 2:55 PM, Daniel Povey wrote:
> Hi all.
>  From a first look, it does look very impressive, and nicely documented.
> I would appreciate it if people on the list who have Python experience
> would comment on this- you can either reply to this thread, or to me.
> I don't know if this has been done in the "natural" way, or if there
> is some reason why people in the future will say, "why did you do it
> this way, you should have done XXX".
>
> Jan:
> in the scripts/ directory you seem to have some examples of how you
> can create python programs that behave very much like Kaldi
> command-line programs, using your framework.  This is very useful.
> However, the programs
>   apply-global-cmvn.py
>   compute-global-cmvn-stats.py
> are perhaps a little confusing because they provide the same
> functionality that you could get with "compute-cmvn-stats ->
> matrix-sum" and "apply-cmvn" on the output of that command; and they
> do so using different formats for the CMVN information.  I know the
> format of storing the CMVN stats in a two-row matrix is perhaps not
> perfectly ideal, but it's a standard within Kaldi and it would be
> confusing to deviate from that standard.
> Of course, this is a very minor issue that doesn't affect the validity
> of the framework as a whole.  I am just pointing this out; the main
> discussion should be about the framework and whether people feel it's
> the "right" way to do this.
>
> Dan
>
> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski <jan...@gm...> wrote:
>> Hi all!
>>
>> I've written wrappers to access Kaldi data files from within Python
>> using boost::python (the code is on github
>> https://github.com/janchorowski/kaldi-git/tree/python/src/python). If
>> you think this would be an interesting addition please instruct me how
>> to contribute.
>>
>> Best Regards,
>> Jan Chorowski
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers

Re: [Kaldi-developers] python wrappers for Kaldi

[Daniel P. <dp...@gm...>]

Hi all.
>From a first look, it does look very impressive, and nicely documented.
I would appreciate it if people on the list who have Python experience
would comment on this- you can either reply to this thread, or to me.
I don't know if this has been done in the "natural" way, or if there
is some reason why people in the future will say, "why did you do it
this way, you should have done XXX".

Jan:
in the scripts/ directory you seem to have some examples of how you
can create python programs that behave very much like Kaldi
command-line programs, using your framework.  This is very useful.
However, the programs
 apply-global-cmvn.py
 compute-global-cmvn-stats.py
are perhaps a little confusing because they provide the same
functionality that you could get with "compute-cmvn-stats ->
matrix-sum" and "apply-cmvn" on the output of that command; and they
do so using different formats for the CMVN information.  I know the
format of storing the CMVN stats in a two-row matrix is perhaps not
perfectly ideal, but it's a standard within Kaldi and it would be
confusing to deviate from that standard.
Of course, this is a very minor issue that doesn't affect the validity
of the framework as a whole.  I am just pointing this out; the main
discussion should be about the framework and whether people feel it's
the "right" way to do this.

Dan

On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski <jan...@gm...> wrote:
> Hi all!
>
> I've written wrappers to access Kaldi data files from within Python
> using boost::python (the code is on github
> https://github.com/janchorowski/kaldi-git/tree/python/src/python). If
> you think this would be an interesting addition please instruct me how
> to contribute.
>
> Best Regards,
> Jan Chorowski
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers

Re: [Kaldi-developers] python wrappers for Kaldi

[Josef N. <jos...@gm...>]

wow, really cool!

On Sat, Dec 13, 2014 at 3:28 PM, Jan Chorowski <jan...@gm...>
wrote:
>
> Hi all!
>
> I've written wrappers to access Kaldi data files from within Python
> using boost::python (the code is on github
> https://github.com/janchorowski/kaldi-git/tree/python/src/python). If
> you think this would be an interesting addition please instruct me how
> to contribute.
>
> Best Regards,
> Jan Chorowski
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

[Kaldi-developers] python wrappers for Kaldi

[Jan C. <jan...@gm...>]

Hi all!

I've written wrappers to access Kaldi data files from within Python 
using boost::python (the code is on github 
https://github.com/janchorowski/kaldi-git/tree/python/src/python). If 
you think this would be an interesting addition please instruct me how 
to contribute.

Best Regards,
Jan Chorowski

Re: [Kaldi-developers] Custom search in Kaldi

[Daniel P. <dp...@gm...>]

Not really.  It's quite tricky.  If you have some dynamic part of the
grammar that is small enough to compile in-memory, you could do an
on-demand FST union of that with the main compiled grammar.  Including
the dynamic grammar as a sub-part of the main grammar is a bit more
tricky due to context.  It would probably be doable without too much
trouble if you assume it's separated by silence, but would still
require some work (and knowledge of how things work).
Dan


On Fri, Dec 12, 2014 at 10:12 AM, Alexander Solovets
<aso...@gm...> wrote:
> Hi all,
>
> Were there attempts to implement custom search in Kaldi? By "custom
> search" I mean not-WFST based, or maybe WFST search but that's able to
> take into account some prior knowledge about the sentence being
> recognized.
>
> --
> Sincerely, Alexander
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers

[Kaldi-developers] Custom search in Kaldi

[Alexander S. <aso...@gm...>]

Hi all,

Were there attempts to implement custom search in Kaldi? By "custom
search" I mean not-WFST based, or maybe WFST search but that's able to
take into account some prior knowledge about the sentence being
recognized.

-- 
Sincerely, Alexander

Re: [Kaldi-developers] OpenFST 1.4.1

[Daniel P. <dp...@gm...>]

OK, I tested your patch and it seems to work for the current OpenFst.

I noticed another issue-- you seem to be using openfst-1.3.2 as the
"older" version, but the current Kaldi uses openfst-1.3.4.
This may be why you have to use that new patch to fix begin_->begin
and end_->end in IntervalSet.  I think perhaps you should update your
setup to use openfst-1.3.4 as the older supported version.

I will check in a fix for the sgmm-*-multi-test separately.

Something else is that it's not very nice to have to specify
OPENFST_VERSION=1.4.2 on the command line to 'make'.  If someone were
to do this, and later type "make" again, it would go back to the older
version.  I think it might be better to instruct people to uncomment a
line in the Makefile if they want this.  Any comment?  Adding a
'configure' script at this level seems too heavyweight for now.

Dan


On Tue, Dec 9, 2014 at 10:33 PM, Dogan Can <dog...@us...> wrote:
> Hi Dan
>
> I’m attaching a new patch against kaldi-trunk. Please see my inline answers
> to your comments.
>
> I also addressed the openfst symbolic linking problem in tools/Makefile that
> was mentioned in your other email.
>
> I tested these changes on Ubuntu 12.04 with gcc-4.6 and clang-3.3. Clang
> build is printing a bunch of benign warnings on Linux (that we are
> suppressing in darwin makefiles with some extra flags). Maybe we should
> extract those flags from darwin makefiles to a common makefile shared on all
> builds. I mean I don’t see any reason why we should not fully support clang
> on Linux. Other than that, everything seems to be in working order on my
> end.
>
> Cheers,
> Dogan
>
>
>
>
> On Dec 9, 2014, at 1:53 PM, Daniel Povey <dp...@gm...> wrote:
>
> Thanks..
> There are a few minor things I think are worth changing:
>
> -  patches should now go not in tools/ but in tools/extras/.
>
>
> Done. I also moved the sequitur.patch into tools/extras and changed its
> build script to use this new location.
>
>
> - I'd prefer it if the test for the OpenFST version and the c++0x flag
> were in the configure script rather than in the makefiles/* (if some
> setups need extra flags you can put a test in the corresponding
> makefile though).  This will avoid the need to edit all the
> makefiles/*, and also I prefer kaldi.mk to just have a few simple
> options in it rather than having all kinds of conditional statements.
> Then it's easier to hand-edit if the user feels like it.  I'm OK with
> things breaking if someone re-installs OpenFst without rerunning
> "configure", because the concept is that you rerun "configure" any
> time you change something bug.
>
>
> Done.
>
>
> -in util/stl-utils.h, there are redundant #ifdef/#elif blocks, I think
> it would be easier to just do
> #if defined(_MSC_VER) || (__cplusplus > 199711L)
> #include <unordered_map>
> #include <unordered_set>
> using std::unordered_map;
> using std::unordered_set;
> #else
> …
>
>
> It seems the support for these macros is quite a mess at the moment. For
> instance I just noticed that the __cplusplus macro is defined to be 1 in
> gcc-4.6 (default on Ubuntu 12.04) when c++11 support is enabled. I had to
> change that condition to the following one to get things compile on Ubuntu.
>
> if __cplusplus > 199711L || defined(__GXX_EXPERIMENTAL_CXX0X__)
>
> I left redundant #ifdef blocks in place in case we need to further adjust
> these checks in the future. Once these things are somewhat settled we can
> get rid of the redundant cases. What do you think?
>
> - Wouldn't it be less confusing to add the -std=c++11 option instead
> of the -std=c++0x option?
>
>
> -std=c++11 is not supported on gcc-4.6.
>
> - For me, on Linux, the kaldi.mk did not work out of the box because
> your statement adding the -std=c++0x option was above the statement
>
> CXXFLAGS = -msse -msse2 -Wall -I.. \
>       -pthread \
> [etc.]
>
> Presumably when you put this test in the configure script instead of
> kaldi.mk, you can add this at the end rather than the beginning of
> kaldi.mk.
>
>
> I fixed this on Ubuntu 12.04 by adding the necessary c++11 flags to
> EXTRA_CXXFLAGS. Could you check if your Linux distro is happy after this
> change?
>
> I am not able to test this on my Mac (OS X 10.7.5).  I get this:
> configure: error: in `/Users/danielpovey/kaldi/trunk/tools/openfst-1.4.1':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
> make: *** [openfst-1.4.1/Makefile] Error 77
> and openfst/config.log has nothing interesting.  I am guessing it
> means my C++ compiler is out of date.  I checked MacPorts and there is
> nothing newer available.  [my version is "gcc version 4.2.1 (Based on
> Apple Inc. build 5658) (LLVM build 2336.1.00)”]
>
>
> You need gcc >= 4.6 for c++11 support. You can install the latest gcc (as
> well as older ones if needed) with homebrew.
>
> Anyway, this probably doesn't matter much.  It just means you should
> show me what the error was in that failing test so I will know how to
> fix it.
>
>
> I’m attaching an output log.
>
>
> Dan
>
> On Tue, Dec 9, 2014 at 4:36 AM, Dogan Can <dog...@us...> wrote:
>
> Hi Dan
>
> Sure, I’m attaching a patch against the kaldi-trunk. I just made a bunch of
> additional changes to get the failing tests succeed. At the moment, the only
> test failing on Mac OS 10.10 is sgmm/estimate-am-sgmm-multi-test. Could you
> take a look at that? I think it needs a threshold adjustment or something
> like that.
>
> Cheers,
> Dogan
>
> -------------------------------------
>
> Installation instructions:
>
> cd tools
> make -j 8 OPENFST_VERSION=1.4.1
> cd ../src
> ./configure
> make -j 8 depend
> make -j 8
>
> If OPENFST_VERSION is not set during the make call, then it defaults to
> 1.3.2, i.e. current installation instructions remain as they are.
>
> Apart from the script changes and a bunch of conditional includes, the major
> change in this patch is the addition of "util/basic-filebuf.h” which defines
> a modified version of the std::basic_filebuf class from libc++. It allows
> one to create a basic_filebuf object from an existing FILE* handle or file
> descriptor when linking against libc++. This is a fairly large change and
> has the potential to cause some regressions.
>
> By the way, “make -j 8 depend” step produces a bunch of “subframework"
> warnings on Mac OS 10.10 when compiling with GCC. It seems Apple dropped
> support for some previously deprecated stuff and GCC hasn’t caught up yet.
>
> Also note that this patch includes a few minor/cosmetic fixes here and
> there.
>
>
>
>
> On Dec 8, 2014, at 10:39 AM, Daniel Povey <dp...@gm...> wrote:
>
> Dogan, maybe you could attach your patch here and let Simon test it?
> Dan
>
>
> On Mon, Dec 8, 2014 at 1:38 PM, Dogan Can <dog...@us...> wrote:
>
> Hi Dan
>
> It builds on Mac OS X 10.10 both with g++ and clang. I haven't done any
> regression tests though. Also I haven't tested it on Linux yet.
>
> Paul, did you get a chance to test it on your end?
>
> Cheers
> Dogan
>
> —
> Sent from Mailbox
>
>
> On Mon, Dec 8, 2014 at 10:27 AM, Daniel Povey <dp...@gm...> wrote:
>
>
> Paul Dixon has already done some work to get Kaldi to compile with
> OpenFst 1.4 (and C++11), but it is not committed yet. Dogan was going
> to help get it committed, but I don't know how far along this is.
> Dogan, any comment?
> Dan
>
>
> On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
>
> The OpenFST 1.4.1 needs latest C++ standard (C++11). I'm not sure which
> of
> the C++11 features it needs, but not all compilers support that standard
> fully, or you have to use relatively recent version. That might be a bit
> of
> inconvenience for some people. Feel free to to experiment with it in
> connection to Kaldi -- there is not specific reason why to avoid it.
> y.
>
> On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
> wrote:
>
>
> Hi,
>
> I wondered if there exists any version of Kaldi using OpenFST version
> 1.4.1 by default, or if there would be any interest in having this
> option or any reason not to use it?!
>
> I am using Thrax for a rule based grammar used as the language model,
> and the current version requires the latest version of OpenFST.
>
> Is there any interest in reviewing, if I should add this as an option
> to
> the installation of the tools? I.e., adding support for (a patched)
> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
> perhaps as well NGram Library, if anyone might want to try it out)?
>
> All the best,
>
> Simon
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> Get technology previously reserved for billion-dollar corporations,
> FREE
>
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>
>
>
>
>
>

Re: [Kaldi-developers] OpenFST 1.4.1

[Dogan C. <dog...@us...>]

Hi Dan

I’m attaching a new patch against kaldi-trunk. Please see my inline answers to your comments.

I also addressed the openfst symbolic linking problem in tools/Makefile that was mentioned in your other email.

I tested these changes on Ubuntu 12.04 with gcc-4.6 and clang-3.3. Clang build is printing a bunch of benign warnings on Linux (that we are suppressing in darwin makefiles with some extra flags). Maybe we should extract those flags from darwin makefiles to a common makefile shared on all builds. I mean I don’t see any reason why we should not fully support clang on Linux. Other than that, everything seems to be in working order on my end.

Cheers,
Dogan



> On Dec 9, 2014, at 1:53 PM, Daniel Povey <dp...@gm...> wrote:
> 
> Thanks..
> There are a few minor things I think are worth changing:
> 
> -  patches should now go not in tools/ but in tools/extras/.

Done. I also moved the sequitur.patch into tools/extras and changed its build script to use this new location. 

> 
> - I'd prefer it if the test for the OpenFST version and the c++0x flag
> were in the configure script rather than in the makefiles/* (if some
> setups need extra flags you can put a test in the corresponding
> makefile though).  This will avoid the need to edit all the
> makefiles/*, and also I prefer kaldi.mk to just have a few simple
> options in it rather than having all kinds of conditional statements.
> Then it's easier to hand-edit if the user feels like it.  I'm OK with
> things breaking if someone re-installs OpenFst without rerunning
> "configure", because the concept is that you rerun "configure" any
> time you change something bug.

Done.

> 
> -in util/stl-utils.h, there are redundant #ifdef/#elif blocks, I think
> it would be easier to just do
> #if defined(_MSC_VER) || (__cplusplus > 199711L)
> #include <unordered_map>
> #include <unordered_set>
> using std::unordered_map;
> using std::unordered_set;
> #else
> …
> 

It seems the support for these macros is quite a mess at the moment. For instance I just noticed that the __cplusplus macro is defined to be 1 in gcc-4.6 (default on Ubuntu 12.04) when c++11 support is enabled. I had to change that condition to the following one to get things compile on Ubuntu.

if __cplusplus > 199711L || defined(__GXX_EXPERIMENTAL_CXX0X__)

I left redundant #ifdef blocks in place in case we need to further adjust these checks in the future. Once these things are somewhat settled we can get rid of the redundant cases. What do you think?

> - Wouldn't it be less confusing to add the -std=c++11 option instead
> of the -std=c++0x option?
> 

-std=c++11 is not supported on gcc-4.6.

> - For me, on Linux, the kaldi.mk did not work out of the box because
> your statement adding the -std=c++0x option was above the statement
> 
> CXXFLAGS = -msse -msse2 -Wall -I.. \
>       -pthread \
> [etc.]
> 
> Presumably when you put this test in the configure script instead of
> kaldi.mk, you can add this at the end rather than the beginning of
> kaldi.mk.
> 

I fixed this on Ubuntu 12.04 by adding the necessary c++11 flags to EXTRA_CXXFLAGS. Could you check if your Linux distro is happy after this change?

> I am not able to test this on my Mac (OS X 10.7.5).  I get this:
> configure: error: in `/Users/danielpovey/kaldi/trunk/tools/openfst-1.4.1':
> configure: error: C++ compiler cannot create executables
> See `config.log' for more details
> make: *** [openfst-1.4.1/Makefile] Error 77
> and openfst/config.log has nothing interesting.  I am guessing it
> means my C++ compiler is out of date.  I checked MacPorts and there is
> nothing newer available.  [my version is "gcc version 4.2.1 (Based on
> Apple Inc. build 5658) (LLVM build 2336.1.00)”]

You need gcc >= 4.6 for c++11 support. You can install the latest gcc (as well as older ones if needed) with homebrew <http://brew.sh/>.

> Anyway, this probably doesn't matter much.  It just means you should
> show me what the error was in that failing test so I will know how to
> fix it.

I’m attaching an output log.

> 
> Dan
> 
> On Tue, Dec 9, 2014 at 4:36 AM, Dogan Can <dog...@us...> wrote:
>> Hi Dan
>> 
>> Sure, I’m attaching a patch against the kaldi-trunk. I just made a bunch of additional changes to get the failing tests succeed. At the moment, the only test failing on Mac OS 10.10 is sgmm/estimate-am-sgmm-multi-test. Could you take a look at that? I think it needs a threshold adjustment or something like that.
>> 
>> Cheers,
>> Dogan
>> 
>> -------------------------------------
>> 
>> Installation instructions:
>> 
>> cd tools
>> make -j 8 OPENFST_VERSION=1.4.1
>> cd ../src
>> ./configure
>> make -j 8 depend
>> make -j 8
>> 
>> If OPENFST_VERSION is not set during the make call, then it defaults to 1.3.2, i.e. current installation instructions remain as they are.
>> 
>> Apart from the script changes and a bunch of conditional includes, the major change in this patch is the addition of "util/basic-filebuf.h” which defines a modified version of the std::basic_filebuf class from libc++. It allows one to create a basic_filebuf object from an existing FILE* handle or file descriptor when linking against libc++. This is a fairly large change and has the potential to cause some regressions.
>> 
>> By the way, “make -j 8 depend” step produces a bunch of “subframework" warnings on Mac OS 10.10 when compiling with GCC. It seems Apple dropped support for some previously deprecated stuff and GCC hasn’t caught up yet.
>> 
>> Also note that this patch includes a few minor/cosmetic fixes here and there.
>> 
>> 
>> 
>> 
>>> On Dec 8, 2014, at 10:39 AM, Daniel Povey <dp...@gm...> wrote:
>>> 
>>> Dogan, maybe you could attach your patch here and let Simon test it?
>>> Dan
>>> 
>>> 
>>> On Mon, Dec 8, 2014 at 1:38 PM, Dogan Can <dog...@us...> wrote:
>>>> Hi Dan
>>>> 
>>>> It builds on Mac OS X 10.10 both with g++ and clang. I haven't done any
>>>> regression tests though. Also I haven't tested it on Linux yet.
>>>> 
>>>> Paul, did you get a chance to test it on your end?
>>>> 
>>>> Cheers
>>>> Dogan
>>>> 
>>>> —
>>>> Sent from Mailbox
>>>> 
>>>> 
>>>> On Mon, Dec 8, 2014 at 10:27 AM, Daniel Povey <dp...@gm...> wrote:
>>>>> 
>>>>> Paul Dixon has already done some work to get Kaldi to compile with
>>>>> OpenFst 1.4 (and C++11), but it is not committed yet. Dogan was going
>>>>> to help get it committed, but I don't know how far along this is.
>>>>> Dogan, any comment?
>>>>> Dan
>>>>> 
>>>>> 
>>>>> On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
>>>>>> The OpenFST 1.4.1 needs latest C++ standard (C++11). I'm not sure which
>>>>>> of
>>>>>> the C++11 features it needs, but not all compilers support that standard
>>>>>> fully, or you have to use relatively recent version. That might be a bit
>>>>>> of
>>>>>> inconvenience for some people. Feel free to to experiment with it in
>>>>>> connection to Kaldi -- there is not specific reason why to avoid it.
>>>>>> y.
>>>>>> 
>>>>>> On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I wondered if there exists any version of Kaldi using OpenFST version
>>>>>>> 1.4.1 by default, or if there would be any interest in having this
>>>>>>> option or any reason not to use it?!
>>>>>>> 
>>>>>>> I am using Thrax for a rule based grammar used as the language model,
>>>>>>> and the current version requires the latest version of OpenFST.
>>>>>>> 
>>>>>>> Is there any interest in reviewing, if I should add this as an option
>>>>>>> to
>>>>>>> the installation of the tools? I.e., adding support for (a patched)
>>>>>>> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
>>>>>>> perhaps as well NGram Library, if anyone might want to try it out)?
>>>>>>> 
>>>>>>> All the best,
>>>>>>> 
>>>>>>> Simon
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>>>> from Actuate! Instantly Supercharge Your Business Reports and
>>>>>>> Dashboards
>>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>>>>> more
>>>>>>> Get technology previously reserved for billion-dollar corporations,
>>>>>>> FREE
>>>>>>> 
>>>>>>> 
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Kaldi-developers mailing list
>>>>>>> Kal...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>>>> more
>>>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>>> 
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Kaldi-developers mailing list
>>>>>> Kal...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>>>> 
>>>> 
>>>> 
>> 
>> 

Re: [Kaldi-developers] OpenFST 1.4.1

[Daniel P. <dp...@gm...>]

Thanks..
There are a few minor things I think are worth changing:

-  patches should now go not in tools/ but in tools/extras/.

- I'd prefer it if the test for the OpenFST version and the c++0x flag
were in the configure script rather than in the makefiles/* (if some
setups need extra flags you can put a test in the corresponding
makefile though).  This will avoid the need to edit all the
makefiles/*, and also I prefer kaldi.mk to just have a few simple
options in it rather than having all kinds of conditional statements.
Then it's easier to hand-edit if the user feels like it.  I'm OK with
things breaking if someone re-installs OpenFst without rerunning
"configure", because the concept is that you rerun "configure" any
time you change something bug.

-in util/stl-utils.h, there are redundant #ifdef/#elif blocks, I think
it would be easier to just do
#if defined(_MSC_VER) || (__cplusplus > 199711L)
#include <unordered_map>
#include <unordered_set>
using std::unordered_map;
using std::unordered_set;
#else
...

- Wouldn't it be less confusing to add the -std=c++11 option instead
of the -std=c++0x option?

- For me, on Linux, the kaldi.mk did not work out of the box because
your statement adding the -std=c++0x option was above the statement

CXXFLAGS = -msse -msse2 -Wall -I.. \
       -pthread \
[etc.]

Presumably when you put this test in the configure script instead of
kaldi.mk, you can add this at the end rather than the beginning of
kaldi.mk.

I am not able to test this on my Mac (OS X 10.7.5).  I get this:
configure: error: in `/Users/danielpovey/kaldi/trunk/tools/openfst-1.4.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
make: *** [openfst-1.4.1/Makefile] Error 77
and openfst/config.log has nothing interesting.  I am guessing it
means my C++ compiler is out of date.  I checked MacPorts and there is
nothing newer available.  [my version is "gcc version 4.2.1 (Based on
Apple Inc. build 5658) (LLVM build 2336.1.00)"]
 Anyway, this probably doesn't matter much.  It just means you should
show me what the error was in that failing test so I will know how to
fix it.

Dan

On Tue, Dec 9, 2014 at 4:36 AM, Dogan Can <dog...@us...> wrote:
> Hi Dan
>
> Sure, I’m attaching a patch against the kaldi-trunk. I just made a bunch of additional changes to get the failing tests succeed. At the moment, the only test failing on Mac OS 10.10 is sgmm/estimate-am-sgmm-multi-test. Could you take a look at that? I think it needs a threshold adjustment or something like that.
>
> Cheers,
> Dogan
>
> -------------------------------------
>
> Installation instructions:
>
> cd tools
> make -j 8 OPENFST_VERSION=1.4.1
> cd ../src
> ./configure
> make -j 8 depend
> make -j 8
>
> If OPENFST_VERSION is not set during the make call, then it defaults to 1.3.2, i.e. current installation instructions remain as they are.
>
> Apart from the script changes and a bunch of conditional includes, the major change in this patch is the addition of "util/basic-filebuf.h” which defines a modified version of the std::basic_filebuf class from libc++. It allows one to create a basic_filebuf object from an existing FILE* handle or file descriptor when linking against libc++. This is a fairly large change and has the potential to cause some regressions.
>
> By the way, “make -j 8 depend” step produces a bunch of “subframework" warnings on Mac OS 10.10 when compiling with GCC. It seems Apple dropped support for some previously deprecated stuff and GCC hasn’t caught up yet.
>
> Also note that this patch includes a few minor/cosmetic fixes here and there.
>
>
>
>
>> On Dec 8, 2014, at 10:39 AM, Daniel Povey <dp...@gm...> wrote:
>>
>> Dogan, maybe you could attach your patch here and let Simon test it?
>> Dan
>>
>>
>> On Mon, Dec 8, 2014 at 1:38 PM, Dogan Can <dog...@us...> wrote:
>>> Hi Dan
>>>
>>> It builds on Mac OS X 10.10 both with g++ and clang. I haven't done any
>>> regression tests though. Also I haven't tested it on Linux yet.
>>>
>>> Paul, did you get a chance to test it on your end?
>>>
>>> Cheers
>>> Dogan
>>>
>>> —
>>> Sent from Mailbox
>>>
>>>
>>> On Mon, Dec 8, 2014 at 10:27 AM, Daniel Povey <dp...@gm...> wrote:
>>>>
>>>> Paul Dixon has already done some work to get Kaldi to compile with
>>>> OpenFst 1.4 (and C++11), but it is not committed yet. Dogan was going
>>>> to help get it committed, but I don't know how far along this is.
>>>> Dogan, any comment?
>>>> Dan
>>>>
>>>>
>>>> On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
>>>>> The OpenFST 1.4.1 needs latest C++ standard (C++11). I'm not sure which
>>>>> of
>>>>> the C++11 features it needs, but not all compilers support that standard
>>>>> fully, or you have to use relatively recent version. That might be a bit
>>>>> of
>>>>> inconvenience for some people. Feel free to to experiment with it in
>>>>> connection to Kaldi -- there is not specific reason why to avoid it.
>>>>> y.
>>>>>
>>>>> On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I wondered if there exists any version of Kaldi using OpenFST version
>>>>>> 1.4.1 by default, or if there would be any interest in having this
>>>>>> option or any reason not to use it?!
>>>>>>
>>>>>> I am using Thrax for a rule based grammar used as the language model,
>>>>>> and the current version requires the latest version of OpenFST.
>>>>>>
>>>>>> Is there any interest in reviewing, if I should add this as an option
>>>>>> to
>>>>>> the installation of the tools? I.e., adding support for (a patched)
>>>>>> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
>>>>>> perhaps as well NGram Library, if anyone might want to try it out)?
>>>>>>
>>>>>> All the best,
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>>> from Actuate! Instantly Supercharge Your Business Reports and
>>>>>> Dashboards
>>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>>>> more
>>>>>> Get technology previously reserved for billion-dollar corporations,
>>>>>> FREE
>>>>>>
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Kaldi-developers mailing list
>>>>>> Kal...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>>> more
>>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Kaldi-developers mailing list
>>>>> Kal...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>>>
>>>
>>>
>
>

Re: [Kaldi-developers] OpenFST 1.4.1

[Dogan C. <dog...@us...>]

Hi Dan

Sure, I’m attaching a patch against the kaldi-trunk. I just made a bunch of additional changes to get the failing tests succeed. At the moment, the only test failing on Mac OS 10.10 is sgmm/estimate-am-sgmm-multi-test. Could you take a look at that? I think it needs a threshold adjustment or something like that.

Cheers,
Dogan

-------------------------------------

Installation instructions:

cd tools
make -j 8 OPENFST_VERSION=1.4.1
cd ../src
./configure
make -j 8 depend
make -j 8

If OPENFST_VERSION is not set during the make call, then it defaults to 1.3.2, i.e. current installation instructions remain as they are.

Apart from the script changes and a bunch of conditional includes, the major change in this patch is the addition of "util/basic-filebuf.h” which defines a modified version of the std::basic_filebuf class from libc++. It allows one to create a basic_filebuf object from an existing FILE* handle or file descriptor when linking against libc++. This is a fairly large change and has the potential to cause some regressions.

By the way, “make -j 8 depend” step produces a bunch of “subframework" warnings on Mac OS 10.10 when compiling with GCC. It seems Apple dropped support for some previously deprecated stuff and GCC hasn’t caught up yet.

Also note that this patch includes a few minor/cosmetic fixes here and there.

[Kaldi-developers] Fwd: [kaldi:code] [r4680] - danielpovey: trunk: modifying gpu-based nnet2 training code to do the I/O and input-data formatting in a separate thread from the main training thread (substantial speed improvement).

[Daniel P. <dp...@gm...>]

Anyone who is using the nnet2 training setup should probably update
their source and recompile for a 20% or so speedup (more when using
small models).  I reworked the I/O code so it happens in a separate
thread.

Dan



---------- Forwarded message ----------
From: Repository Kaldi code <no...@co...>
Date: Mon, Dec 8, 2014 at 6:10 PM
Subject: [kaldi:code] [r4680] - danielpovey: trunk: modifying
gpu-based nnet2 training code to do the I/O and input-data formatting
in a separate thread from the main training thread (substantial speed
improvement).
To: Repository Kaldi code <no...@co...>


trunk: modifying gpu-based nnet2 training code to do the I/O and
input-data formatting in a separate thread from the main training
thread (substantial speed improvement).
http://sourceforge.net/p/kaldi/code/4680/

________________________________

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/kaldi/code/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

Re: [Kaldi-developers] OpenFST 1.4.1

[Dogan C. <dog...@us...>]

Hi Dan


It builds on Mac OS X 10.10 both with g++ and clang. I haven't done any regression tests though. Also I haven't tested it on Linux yet.




Paul, did you get a chance to test it on your end?




Cheers

Dogan


—
Sent from Mailbox

On Mon, Dec 8, 2014 at 10:27 AM, Daniel Povey <dp...@gm...> wrote:

> Paul Dixon has already done some work to get Kaldi to compile with
> OpenFst 1.4 (and C++11), but it is not committed yet.  Dogan was going
> to help get it committed, but I don't know how far along this is.
> Dogan, any comment?
> Dan
> On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
>> The OpenFST 1.4.1 needs latest C++ standard (C++11).  I'm not sure which of
>> the C++11 features it needs, but not all compilers support that standard
>> fully, or you have to use relatively recent version. That might be a bit of
>> inconvenience for some people. Feel free to to experiment with it in
>> connection to Kaldi -- there is not specific reason why  to avoid it.
>> y.
>>
>> On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
>> wrote:
>>>
>>> Hi,
>>>
>>> I wondered if there exists any version of Kaldi using OpenFST version
>>> 1.4.1 by default, or if there would be any interest in having this
>>> option or any reason not to use it?!
>>>
>>> I am using Thrax for a rule based grammar used as the language model,
>>> and the current version requires the latest version of OpenFST.
>>>
>>> Is there any interest in reviewing, if I should add this as an option to
>>> the installation of the tools? I.e., adding support for (a patched)
>>> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
>>> perhaps as well NGram Library, if anyone might want to try it out)?
>>>
>>> All the best,
>>>
>>> Simon
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Kaldi-developers mailing list
>>> Kal...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>

Re: [Kaldi-developers] OpenFST 1.4.1

[Daniel P. <dp...@gm...>]

Dogan, maybe you could attach your patch here and let Simon test it?
Dan


On Mon, Dec 8, 2014 at 1:38 PM, Dogan Can <dog...@us...> wrote:
> Hi Dan
>
> It builds on Mac OS X 10.10 both with g++ and clang. I haven't done any
> regression tests though. Also I haven't tested it on Linux yet.
>
> Paul, did you get a chance to test it on your end?
>
> Cheers
> Dogan
>
> —
> Sent from Mailbox
>
>
> On Mon, Dec 8, 2014 at 10:27 AM, Daniel Povey <dp...@gm...> wrote:
>>
>> Paul Dixon has already done some work to get Kaldi to compile with
>> OpenFst 1.4 (and C++11), but it is not committed yet. Dogan was going
>> to help get it committed, but I don't know how far along this is.
>> Dogan, any comment?
>> Dan
>>
>>
>> On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
>> > The OpenFST 1.4.1 needs latest C++ standard (C++11). I'm not sure which
>> > of
>> > the C++11 features it needs, but not all compilers support that standard
>> > fully, or you have to use relatively recent version. That might be a bit
>> > of
>> > inconvenience for some people. Feel free to to experiment with it in
>> > connection to Kaldi -- there is not specific reason why to avoid it.
>> > y.
>> >
>> > On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I wondered if there exists any version of Kaldi using OpenFST version
>> >> 1.4.1 by default, or if there would be any interest in having this
>> >> option or any reason not to use it?!
>> >>
>> >> I am using Thrax for a rule based grammar used as the language model,
>> >> and the current version requires the latest version of OpenFST.
>> >>
>> >> Is there any interest in reviewing, if I should add this as an option
>> >> to
>> >> the installation of the tools? I.e., adding support for (a patched)
>> >> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
>> >> perhaps as well NGram Library, if anyone might want to try it out)?
>> >>
>> >> All the best,
>> >>
>> >> Simon
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> >> from Actuate! Instantly Supercharge Your Business Reports and
>> >> Dashboards
>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>> >> more
>> >> Get technology previously reserved for billion-dollar corporations,
>> >> FREE
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Kaldi-developers mailing list
>> >> Kal...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> > more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Kaldi-developers mailing list
>> > Kal...@li...
>> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >
>
>

Re: [Kaldi-developers] OpenFST 1.4.1

[Daniel P. <dp...@gm...>]

Paul Dixon has already done some work to get Kaldi to compile with
OpenFst 1.4 (and C++11), but it is not committed yet.  Dogan was going
to help get it committed, but I don't know how far along this is.
Dogan, any comment?
Dan


On Mon, Dec 8, 2014 at 12:19 PM, Jan Trmal <af...@ce...> wrote:
> The OpenFST 1.4.1 needs latest C++ standard (C++11).  I'm not sure which of
> the C++11 features it needs, but not all compilers support that standard
> fully, or you have to use relatively recent version. That might be a bit of
> inconvenience for some people. Feel free to to experiment with it in
> connection to Kaldi -- there is not specific reason why  to avoid it.
> y.
>
> On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
> wrote:
>>
>> Hi,
>>
>> I wondered if there exists any version of Kaldi using OpenFST version
>> 1.4.1 by default, or if there would be any interest in having this
>> option or any reason not to use it?!
>>
>> I am using Thrax for a rule based grammar used as the language model,
>> and the current version requires the latest version of OpenFST.
>>
>> Is there any interest in reviewing, if I should add this as an option to
>> the installation of the tools? I.e., adding support for (a patched)
>> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
>> perhaps as well NGram Library, if anyone might want to try it out)?
>>
>> All the best,
>>
>> Simon
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

Re: [Kaldi-developers] ATLAS in tools

[Jan T. <af...@ce...>]

I suspect ATLAS headers are used mostly for CBLAS declarations.
Some people use MKL or OpenBLAS instead of ATLAS, or, as you mentioned,
have ATLAS installed globally. I.e. for most cases compiling the ATLAS
during kaldi compilation does not make sense.
y.


On Mon, Dec 8, 2014 at 8:52 AM, Simon Klüpfel <sim...@gm...>
wrote:

> Hi,
>
> I saw that the Makefile in tools/ does only install the ATLAS headers,
> and not the library. Due to this I usually was running the
> ./install_atlas.sh script manually.
>
> Is this just for convenience, as you might use your globally installed
> ATLAS libraries and just need the headers, is this the intended default
> behavior, or, is this something that should in general not be like this,
> and rather compile and install the library?
>
> I just always wondered, when I installed Kaldi.
>
> All the best,
>
> Simon
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

Re: [Kaldi-developers] OpenFST 1.4.1

[Jan T. <af...@ce...>]

The OpenFST 1.4.1 needs latest C++ standard (C++11).  I'm not sure which of
the C++11 features it needs, but not all compilers support that standard
fully, or you have to use relatively recent version. That might be a bit of
inconvenience for some people. Feel free to to experiment with it in
connection to Kaldi -- there is not specific reason why  to avoid it.
y.

On Mon, Dec 8, 2014 at 8:47 AM, Simon Klüpfel <sim...@gm...>
wrote:

> Hi,
>
> I wondered if there exists any version of Kaldi using OpenFST version
> 1.4.1 by default, or if there would be any interest in having this
> option or any reason not to use it?!
>
> I am using Thrax for a rule based grammar used as the language model,
> and the current version requires the latest version of OpenFST.
>
> Is there any interest in reviewing, if I should add this as an option to
> the installation of the tools? I.e., adding support for (a patched)
> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
> perhaps as well NGram Library, if anyone might want to try it out)?
>
> All the best,
>
> Simon
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

Re: [Kaldi-developers] OpenFST 1.4.1

[Josef N. <jos...@gm...>]

Is there any interest in reviewing, if I should add this as an option to
> the installation of the tools? I.e., adding support for (a patched)
> 1.4.1 version, as well as options for the OpenGrm tools (Thrax and
> perhaps as well NGram Library, if anyone might want to try it out)?

Sounds pretty nice! The OpenGrm conversion tools also tend to generate more
compact representations.  Note however, that in order to use the Ngram
models created by OpenGrm directly in Kaldi, you may have to either modify
the machines, or [probably better] make some minor modifications to the
OpenGrm source.  The main issue is that Kaldi represents the G machine as a
transducer, while if I recall correctly, OpenGrm enforces a representation
of the model as a weighted acceptor.

Of course you can also use OpenGrm for training and dump in ARPA format
then use Kaldi tools normally  to get things to work.


>
> All the best,
>
> Simon
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

[Kaldi-developers] ATLAS in tools

[Simon K. <sim...@gm...>]

Hi,

I saw that the Makefile in tools/ does only install the ATLAS headers,
and not the library. Due to this I usually was running the
./install_atlas.sh script manually.

Is this just for convenience, as you might use your globally installed
ATLAS libraries and just need the headers, is this the intended default
behavior, or, is this something that should in general not be like this,
and rather compile and install the library?

I just always wondered, when I installed Kaldi.

All the best,

Simon

[Kaldi-developers] OpenFST 1.4.1

[Simon K. <sim...@gm...>]

Hi,

I wondered if there exists any version of Kaldi using OpenFST version
1.4.1 by default, or if there would be any interest in having this
option or any reason not to use it?!

I am using Thrax for a rule based grammar used as the language model,
and the current version requires the latest version of OpenFST.

Is there any interest in reviewing, if I should add this as an option to
the installation of the tools? I.e., adding support for (a patched)
1.4.1 version, as well as options for the OpenGrm tools (Thrax and
perhaps as well NGram Library, if anyone might want to try it out)?

All the best,

Simon

Re: [Kaldi-developers] Problems Running Kaldi Tests

[Daniel P. <dp...@gm...>]

I have modified that test program and it should pass now.

We normally don't get so many issues discovered by one person- it only
happens when we encounter a new platform that hasn't been properly
tested before.

Dan


On Thu, Dec 4, 2014 at 4:34 AM, Joaquin Antonio Ruales
<ja...@co...> wrote:
> Yep! now the matrix test works. Now I'm getting an error on the
> mle-full-gmm-test. could it be another problem only relevant to OSX
> Mavericks and Yosemite? Here are the last few lines of output of
> ./mle-full-gmm-test:
>
> Condition number of random matrix large 1.558446e+02, trying again (this is
> normal)
>
> Avg log-like per frame [full-cov, 1-mix] should be: -2.535968e+01
>
> Total log-like [full-cov, 1-mix] should be: -3.550355e+04
>
> Cov eigs are  [ 1.639155e+01 1.397001e+01 1.149592e+01 1.090052e+01
> 1.049452e+01 8.523492e+00 7.486929e+00 7.382205e+00 6.812490e+00
> 5.214448e+00 ]
>
> LOG (UnitTestEstimateFullGmm():mle-full-gmm-test.cc:361) Testing
> natural<>normal conversion
>
> KALDI_ASSERT: at UnitTestEstimateFullGmm:mle-full-gmm-test.cc:374, failed:
> std::abs(gmm->means_invcovars().Row(0)(d) -
> rgmm.means_invcovars().Row(0)(d)) < prec_v
>
> Stack trace is:
>
> 0   mle-full-gmm-test                   0x000000010b873bb7
> _ZN5kaldi18KaldiGetStackTraceEv + 71
>
> 1   mle-full-gmm-test                   0x000000010b873f86
> _ZN5kaldi19KaldiAssertFailure_EPKcS1_iS1_ + 230
>
> 2   mle-full-gmm-test                   0x000000010b78f8c6
> _Z23UnitTestEstimateFullGmmv + 4774
>
> 3   mle-full-gmm-test                   0x000000010b790a48 main + 40
>
> 4   libdyld.dylib                       0x000000010bb725fd start + 1
>
> 5   ???                                 0x0000000000000001 0x0 + 1
>
> Abort trap: 6
>
>
> On Wed, Dec 3, 2014 at 8:10 PM, Dogan Can <dog...@us...> wrote:
>>
>> Hi Dan,
>>
>> It turns out this was due to a bug in our RandGauss2 function that accepts
>> double arguments. I’m committing the following fix to kaldi trunk right
>> away.
>>
>> Cheers,
>> Dogan
>>
>> diff --git a/src/base/kaldi-math.cc b/src/base/kaldi-math.cc
>> index 5b30320..0de73bf 100644
>> --- a/src/base/kaldi-math.cc
>> +++ b/src/base/kaldi-math.cc
>> @@ -147,7 +147,7 @@ void RandGauss2(double *a, double *b, RandomState
>> *state)
>>    float a_float, b_float;
>>    // Just because we're using doubles doesn't mean we need
>> super-high-quality
>>    // random numbers, so we just use the floating-point version
>> internally.
>> -  RandGauss2(&a_float, &b_float);
>> +  RandGauss2(&a_float, &b_float, state);
>>    *a = a_float; *b = b_float;
>>  }
>>
>> On Dec 3, 2014, at 2:23 AM, Dogan Can <dog...@us...> wrote:
>>
>> Hi Dan
>>
>> I don’t have a Mavericks setup but I can replicate the failure on Yosemite
>> with clang. When everything is compiled with gcc, matrix-lib-test finishes
>> successfully.
>>
>> I looked a bit into the root cause of why the test was going into an
>> infinite loop. The random 3x3 matrices generated during the failing test end
>> up having the same first and third columns and fail the condition number
>> test, hence the generation loop never terminates. I did some sleuthing to
>> figure out how that was happening and it turns out the value of rstate.seed
>> (see the snippet below from matrix/kaldi-matrix.cc) is the same before and
>> after the call to RandGauss2 (note that inner for loop executes only once).
>> It seems like we are hitting a race condition in the system provided rand_r
>> implementation or a compiler bug.
>>
>>
>> 1093 template<typename Real>
>> 1094 void MatrixBase<Real>::SetRandn() {
>> 1095   kaldi::RandomState rstate;
>> 1096   for (MatrixIndexT row = 0; row < num_rows_; row++) {
>> 1097     Real *row_data = this->RowData(row);
>> 1098     MatrixIndexT nc = (num_cols_ % 2 == 1) ? num_cols_ - 1 :
>> num_cols_;
>> 1099     for (MatrixIndexT col = 0; col < nc; col += 2) {
>> 1100       kaldi::RandGauss2(row_data + col, row_data + col + 1, &rstate);
>> 1101     }
>> 1102     if (nc != num_cols_) row_data[nc] =
>> static_cast<Real>(kaldi::RandGauss(&rstate));
>> 1103   }
>> 1104 }
>>
>>
>> Cheers,
>> Dogan
>>
>> On Dec 2, 2014, at 10:13 PM, Daniel Povey <dp...@gm...> wrote:
>>
>> According to
>> http://stackoverflow.com/questions/19554439/gdb-missing-in-os-x-mavericks
>> gdb is no longer supported in mavericks and you have to use lldb. I've
>> never used that so I don't know what to tell you to do.
>> Dogan, do you have a mavericks setup, and can you see if you get the
>> infinite loop that he gets when you test?
>> Joaqin: I would just continue through the tutorial for now.  Probably
>> it's not going to be a problem.
>> Dan
>>
>>
>> On Wed, Dec 3, 2014 at 1:09 AM, Daniel Povey <dp...@gm...> wrote:
>>
>> Hm.  That makes me think there may be a problem with your gcc/gdb
>> installation- maybe you could try uninstalling it and installing it
>> again.  Did you get it from MacPorts?
>> Dan
>>
>>
>> On Wed, Dec 3, 2014 at 1:05 AM, Joaquin Antonio Ruales
>> <ja...@co...> wrote:
>>
>> Now I get:
>>
>>
>> Program received signal SIGINT, Interrupt.
>>
>> 0x00007fff8c755e9a in ?? ()
>>
>> (gdb) b matrix-lib-test.cc:39
>>
>> Cannot access memory at address 0xab670
>>
>>
>> On Wed, Dec 3, 2014 at 12:57 AM, Daniel Povey <dp...@gm...> wrote:
>>
>>
>> Probably when you did ctrl-c it was in the Atlas library, sometimes it
>> can't get a proper backtrace.  Instead, after doing ctrl-c do:
>> (gdb) b matrix-lib-test.cc:39
>> (gdb) c
>>
>> to continue, and when it breaks, show me a backtrace.
>> Dan
>>
>>
>> On Wed, Dec 3, 2014 at 12:48 AM, Joaquin Antonio Ruales
>> <ja...@co...> wrote:
>>
>> This is what I get:
>>
>>
>> Program received signal SIGINT, Interrupt.
>>
>> 0x00007fff8b2c6342 in ?? ()
>>
>> (gdb) bt
>>
>> #0  0x00007fff8b2c6342 in ?? ()
>>
>> #1  0x00007fff5fbfdbc8 in ?? ()
>>
>> #2  0x0000000000000001 in ?? ()
>>
>> #3  0x00007fff5fbfdfdc in ?? ()
>>
>> #4  0x00007fff5fbfdfe0 in ?? ()
>>
>> #5  0x00007fff5fbfdbbe in ?? ()
>>
>> #6  0x0000000100102672 in ?? ()
>>
>> #7  0x00007fff5fbfdc10 in ?? ()
>>
>> #8  0x00007fff8b00eac4 in ?? ()
>>
>> #9  0x00007fff5fbfda90 in ?? ()
>>
>> #10 0x00007fff8e2bf272 in ?? ()
>>
>> #11 0x00000002001a0a00 in ?? ()
>>
>> #12 0x00000001001a0a00 in ?? ()
>>
>> #13 0x000000010019d000 in ?? ()
>>
>> #14 0x00000001001a0a00 in ?? ()
>>
>> #15 0x00000001003002ca in ?? ()
>>
>> #16 0x0000000000000000 in ?? ()
>>
>>
>> On Wed, Dec 3, 2014 at 12:42 AM, Daniel Povey <dp...@gm...> wrote:
>>
>>
>> That isn't normal and it doesn't happen when I compile on a Mac.
>> Can you run it in gdb by doing
>> gdb ./matrix-lib-test
>> (gdb) r
>>
>> and then do ctrl-c when it gets in the loop and type "bt" and show me
>> the backtrace?
>> Dan
>>
>>
>> On Wed, Dec 3, 2014 at 12:36 AM, Joaquin Antonio Ruales
>> <ja...@co...> wrote:
>>
>> Hi Dan,
>>
>> Thanks for the quick reply. I have "svn up"ed and recompiled
>> everything,
>> but
>> now the same matrix test runs into an infinite loop. Would it be safe
>> to
>> ignore the test results and continue with the tutorial? Here are the
>> few
>> lines of output from the test:
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 7.50727e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.91265e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 7.70738e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 2.32488e+17, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 8.44565e+17, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.83557e+17, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 2.61736e+17, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 8.67803e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.80053e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.67101e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.49485e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 8.31813e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 1.6285e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 2.48172e+16, trying again (this is normal)
>>
>> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
>> random
>> matrix large 2.1569e+16, trying again (this is normal)
>>
>>
>> On Tue, Dec 2, 2014 at 4:35 PM, Daniel Povey <dp...@gm...>
>> wrote:
>>
>>
>> I think I had noticed this before, and I fixed the test by changing
>> the threshold.
>> If you do "svn up" and recompile, it should pass.
>> Dan
>>
>>
>> On Tue, Dec 2, 2014 at 4:20 PM, Joaquín Ruales
>> <ja...@co...>
>> wrote:
>>
>> Hi Kaldi Team,
>>
>> I'm running into trouble when running the Kaldi tests (make test)
>> described
>> in the Kaldi tutorial. I'm running it on a Mac (Mavericks) and the
>> error
>> is
>> in matrix-lib-test: KALDI_ASSERT: at
>> UnitTestLinearCgd:matrix-lib-test.cc:3118, failed: error < 1.0e-05
>> *
>> b.Norm(2.0)
>>
>> Has anyone faced this problem before or have any suggestions?
>>
>> Thanks,
>> Joaquín
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and
>> Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration
>> &
>> more
>> Get technology previously reserved for billion-dollar
>> corporations,
>> FREE
>>
>>
>>
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

Re: [Kaldi-developers] Problems Running Kaldi Tests

[Joaquin A. R. <ja...@co...>]

Yep! now the matrix test works. Now I'm getting an error on the
mle-full-gmm-test. could it be another problem only relevant to OSX
Mavericks and Yosemite? Here are the last few lines of output of
./mle-full-gmm-test:

Condition number of random matrix large 1.558446e+02, trying again (this is
normal)

Avg log-like per frame [full-cov, 1-mix] should be: -2.535968e+01

Total log-like [full-cov, 1-mix] should be: -3.550355e+04

Cov eigs are  [ 1.639155e+01 1.397001e+01 1.149592e+01 1.090052e+01
1.049452e+01 8.523492e+00 7.486929e+00 7.382205e+00 6.812490e+00
5.214448e+00 ]

LOG (UnitTestEstimateFullGmm():mle-full-gmm-test.cc:361) Testing
natural<>normal conversion

KALDI_ASSERT: at UnitTestEstimateFullGmm:mle-full-gmm-test.cc:374, failed:
std::abs(gmm->means_invcovars().Row(0)(d) -
rgmm.means_invcovars().Row(0)(d)) < prec_v

Stack trace is:

0   mle-full-gmm-test                   0x000000010b873bb7
_ZN5kaldi18KaldiGetStackTraceEv + 71

1   mle-full-gmm-test                   0x000000010b873f86
_ZN5kaldi19KaldiAssertFailure_EPKcS1_iS1_ + 230

2   mle-full-gmm-test                   0x000000010b78f8c6
_Z23UnitTestEstimateFullGmmv + 4774

3   mle-full-gmm-test                   0x000000010b790a48 main + 40

4   libdyld.dylib                       0x000000010bb725fd start + 1

5   ???                                 0x0000000000000001 0x0 + 1

Abort trap: 6

On Wed, Dec 3, 2014 at 8:10 PM, Dogan Can <dog...@us...> wrote:

> Hi Dan,
>
> It turns out this was due to a bug in our RandGauss2 function that accepts
> double arguments. I’m committing the following fix to kaldi trunk right
> away.
>
> Cheers,
> Dogan
>
> diff --git a/src/base/kaldi-math.cc b/src/base/kaldi-math.cc
> index 5b30320..0de73bf 100644
> --- a/src/base/kaldi-math.cc
> +++ b/src/base/kaldi-math.cc
> @@ -147,7 +147,7 @@ void RandGauss2(double *a, double *b, RandomState
> *state)
>    float a_float, b_float;
>    // Just because we're using doubles doesn't mean we need
> super-high-quality
>    // random numbers, so we just use the floating-point version internally.
> -  RandGauss2(&a_float, &b_float);
> +  RandGauss2(&a_float, &b_float, state);
>    *a = a_float; *b = b_float;
>  }
>
> On Dec 3, 2014, at 2:23 AM, Dogan Can <dog...@us...> wrote:
>
> Hi Dan
>
> I don’t have a Mavericks setup but I can replicate the failure on Yosemite
> with clang. When everything is compiled with gcc, matrix-lib-test finishes
> successfully.
>
> I looked a bit into the root cause of why the test was going into an
> infinite loop. The random 3x3 matrices generated during the failing test
> end up having the same first and third columns and fail the condition
> number test, hence the generation loop never terminates. I did some
> sleuthing to figure out how that was happening and it turns out the value
> of rstate.seed (see the snippet below from matrix/kaldi-matrix.cc) is the
> same before and after the call to RandGauss2 (note that inner for loop
> executes only once). It seems like we are hitting a race condition in the
> system provided rand_r implementation or a compiler bug.
>
>
> 1093 template<typename Real>
> 1094 void MatrixBase<Real>::SetRandn() {
> 1095   kaldi::RandomState rstate;
> 1096   for (MatrixIndexT row = 0; row < num_rows_; row++) {
> 1097     Real *row_data = this->RowData(row);
> 1098     MatrixIndexT nc = (num_cols_ % 2 == 1) ? num_cols_ - 1 :
> num_cols_;
> 1099     for (MatrixIndexT col = 0; col < nc; col += 2) {
> 1100       kaldi::RandGauss2(row_data + col, row_data + col + 1, &rstate);
> 1101     }
> 1102     if (nc != num_cols_) row_data[nc] =
> static_cast<Real>(kaldi::RandGauss(&rstate));
> 1103   }
> 1104 }
>
>
> Cheers,
> Dogan
>
> On Dec 2, 2014, at 10:13 PM, Daniel Povey <dp...@gm...> wrote:
>
> According to
> http://stackoverflow.com/questions/19554439/gdb-missing-in-os-x-mavericks
> gdb is no longer supported in mavericks and you have to use lldb. I've
> never used that so I don't know what to tell you to do.
> Dogan, do you have a mavericks setup, and can you see if you get the
> infinite loop that he gets when you test?
> Joaqin: I would just continue through the tutorial for now.  Probably
> it's not going to be a problem.
> Dan
>
>
> On Wed, Dec 3, 2014 at 1:09 AM, Daniel Povey <dp...@gm...> wrote:
>
> Hm.  That makes me think there may be a problem with your gcc/gdb
> installation- maybe you could try uninstalling it and installing it
> again.  Did you get it from MacPorts?
> Dan
>
>
> On Wed, Dec 3, 2014 at 1:05 AM, Joaquin Antonio Ruales
> <ja...@co...> wrote:
>
> Now I get:
>
>
> Program received signal SIGINT, Interrupt.
>
> 0x00007fff8c755e9a in ?? ()
>
> (gdb) b matrix-lib-test.cc:39
>
> Cannot access memory at address 0xab670
>
>
> On Wed, Dec 3, 2014 at 12:57 AM, Daniel Povey <dp...@gm...> wrote:
>
>
> Probably when you did ctrl-c it was in the Atlas library, sometimes it
> can't get a proper backtrace.  Instead, after doing ctrl-c do:
> (gdb) b matrix-lib-test.cc:39
> (gdb) c
>
> to continue, and when it breaks, show me a backtrace.
> Dan
>
>
> On Wed, Dec 3, 2014 at 12:48 AM, Joaquin Antonio Ruales
> <ja...@co...> wrote:
>
> This is what I get:
>
>
> Program received signal SIGINT, Interrupt.
>
> 0x00007fff8b2c6342 in ?? ()
>
> (gdb) bt
>
> #0  0x00007fff8b2c6342 in ?? ()
>
> #1  0x00007fff5fbfdbc8 in ?? ()
>
> #2  0x0000000000000001 in ?? ()
>
> #3  0x00007fff5fbfdfdc in ?? ()
>
> #4  0x00007fff5fbfdfe0 in ?? ()
>
> #5  0x00007fff5fbfdbbe in ?? ()
>
> #6  0x0000000100102672 in ?? ()
>
> #7  0x00007fff5fbfdc10 in ?? ()
>
> #8  0x00007fff8b00eac4 in ?? ()
>
> #9  0x00007fff5fbfda90 in ?? ()
>
> #10 0x00007fff8e2bf272 in ?? ()
>
> #11 0x00000002001a0a00 in ?? ()
>
> #12 0x00000001001a0a00 in ?? ()
>
> #13 0x000000010019d000 in ?? ()
>
> #14 0x00000001001a0a00 in ?? ()
>
> #15 0x00000001003002ca in ?? ()
>
> #16 0x0000000000000000 in ?? ()
>
>
> On Wed, Dec 3, 2014 at 12:42 AM, Daniel Povey <dp...@gm...> wrote:
>
>
> That isn't normal and it doesn't happen when I compile on a Mac.
> Can you run it in gdb by doing
> gdb ./matrix-lib-test
> (gdb) r
>
> and then do ctrl-c when it gets in the loop and type "bt" and show me
> the backtrace?
> Dan
>
>
> On Wed, Dec 3, 2014 at 12:36 AM, Joaquin Antonio Ruales
> <ja...@co...> wrote:
>
> Hi Dan,
>
> Thanks for the quick reply. I have "svn up"ed and recompiled
> everything,
> but
> now the same matrix test runs into an infinite loop. Would it be safe
> to
> ignore the test results and continue with the tutorial? Here are the
> few
> lines of output from the test:
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 7.50727e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.91265e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 7.70738e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 2.32488e+17, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 8.44565e+17, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.83557e+17, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 2.61736e+17, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 8.67803e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.80053e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.67101e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.49485e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 8.31813e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 1.6285e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 2.48172e+16, trying again (this is normal)
>
> LOG (RandPosdefSpMatrix():matrix-lib-test.cc:39) Condition number of
> random
> matrix large 2.1569e+16, trying again (this is normal)
>
>
> On Tue, Dec 2, 2014 at 4:35 PM, Daniel Povey <dp...@gm...>
> wrote:
>
>
> I think I had noticed this before, and I fixed the test by changing
> the threshold.
> If you do "svn up" and recompile, it should pass.
> Dan
>
>
> On Tue, Dec 2, 2014 at 4:20 PM, Joaquín Ruales
> <ja...@co...>
> wrote:
>
> Hi Kaldi Team,
>
> I'm running into trouble when running the Kaldi tests (make test)
> described
> in the Kaldi tutorial. I'm running it on a Mac (Mavericks) and the
> error
> is
> in matrix-lib-test: KALDI_ASSERT: at
> UnitTestLinearCgd:matrix-lib-test.cc:3118, failed: error < 1.0e-05
> *
> b.Norm(2.0)
>
> Has anyone faced this problem before or have any suggestions?
>
> Thanks,
> Joaquín
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration
> &
> more
> Get technology previously reserved for billion-dollar
> corporations,
> FREE
>
>
>
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>
>
>
>
>
>
>
>
>

Re: [Kaldi-developers] Estimation of global Constrained MLLR (CMLLR) transforms

[Daniel P. <dp...@gm...>]

If you have just features and GMMs, and not HMM-GMMs, what you
probably want is something like gmm-est-fmllr-global.
Dan


On Wed, Dec 3, 2014 at 8:36 PM, ask...@gm... <ask...@gm...> wrote:
> hi, i am going to transform features and plan to use gmm-est-fmllr in kaldi,
> below is the description of my work:
>
>    i have 60 GMM model of 60 speaker in language A, and 60 mfcc feature
> files of this 60 speaker in language B, i want to estimate global fmllr
> based on this, how to do it?
>
> gmm-est-fmllr [options] <model-in> <feature-rspecifier> <post-rspecifier>
> <transform-wspecifier>
>
>
> what format is the <post-rspecifier> in?
>
>
> ________________________________
> ask...@gm...
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

[Kaldi-developers] Estimation of global Constrained MLLR (CMLLR) transforms

[<ask...@gm...>]

hi, i am going to transform features and plan to use gmm-est-fmllr in kaldi, below is the description of my work:

   i have 60 GMM model of 60 speaker in language A, and 60 mfcc feature files of this 60 speaker in language B, i want to estimate global fmllr based on this, how to do it?

gmm-est-fmllr [options] <model-in> <feature-rspecifier> <post-rspecifier> <transform-wspecifier> 
what format is the <post-rspecifier> in?



ask...@gm...