Google Data

(originally posted on the Geo Developers blog)

We are excited to announce that we are open-sourcing Google Earth Enterprise (GEE), the enterprise product that allows developers to build and host their own private maps and 3D globes. With this release, GEE Fusion, GEE Server, and GEE Portable Server source code (all 470,000+ lines!) will be published on GitHub under the Apache2 license in March.

Originally launched in 2006, Google Earth Enterprise provides customers the ability to build and host private, on-premise versions of Google Earth and Google Maps. In March 2015, we announced the deprecation of the product and the end of all sales. To provide ample time for customers to transition, we have provided a two year maintenance period ending on March 22, 2017. During this maintenance period, product updates have been regularly shipped and technical support has been available to licensed customers.

Feedback is important to us and we’ve heard from our customers that GEE remains in-use in mission-critical applications. Many customers have not transitioned to other technologies. Open-sourcing GEE allows our customer community to continue to improve and evolve the project in perpetuity. Note that the implementations for Google Earth Enterprise Client, Google Maps JavaScript® API V3 and Google Earth API will not be open sourced. The Enterprise Client will continue to be made available and updated. However, since GEE Fusion and GEE Server are being open-sourced, the imagery and terrain quadtree implementations used in these products will allow third-party developers to build viewers that can consume GEE Server Databases.

We’re thankful for the help of our GEE partners in preparing the codebase to be migrated to GitHub. It’s a lot of work and we cannot do it without them. It is our hope that their passion for GEE and GEE customers will serve to lead the project into its next chapter.

Looking forward, GEE customers can use Google Cloud Platform (GCP) instead of legacy on-premises enterprise servers to run their GEE instances. For many customers, GCP provides a scalable and affordable infrastructure as a service where they can securely run GEE. Other GEE customers will be able to continue to operate the software in disconnected environments. However, we believe that the advantages of incorporating even some of the workloads on GCP will become apparent (such as processing large imagery or terrain assets on GCP that can be downloaded and brought to internal networks, or standing up user-facing Portable Globe Factories).

Moreover, GCP is increasingly used as a source for geospatial data. Google’s Earth Engine has made available over a petabyte of raster datasets which are readily accessible and available to the public on Google Cloud Storage. Additionally, Google uses Cloud Storage to provide data to customers who purchase Google Imagery today. Having access to massive amounts of geospatial data, on the same platform as your flexible compute and storage, makes generating high quality Google Earth Enterprise Databases and Portables easier and faster than ever.

We will be sharing a series of white papers and other technical resources to make it as frictionless as possible to get open source GEE up and running on Google Cloud Platform. We are excited about the possibilities that open-sourcing enables, and we trust this is good news for our community. We will be sharing more information when we launch the code in March on GitHub. For general product information, visit the Google Earth Enterprise Help Center. Review the essential and advanced training for how to use Google Earth Enterprise, or learn more about the benefits of Google Cloud Platform.

Posted by Avnish Bhatnagar, Senior Technical Solutions Engineer, Google Cloud

Back in August, the Google Open Source Programs Office sponsored a meetup for contributors to Mercurial, a distributed version control system. Learn more about their two day hackfest below.

On August 29th-31st, the Mercurial project held one of its twice-a-year sprints in the Google Munich office. Mercurial is a distributed version control system, used by Python, OpenJDK, and Firefox among others. We had 24 developers in attendance, some from companies with large Mercurial deployments and some individual contributors who volunteer in their spare time.

One of the problems Mercurial wants to tackle soon is scaling from supporting hundreds of thousands of files to supporting millions of files in a single repository. The community has identified two approaches to scaling: shallow clones and narrow clones. Shallow clones will allow clients to pull down only part of a repository’s history, and narrow clones will make it possible to pull history for only some files.

At the sprint, we talked through some of the initial narrow/shallow clone implementation hurdles, like how to securely and efficiently store large manifests, and made good progress on a plan. We spent time working on changeset evolution, which makes it easier to manage the process of collaborating on a patch before it’s done. A group also discussed how to make bookmarks work better for users of changeset evolution in large systems, including developing a good plan around remote bookmark management.

If you are interested in finding out more about Mercurial (or perhaps you’d like to contribute to make it scale even better!) you can find our mailing list information here.

By Augie Fackler and Lennard de Rijk, Google Engineering

