User:Arghya1998/proposal

Basic Details

Name	Arghya Bhattacharya
Email Address	arghya.b@research.iit.ac.in
Alternate Email Address	arghyatiger@gmail.com
IRC Nick	arghya[m]
Mobile	+91 9831325363
TimeZone	UTC + 5:30
Link to Gihub	https://github.com/arghyatiger
Link to Gitlab	https://gitlab.com/arghyatiger

Why am I interested in Machine Translation?

The broader perspective:

Being from a diverse country like India, with over 22 officially registered languages and over 1500 mother tongue languages (150 of them are sizeable), I’ve always been curious as to how languages serve as the basic entity of communication. During my childhood, I have lived in various places in India and hence I have had the chance to closely interact with people of different lingual backgrounds and in the process I ended up learning quite a few languages including Hindi, Bengali, English, Tamil, Oriya. The language diversity in my country is fascinating, but with it comes a lot of problems in communication and I believe that efficient machine translation can aid a lot of these problems and breaking the “language barrier” across not just the country and the globe and connect people better.

Academic Interests:

I am currently pursuing my B.Tech in Computer Science + M.S by Research in Computational Linguistics Dual Degree program at IIIT-Hyderabad, India. A good portion of our academic focus is on Machine Translation and I find it a really interesting area to work on. So working with apertium will help me nurture my Computational Linguistics skills as well as give me a chance to give back to the community with some solid contribution.

Why is it that I am interested in Apertium?

Being a student, with primary academic focus on Computational Linguistics, Apertium happens to be one of the important tools that I use for my university assignments like building transducers for small restricted grammar and building morphological generators.The Apertium projects provide a nice blend of linguistic and coding tasks and that makes the projects interesting to me. Belonging to the intersect of people who understand both linguistics and computers these projects really are the most relvant to my domain. Also as a part of the long-term goal of contributing to the community, I think contributions to Apertium would make a significant impact on the Computational Linguistics community all around the globe and that further motivates me to work for Apertium.

Which of the published tasks am I interested in?

To me, all the published tasks seemed to be interesting and hence it was difficult to choose only one. But I have been able to narrow down to the project which I like the most. It is called Python API/library for Apertium

Why should Google and Apertium sponsor the project of Python API for Apertium?

The Apertium code base is primarily written in C++. While C++ has a fairly high performance, supports low-level systems programming and is fairly available everywhere and reasonably well standardized, however, there are a few shortcomings to it as well. Some of them include the non-interactiveness of C++, the compile/debug/nap cycle and the endless difficulties in extending and modifying the modules. Also, Once the development of a module is done with, certain improvements like writing User-Interfaces and systems integration become really cumbersome in C++. Python, on the other hand, has a lot of features that c++ doesn’t have. Python has an interpreted high-level programming environment. And hence a python wrapper can provide flexibility, interactivity to Apertium’s code base. Also a lot of other features like ease of debugging, ease of testing, and rapid prototyping.

How and who will benefit from this project?

The project would bring a lot of developers at ease. Python is a high-level language with a lot of features that make it easier to grasp for developers. Python will also help increase the scalability of apertium in the future.A lot of people like to use Jupyter notebooks and Python, and a Python module would increase the user community. Hence I believe that if Apertium has a Python API, it would be helpful to a large community of developers, linguists, computational linguistics and all people keen on using the wide range of linguistic tools that we provide.

Detailed project plan and workflow

1. Detailed Project Goal:

The Goal of the project is to create structured python wrappers for the core modules of apertium, namely:

• Apertium/Lttoolbox
• Apertium/Apertium

a.) The modules would be python importable, the pythonic usage would be as follows:

b.) The modules would be nested so as to keep a proper code structure

c.) The internal usage of the functions would be as follows:

d.) Specialized IO functions have to be written for the wrapper as Python may not support a lot of input types, For example

Logical usage of this in python would be:

But this gives a Syntax error as - L isn't a valid string prefix in Python. in python. So we can accept a normal string ( str ) instead and pass the appropriate string along with the prefix to the core function

2. Tool to be used:

For the project, I plan on using SWIG to bind the C++ code. SWIG is a software development tool that simplifies the task of interfacing different languages to C and C++ programs. It is a compiler that takes C declarations and creates the wrappers needed to access those declarations from other languages. Among the other options that I explored for the project are Pyrex, ctypes, SIP, Boost.python.But for projects of huge scale such as this one, SWIG seems to be the most convenient due to a lot of features. These are explained later in the proposal.

3. Timeline :

Goals for the various phases:

PHASE	OBJECTIVE OF PHASE
Community Bonding Period	Good Understanding of all the modules, all the intricacies of binding each module and a detailed report of the modules
Phase 1	Binding/Testing the Lttoolbox Module
Phase 2	Binding/Testing the Apertium Module
Phase 3	Documentation of usage of the python modules and library organization of the modules made in previous phases

Week-Wise Goals:

