Paul Goossens<br /> Director<br /> Commercial Market Development<br /> Maplesoft<br /> Ontario, Canada

Paul Goossens
Commercial Market Development
Ontario, Canada

For many manufacturers, the bulk of product-development dollars go to build, test, and refine prototypes, or possibly make repairs to them when things go wrong. In fact, most companies probably hope things go wrong at this stage so they can be corrected because flawed products that make it to market can bring class-action lawsuits.

This is why manufacturers more and more turn to "virtual prototyping" tools that let engineers analyze and visualize certain aspects of designs before they're built. In these tools, the math that describes and runs the simulations resides deep inside the software as rich sets of models and algorithms that represent real systems.

But what about all the work and thought that go into a design at the conceptual stage? Why do engineers still reach for a notepad, pen, and calculator when making critical design decisions? For many, the answer is there are no viable alternatives. Specifically, designers don't believe computers "do math" — equation formulation, algebraic manipulations, simplifications, and so forth — the same way they do.

This is true only if one views the use of spreadsheets or programming languages as "doing math" on computers. And for many " computersavvy" engineers, this is exactly what has happened. I have personally encountered several engineering projects where supporting calculations become locked inside cryptic spreadsheet formulae such as ((B12 + 2*$A$1)/A12)*2.3128.

These formula-based calculation tools tend to contort engineering information into inefficient, if not dangerous, forms. Admiral Harold Gehman, chairman of the Columbia [Space Shuttle] Accident Investigation Board, stated, "Neither NASA nor the board are satisfied with the model. It's essentially an Excel spreadsheet," noting that critical engineering calculations were performed with tools never designed for engineering work.

So-called interactive math systems such as Maple get around the problem. They explicitly manage math information in a way that more closely resembles how engineers work. Such packages have been referred to as "spreadsheets on steroids" for the depth and speed of their math solvers. This is a gross oversimplification because interactive systems differ fundamentally from spreadsheets and most other packages used by engineers to do math calculations. And it is these differences that help engineers be more productive.

Engineers are under ever-greater pressure to bring new products to market better, faster, and cheaper. The ability to enter mathematical problems in an intuitive way and get readable answers can cut the time needed for design calculations from months to days. A platform that has the computational breadth and depth to manage any level of engineering calculation, including dimensions and units, eliminates mathematical errors and lowers the risk of production delays and associated costs.

Increasingly, innovation starts with a mathematical premise that is then developed into a conceptual design. It is impossible in these cases to predetermine the analytical needs of the user because he still doesn't know all the parameters. Interactive math tools give computational headroom for such an approach.

In some ways, productivity gains have less to do with solving a math problem and more with the formulation, management, and deployment of the problem and answer. Engineers do more than calculate and simulate: they explore, collaborate, communicate, test, present and manage a diverse range of information.

It's been our experience that interactive math systems applied to the design process give up to 20X more bang for the buck than in any other stage of product development. And subsequent projects may see even greater benefit when design knowledge can be readily reused.

Maplesoft ( is a developer of mathematical and analytical software.