Today we have a post from Doris Lee, a 2014 Google Summer of Code student for the Laboratory for Cosmological Data Mining. Doris talks about her fascinating summer project exploring the galaxy. 

I first learned about Google Summer of Code (GSoC) through an informational session at my school, UC Berkeley. I was interested because of the program’s project-based nature which sounded like a lot of fun. I started by listing my favorite projects from each organization’s ideas page, and ended up getting so engrossed in the project and the code problem associated with the application that I submitted just one to the Laboratory of Cosmological Data Mining. The Laboratory was founded in 2002 at the University of Illinois by Professor Robert J. Brunner to develop and apply computational technologies to extract cosmological information from large astrophysical data sets being generated within the community.

But what I enjoyed the most about GSoC was the freedom to define the direction of my own work. The initial goal of the project was to make mosaics for large, bright galaxies from the Sloan Digital Sky Survey. However, in our first attempts some of the pictures that we made of the sky contained no galaxy at all! We discovered this was due to inherent inaccuracies in the coordinate values because the catalog was quite old. The course of my GSoC project was turned into developing an algorithm that uses newer imaging data to fix these inaccuracies and then mosaic them into pretty images. In the end, I designed a pipeline that enables users to automatically generate multi-band color images on any catalog of their choice. In addition, this pipeline is designed so it could be used on any set of data taken in the future. 

Overall, my mentor was very helpful with guiding me through my project and addressing my questions. I feel lucky to have worked on a project that I was so excited about and something I truly wanted to see working. 

Since my project made heavy use of open source software developed by other programmers and members of the scientific community, I learned a lot about how open source software projects are managed, documented, distributed and maintained. This was especially useful when I was developing the user interface and documentation to present my final GSoC project and making the code open source. In addition, I learned that in the free and open-source software community, effective documentation and readable code can be just as important as getting the code to work. The value of publicly-available code derives from how other users can benefit from it. You can view the work here on GitHub. 

Google Summer of Code meetups are a great way for students to spread the word about how the program works and meet fellow open source enthusiasts. If you are interested in holding a meetup at your University, please visit our FAQ page for more information.

On August 23rd, the Jamia Millia Islamia Linux User Group (JMILUG) hosted a Google Summer of Code (GSoC) meetup at Jamia Millia Islamia University in New Delhi. The meetup was an opportunity to learn from past and present GSoC students who have actively contributed to open source projects all over the world. The meetup also provided great information for budding developers who are ready to get their hands dirty and contribute to real world projects.

Over the last two years, nine JMILUG members have participated in GSoC. We felt it was time to give back to both the Indian GSoC students and open source community. We started accepting proposals from potential speakers for the event a couple of months before the meetup. Proposals were subject to a voting process through a website we built and speakers from the top voted sessions were called to give a talk.

The event was incredibly popular — we received over 250 registrations! We decided to move to a bigger venue and were able to accommodate everyone that was interested. On the day of the meet-up, we were pleased to welcome student participants from all academic levels and backgrounds.

The Google Open Source Programs Office graciously provided pens and t-shirts for the event. To make the speaker sessions more interactive, we distributed the goodies based on participation in a Q&A session after each talk. This also ensured that attendees listened intently to each speaker.

In total we had seven speakers give talks during the day-long event. Topics ranged from Angular.js to web accessibility. The final session of the day was dedicated to the topic “Getting into GSoC”. A high point was inviting all current GSoC participants on stage and having them share details about their experience and answer questions from the audience.

We wrapped up the day by distributing attendance certificates to speakers and t-shirts to the two most active audience members. Later, a lottery round was conducted and two people were selected randomly from the audience to be awarded another pair of GSoC T-shirts.

We hope that the meetup will attract many new students to GSoC and the world of open source coding. A big thanks to all of our speakers and attendees!

By Vipul Nayyar, GSoC participant in 2013 and 2014 and Umar Ahmad, GSoC participant in 2014

Google Summer of Code 2015 has just been announced! For more information please visit our program website.

At Google, we are passionate about introducing students to open source software development. Since 2005, the Open Source Programs team at Google has worked with over 10,000 students and over 485 open source projects in a variety of fields to create more code for us all.

Google Summer of Code 

For our Google Summer of Code wrap-up post this week, we put the spotlight on Worldforge, a project that provides tools to allow users to build their own virtual worlds.