PHASE AND BRIEF DESCRIPTION	DURATION	TASK EXPLANATION	DELIVERABLE OF THE WEEK
COMMUNITY BONDING PERIOD	START:April 23rd END:May 13th	Playing around with the lttoolbox and apertium modules and using every function and understanding all the flags and arguments of the functions. Reading up on the details of SWIG. Taking inputs from various apertium users on what would be the ideal implementation that they would want.
Week ONE : Lttoolbox setup	START:May 14th END:May 20th	Making explicit declarations of Constants and Enumerations of the module in SWIG interface Testing all pointer based data manipulation for any errors. (A common problem that might occur with swig bindings) Looking for Data Members that need to be made read-only and making necessary changes in the interface file, Identifying Static Class members, Python classes had no support for static methods and no version of Python supports static member variables in a manner that SWIG can utilize. Therefore, SWIG generates wrappers that try to work around some of these issues, but the other issues have to be taken care of manually. Resolving namespace problem of SWIG manually(occurs if there are multiple namespaces)	First importable wrapper of Lttoolbox module
WEEK TWO: Variable handling in SWIG for Lttoolbox module	START:May 21st END:May 27th	Making explicit declarations of Constants and Enumerations of the module in SWIG interface Testing all pointer based data manipulation for any errors. (A common problem that might occur with swig bindings) Looking for Data Members that need to be made read-only and making necessary changes in the interface file Identifying Static Class members: Python classes had no support for static methods and no version of Python supports static member variables in a manner that SWIG can utilize. Therefore, SWIG generates wrappers that try to work around some of these issues, but the other issues have to be taken care of manually. Resolving namespace problem of SWIG manually(occurs if there are multiple namespaces)	Second version of the wrapper with all data type usage support
WEEK THREE: Templating and Object Handling for Lttoolbox module	START:May 28th END:June 3rd	In order to create wrappers, one has to tell SWIG to create wrappers for a particular template instantiation. Hence all the templates have to be explicitly declared specific to the data being manipulated in them,. C++ Reference Counted Objects: Referencing and Dereferencing of objects have to be taken care of so that no error occurs, another place where SWIG isn’t smart enough. Handling C++ overloaded functions: Overloading support is not quite as flexible as in C++. Sometimes there are methods that SWIG can't disambiguate, if such errors appear then they have to be taken care of manually in the interface file of the wrapper.	Third version of the wrapper with all functions importable from python.
WEEK FOUR:Testing and improving cross language polymorphism, Making the module more pythonistic, Exception Handling	START:June 4th END:June 10th	Implement Director Classes: No mechanism exists to pass method calls down the inheritance chain from C++ to Python. In particular, if a C++ class has been extended in Python, these extensions will not be visible from C++ code. Virtual method calls from C++ are thus not able access the lowest implementation in the inheritance chain. There exists a feature implemented in SWIG called directors, The job of the directors is to route method calls correctly, either to C++ implementations higher in the inheritance chain or to Python implementations lower in the inheritance chain. Writing c++ helper functions: Sometimes the SWIG module misses bits of functionality because there is no easy way to construct and manipulate a suitable datatype, for those cases c++ helper functions need to be written. Writing High-Level Python function to provide a high-level Python interface built on top of low-level helper functions.Error Handling: If C++ throws an error then it is better to convert it into a python exception.	Fourth and final version with input functions and all helper functions written in python.
WEEK FIVE: Apertium setup	START:June 11th END:June 17th	Ref Week 1(***)	First version of the apertium module that is python importable
WEEK SIX: Variable handling in SWIG for Apertium module	START:June 18th END:June 24th	Ref Week 2	Second version of the apertium wrapper
WEEK SEVEN: Templating and Object Handling for Lttoolbox module	START:June 25th END:July 1st	Ref Week 3	Third version of the apertium wrapper with all functions importable from python
WEEK EIGHT: Testing and improving cross language polymorphism, Making the module more pythonistic, Exception Handling	START:July 2nd END:July 8th	Ref Week 4	Fourth and final version with input functions and all helper functions written in python.
WEEK NINE: Extensive alpha testing of modules built	START:July 9th END:July 15th	Testing the modules built by writing unit-tests for the functions in the modules Starting the documentation of the modules, since there are a lot of funcntions and the way swig deals with python is a little different than raw python, proper documentation of all the modules and their usages	Version 1 Documentation written Tests written for the lttoolbox module
WEEK TEN: Finishing Documentation	START:July 16th END:July 22nd	Finishing the documentation of the module Distribute for Beta testing, so that end users validate the usability, functionality, compatibility, and reliability	Tests written for apertium module Documentation version 2.
WEEK ELEVEN: Beta testing and changes(if any)	START:July 23rd END:July 29th	Taking reviews of beta testing and implementing changes if any.	Review Fix Version of wapper realease
WEEK TWELVE: Deciding on the library structure and making module pip installable	START:July 30th END:August 5th	Making the super wrapper for the modules. Making the module pip installable by writing scripts and uploading to PyPI Update Documentation	One wrapper with the 2 created wrappers inside it Pip Installable module
WEEK THIRTEEN: Final reviews and bug report	START:August 6th END:August 14th	Analyse and make bug report for the bugs in the code. Make Final documentation Release Final Module	Final Release of the wrapper.

(***)The tasks are similar to the tasks of the referenced week

Coding Challenge

• Transducer model python importable

• The library has

• Transducers can be built using:

• t.show() returns the transducer in tuple format:

Repo (in progress)

About me: Education and Experience

I am a sophomore at IIIT-Hyderabad, India, pursuing my Dual-Degree in Computer Science and Computational Linguistics. I’ve worked with C++ and Python closely in a lot of projects and I take keen interest in machine learning as well.I usually love building fun applications. The details of my work experience can be found here.

Non-Summer Of Code Plans

I have my college vacations during the months of Google Summer of Code, I would be able to devote around 40 man hours a week.I have a vacation plan for a week that lies in between but for the same reason, I have distributed the work accordingly in the timeline. If not selected I plan to start my research on sentiment analysis.