Worldforge had three Google Summer of Code (GSoC) students this year. Now that the 2014 program has ended we’d like to highlight these three students and the work they’ve done.

Céline Noël, Smartbody integration in Ember.js
Céline worked on integrating the Smartbody system into Ember. Smartbody is a comprehensive system for simulating human behavior with all of the subtle body movements that natural motion entails.

Since Smartbody is a large system dealing with many different facets of human motion, a large part of the work done by Céline involved integration with Ember on the code level. Further work was then done modifying the Ember structure so that human entities can use Smartbody for their underlying animations and movement.

Celine’s work can be seen on Github. It will be merged into the Ember master branch in the coming months.

Péter Szücs, Android support for Ember.js
Péter worked on adding support for Android to Ember, including multi-touch support. The main difficulty initially was getting the Worldforge stack to build for Android using the existing Autoconf build system. Péter has made changes to most of the Worldforge libraries, as well as to the Hammer build tool. Hammer now has built in support for cross platform builds and will set up an Android toolchain by itself.

We expect to provide Android builds of Ember in the next couple of months. Keep an eye on the Worldforge news page for more information about Android support. In the coming weeks, we’ll start moving Péter’s work into the main repositories.

Yaroslav Taben, Cyphesis Entity filters
Yaroslav worked on adding entity filtering to Cyphesis, the server for Worldforge. Yaroslav’s project can basically be described as “functional filtering of entities using a query language”. It is very useful for things like AI code since authors then can more easily write rules for entity behaviour using a query-like language.

Yaroslav worked on both defining the rules for the query language and implementing this in an efficient way in the code. We used an iterative process for the language definition, where we tried out various syntaxes until we found one that fit our specific use case best.

The code can be seen on Github and we plan to start integrating it into Cyphesis in the coming weeks.

All of our students worked hard during the summer and produced excellent results. We’re very happy to have been a GSoC participating organization and hope to do so again next year.

By Erik Ogenvik, Organization Administrator, Worldforge

We continue our Friday Google Summer of Code wrap-up series with Apache Flink (previously Stratosphere) who was a first time participant in the program. Organization Administrator Robert Metzger talks below about their two successful student participants as well as their project’s transition to the Apache Software Foundation incubator program. 

Apache Flink is a system for expressive, declarative, fast, and efficient data analysis. Flink combines the scalability and programming flexibility of distributed MapReduce-like platforms with the efficiency, out-of-core execution, and query optimization capabilities found in parallel databases.

We were accepted to this year’s Google Summer of Code (GSoC) under our former project name “Stratosphere”. But during the summer our project entered the incubator of the Apache Software Foundation (ASF). Incubation is a process for new projects to enter the umbrella of the ASF. As part of the process our project name was subsequently changed from Stratosphere to Flink.

Our move to the ASF also meant quite a few changes for us and our students during the course of their projects. Both mentors and students were able to learn together about the new processes required by the ASF and in the end this transition worked out quite well for everyone involved.

The acceptance of our project into GSoC was a huge, exciting accomplishment for all of the Flink / Stratosphere developers and especially thrilling to a new, first time organization. We had two students this summer: Artem Tsikiridis and Frank Wu.

Artem worked on a full Hadoop MapReduce compatibility layer for Flink. Both Hadoop and Flink are distributed systems for processing huge amounts of data. Hadoop is an open source implementation of the MapReduce algorithm published by Google. It is widely used for a broad range of data intensive computing applications. Flink offers a broad range of operators and can be used to execute MapReduce-style applications.

Artem’s summer project concerned the implementation of a compatibility layer that exposes exactly the same APIs as Apache Hadoop. This feature allows existing Hadoop users to run their Hadoop jobs with Flink. Consequently, users are now able to utilize a faster execution engine for their existing code! Artem worked closely with the community and succeeded in bringing his changes into our main code line. His work will be available with the 0.7-incubating release of Apache Flink.

Frank Wu, our second GSoC student, worked on a large sub-project of Flink called Support for Streaming (Stratosphere Streaming). Frank initiated the development of the mini-batch processing API of Stratosphere Streaming, enabling operations on windows of tuples. Additionally, he contributed to both the iterative and stateful streaming solutions, two of the most challenging applications of streaming. Frank also provided numerous code examples for the topics he was working on. Like Artem, his work will be available with the 0.7-incubating release of Apache Flink.

I would like to thank the mentors, Fabian Hüske and Marton Belassi, as well as our second organization administrator, Ufuk Celebi, for their help with Stratosphere/Flink’s GSoC participation in the summer of 2014.

By Robert Metzger, Organization Administrator for Apache Flink

Student majors in 2014 were predominantly in Computer Science and other technical fields (as expected).  But this year we also had students studying Anthropology, Cartography, Evolutionary Biology, Linguistics and even Metallurgy. GSoC certainly attracts a diverse set of students year after year! For more stats from 2014, check out the other posts in this series.

We’d like to thank the schools and professors that help spread the word about GSoC to their students. But don’t forget that students from any university are encouraged to participate! Reviewing statistics each year from GSoC is exciting, but being in “first place” is certainly not the most important part of the program. Our goal since the inception of GSoC is to get students involved in the creation of free and open source software, and to encourage contributions to projects that have the potential to make a difference worldwide — no matter what university the student attends.

By Mary Radomile, Open Source Programs

Google Summer of Code 2014 has come to a close and news of the great work completed by our 1300+ student participants is starting to pour in. Our first student “wrap-up” post is from Twitter, a three time Summer of Code participant. We’ll be featuring these stories on Fridays this fall.

A recent Pew study found that 86% of people surveyed had taken steps to protect their security online. This is great—more security is always good. However, if people are indeed working to protect themselves, why are we still seeing incidents, breaches, and confusion? In many cases these problems recur because the technology that allows people to secure their communications, content and online activity is too hard to use.

In other words, the tools for the job exist. But while many of these tools work technically, they don’t always work in ways that users expect. They introduce extra steps or are simply confusing and cumbersome. (“Is this a software bug, or am I doing something wrong?”) However elegant and intelligent the underlying technology (and much of it is truly miraculous), the results are in: if people can’t use it easily, many of them won’t.

We believe that people shouldn’t have to make a trade-off between security and ease of use. This is why we’re happy to support Simply Secure, a new organization dedicated to improving the usability and safety of open-source tools that help people secure their online lives.

Over the coming months, Simply Secure will be collaborating with open-source developers, designers, researchers, and others to take what’s there—groundbreaking work from efforts like Open Whisper Systems, The Guardian Project, Off-the-Record Messaging, and more—and work to make them easier to understand and use.

We’re excited for a future where people won’t have to choose between ease and security, and where tools that allow people to secure their communications, content, and online activity are as easy as choosing to use them.

By Meredith Whittaker, Open Source Research Lead and Ben Laurie, Senior Staff Security Engineer

Today we are announcing a new category of client libraries that has been built specifically for Google Cloud Platform. The very first library, gcloud-node, is idiomatic and intuitive for Node.js developers. With today’s release, you can begin integrating Cloud Datastore and Cloud Storage into your Node.js applications, with more Cloud Platform APIs and programming languages planned.

 The easiest way to get started is by installing the gcloud package using npm:

$ npm install gcloud

With gcloud installed, your Node.js code is simpler to write, easier to read, and cleaner to integrate with your existing Node.js codebase. Take a look at the code required to retrieve entities from Datastore:

var gcloud = require('gcloud');

var dataset = new gcloud.datastore.Dataset({
projectId: 'my-project',
keyFilename: '/path/to/keyfile.json' // Details at 
              //https://github.com/googlecloudplatform/gcloud-node#README
});

dataset.get(dataset.key('Product', 123), function(err, entity) {
console.log(err, entity);
});

gcloud is open-sourced on Github; check out the code, file issues and contribute a PR – contributors are welcome. Got questions? Post them on StackOverflow with the [gcloud-node] tag. Learn more about the Client Library for Node.js at http://googlecloudplatform.github.io/gcloud-node/ and try gcloud-node today.

 -Posted by JJ Geewax, Software Engineer

Node.js is a trademark of Joyent, Inc. and npm is a trademark of npm, Inc.

How can we measure the number of additional clicks or sales that an AdWords campaign generated? How can we estimate the impact of a new feature on app downloads? How do we compare the effectiveness of publicity across countries?

In principle, all of these questions can be answered through causal inference.

In practice, estimating a causal effect accurately is hard, especially when a randomised experiment is not available. One approach we’ve been developing at Google is based on Bayesian structural time-series models. We use these models to construct a synthetic control — what would have happened to our outcome metric in the absence of the intervention. This approach makes it possible to estimate the causal effect that can be attributed to the intervention, as well as its evolution over time.

We’ve been testing and applying structural time-series models for some time at Google. For example, we’ve used them to better understand the effectiveness of advertising campaigns and work out their return on investment. We’ve also applied the models to settings where a randomised experiment was available, to check how similar our effect estimates would have been without an experimental control.

Today, we’re excited to announce the release of CausalImpact, an open-source R package that makes causal analyses simple and fast. With its release, all of our advertisers and users will be able to use the same powerful methods for estimating causal effects that we’ve been using ourselves.

Our main motivation behind creating the package has been to find a better way of measuring the impact of ad campaigns on outcomes. However, the CausalImpact package could be used for many other applications involving causal inference. Examples include problems found in economics, epidemiology, or the political and social sciences.

How the package works
The CausalImpact R package implements a Bayesian approach to estimating the causal effect of a designed intervention on a time series. Given a response time series (e.g., clicks) and a set of control time series (e.g., clicks in non-affected markets, clicks on other sites, or Google Trends data), the package constructs a Bayesian structural time-series model with a built-in spike-and-slab prior for automatic variable selection. This model is then used to predict the counterfactual, i.e., how the response metric would have evolved after the intervention if the intervention had not occurred.

As with all methods in causal inference, valid conclusions require us to check for any given situation whether key model assumptions are fulfilled. In the case of CausalImpact, we are looking for a set of control time series which are predictive of the outcome time series in the pre-intervention period. In addition, the control time series must not themselves have been affected by the intervention. For details, see Brodersen et al. (2014).

A simple example
The figure below shows an application of the R package. Based on the observed data before the intervention (black) and a control time series (not shown), the model has computed what would have happened after the intervention at time point 70 in the absence of the intervention (blue).

The difference between the actual observed data and the prediction during the post-intervention period is an estimate of the causal effect of the intervention. The first panel shows the observed and predicted response on the original scale. The second panel shows the difference between the two, i.e., the causal effect for each point in time. The third panel shows the individual causal effects added up in time.

The script used to create the above figure is shown in the left part of the window below. Using package defaults means our analysis boils down to just a single line of code: a call to the function CausalImpact() in line 10. The right-hand side of the window shows the resulting numeric output. For details on how to customize the model, see the documentation.

How to get started
The best place to start is the package documentation. The package is hosted on Github and can be installed using:

install.packages(“devtools”)
library(devtools)
devtools::install_github(“google/CausalImpact”)
library(CausalImpact)

By Kay H. Brodersen, Google

Today’s guest post comes from Bradley Kuhn, President of Software Freedom Conservancy. Conservancy and Google Summer of Code have had a long history as partners and in many cases Conservancy has made it possible for organizations to participate in our program. Read on for more details on how becoming a member of Conservancy can benefit your project in Google Summer of Code and beyond.

Software Freedom Conservancy, Inc. is a 501(c)(3) non-profit charity that serves as a home to Open Source and Free Software projects. In this post I’d like to discuss what that means and why such projects need a non-profit home. In short, Conservancy seeks to makes the lives of Free Software developers easier and it gives contributors much less administrative work to do outside of their area of focus (i.e., software development and documentation).

Google Summer of Code (GSoC) is a great example to show the value a non-profit home brings to Free Software projects. GSoC is likely the largest philanthropic program in the Open Source and Free Software community today. However, one of the most difficult things for organizations who seek to take advantage of such programs is the necessary administrative overhead. Google invests heavily in making it easy for organizations to participate in the program (for instance, by handling the details of stipend payments to students directly). However, to take full advantage of any philanthropic program, the benefiting organization has some work to do. For its member projects, Conservancy is the organization that gets that logistical work done.

Google donates $500 to the mentoring organizations for every student it mentors. However, these funds need to go somewhere. If the funds go to an individual, there are two inherent problems. First, that individual is responsible for taxes on that income. Second, funds belonging to an organization as a whole are now in the bank account of a single project leader. Conservancy solves both those problems. As a tax-exempt charity, the mentor payments are available for organizational use under its tax exemption. Furthermore, Conservancy maintains earmarked funds for each of its projects. Conservancy keeps the mentor funds for the Free Software project, and the project leaders can later vote to make use of the funds in a manner that helps the project and Conservancy’s charitable mission. Often times, projects in Conservancy use these funds to send developers to important conferences to speak about the project and recruit new developers and users.

Google also offers to pay travel expenses for two mentors from each mentoring organization to attendGSoC Mentor Summit. Conservancy handles this work on behalf of its member projects in two directions. First, for developers who don’t have a credit card or otherwise are unable to pay for their own flight and receive reimbursement later, our staff book the flights on Conservancy’s credit card. For the other travelers, Conservancy handles the reimbursement details. And on the back end, we handle all the overhead issues in requesting the POs from Google, invoicing for the funds, and tracking to ensure payment is made.
the annual

GSoC coordination is just one of the many things that Conservancy does every day for its member projects. If there’s anything other than software development and documentation that you can imagine a project needs, Conservancy does that job for its member projects. This includes not only mundane items such as travel coordination, but also issues as complex as trademark filings and defense, copyright licensing advice and enforcement, governance coordination and mentoring, and fundraising for the projects. Some of Conservancy’s member projects have been so successful that they’ve been able to fund developers’ salaries — often part-time but occasionally full-time — for many years to allow them to focus on improving the project’s software for the public benefit.

If your project seeks help with regards to handling its GSoC funds and travel, or anything else mentioned on Conservancy’s list of services to member projects, Conservancy is welcoming new applications for membership. Your project could join Conservancy’s more than thirty other member projects and receive these important services to help your community grow and focus on its core mission of building software for the public good.

By Bradley M. Kuhn, President, Software Freedom Conservancy

Today we are happy to announce the first stable release of Glide 3.0. Glide is an open source media management framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface.

Today marks the final post in our series highlighting new Google Summer of Code organizations for 2014. Organization administrators from BioJavaScript, Julia and GNU Octave discuss their students’ projects below.

BioJavaScript (BioJS) is an open source library and standard for visualization of biological data on the web. BioJS provides widgets (a pre-made piece of code that performs a task needed in lab software) that can be easily reused, combined and extended, following a common architecture and documentation. BioJS is great for labs with few resources to be able to reutilize, find and share existing functionality.

For Google Summer of Code (GSoC) 2014, our students worked on a series of widgets such as a taxonomy viewer that is zoomable at different resolutions and a phylogenetic tree viewer that displays proteins in a tree and branches according to their evolutionary proximity.

By Manuel Corpas, Organization Administrator for BioJS

———————–

Julia is a new dynamic programming language aimed primarily at technical computing. It is designed to be both high-level and high-performance, thus replacing the need to have separate languages to achieve these goals. Development on Julia started in 2009 and the project has since become a global collaboration—over 250 collaborators around the world have written close to 20,000 lines of code in the core Julia repository alone.

2014 marks our first time participating in Google Summer of Code and our three students have finished up their highly successful projects:

• Simon Danisch is working on volumetric, particle and surface visualizations entirely in Julia and OpenGL. He has been blogging about his progress and all his code is available here on GitHub.
• Mikes Innes is building a Julia environment on top of the excellent Light Table platform. It will support building big projects in small steps by modifying them as they are running. It tightly integrates tools such as the profiler and the upcoming documentation and debugging systems, with the aim of being accessible for novices and powerful for seasoned Julians. His work is available through the LightTable plugin manager as well as on GitHub.
• Shashi Gowda is working on making use of the recently added real-time interaction support in IJulia notebooks. It will allow users to create widgets including sliders, drop-downs, colorpickers and other input elements in their notebooks and connect them to plots, DataFrames and other output. As part of this work he has also been working on React.jl, an Elm-inspired reactive-programming package for Julia. His code is available on GitHub.

By Keno Fischer, Organization Administrator for Julia

——————–

GNU Octave is a high-level interpreted programming language primarily intended for numerical computations. It provides a command-line interface for solving linear and nonlinear problems numerically and for performing other numerical experiments using a language that is mostly compatible with MATLAB.

We are excited to have three GSoC students who worked with us this summer. Their projects include:

• Improving finite element modeling capabilities through an interface to FEniCS
• Adding incomplete matrix factorization capabilities
• Improving the handling of sparse matrices

By Carlos Fernandez, Organization Administrator for GNU Octave