|
|
|
|
|
|
|
|
Home > Blog
|
|
|
4/8/2009
As part of the next Inference release, we've started working on Inference in PowerPoint. Similar to Inference in Word, Inference in PowerPoint will enable you to assemble dynamic Microsoft PowerPoint presentations containing your data, objects, IronPython/IronRuby code, and text annotations (commentary). When executed, Inference in PowerPoint will run your IronPython/IronRuby code and generate a Results Document presentation that contains textual, numerical and graphic output of scripting commands in addition to formatted text annotations.
The next Inference release is due out this summer. Here's a screenshot of our latest build:
If you have any thoughts as to what you'd like to see in the Inference in PowerPoint module, feel free to comment to this blog post or shoot me an email at development@bluereference.com. 3/3/2009
One of the features that we added to the most recent release of Inference is the ability to print Expression output to the header and footer regions of Microsoft Word documents. I recently created a sample How-To Guide that illustrates dynamic header and footer output in an Inference in Word document. If you have Inference for .NET installed, you can download the How-To Guide, entitled "Header and Footer Output in Word," from Inference Online:
To print output to headers and footers:
- Create an Expression that returns a value.
- Enter a Label for the Expression – for example, MyExpression.
- In a header or footer, type the Label of the Expression (enclosed in greater than/less than brackets). Example: <MyExpression>.
When the document is executed, the bracketed Expression label placeholders will be replaced with the actual code output from the Expression.
Here are some additional tips:
- You can use the Output Result property of the Expression to specify whether the Expression gets evaluated in the Word canvas during document execution. This restricts the expression output to only the header or footer.
- You can use the Alias Code Text property of the Expression to specify whether the code, or the label, is shown in the Word canvas for an Expression. This makes the Word canvas easier to read.
- If your document includes a Data Frame, you can use an Expression to access its attributes. For example, if your DataFrame includes a title or version number, you can include that in the header/footer of your results document.
- Header/footer output will also be included in pdf results documents.
- This same functionality also works in Excel.
In the actual How-To Guide, we create two Expressions that will generate the header and footer output, and then add the placeholders into the header and footer areas of the document:
When the document is executed to a Microsoft Word View, the Expressions are evaluated, and their output replaces those placeholders in the header and footer sections:
That's pretty much it. You can download this How-To Guide from Inference Online and try it out yourself! 2/9/2009
After four months of fine-tuning and polishing, I'm pleased to announce that we have finally released the commercial version of Inference for .NET. I'd like to thank those of you who have stayed with us over the last year and provided many suggestions for to how to make Inference a better and more-useful product. That said, I want to make it clear that this is just the beginning. As a product, Inference for .NET will continue to evolve and improve as time goes forward. And again, I need your help to make this happen! If you have product suggestions or feedback, please don't hesitate to contact me at development@bluereference.com.
A one-year subscription to Inference for .NET can now be purchased from our Purchase page. Additionally, all academic users can apply for a free Academic License.
So without further ado, here's a list of what's new and what's fixed in the first commercial release of Inference for .NET:
What's New:
- IronRuby support
- Object Browser
- New Shortcut Keys
- Inputs in Excel now identify datatype on creation
- New Table DataFrame input style for Excel
- Input/Output sheets created for Parts Container Excel documents
- Expression output can be placed in headers and footers in Word and Excel
- Document Execution in Inference Studio
- HTML File support (used for HTML tables)
- SharePoint document execution
- New "How-To" samples
- Streamlined QuickStart documents
- 64-bit support
- Improved DataFrame API
- Improved document execution error handling
- Improved document execution process
- Many other usability improvements
What's Fixed:
- Significant memory leak when opening code block and expression editors
- Word drop-down menu instability fixed
- Improved installation detects running instances of Office applications, and Word as Outlook email editor (Office 2003)
- Inference Online Proxy Error resolved
- Over 100 defect fixes
2/4/2009
In his latest column for the SDTimes, Larry O'Brien (knowing.net) test drives the latest release candidate of Inference for .NET:
http://www.sdtimes.com/link/33233
Larry writes:
Inference for .NET is a tool for literate programming using .NET dynamic languages and Microsoft Office. In modern terms, literate programming is a mashup of programming and word processing (or spreadsheet processing). The presentation and formatting tools of Word or Excel can be used to explain code snippets, or the code can be unwoven from the document and executed.
Literate programming naturally appeals to writers, and with the rise of blogs and wikis, it seems like something whose time has come. On the other hand, nothing is as humbling as memorializing your shortcuts, inefficiencies and general shiftlessness on a function-by-function basis (at least such is my experience. It might be different for the talented).
We've had a lot of feedback from users regarding using Inference for .NET as a tool for literate programming – it's definitely one of the more popular uses. Literate programming clearly works best in Inference in Word, although we've had numerous requests to implement similar functionality in PowerPoint. Trust me, we're working on it. J 1/29/2009
Designing a product for reliability is a critical element of the manufacturing lifecycle. To start, one must understand the durability of a product over time or when subjected to particular strain. The following examples illustrate how survival/failure/reliability data can be analyzed and documented using the NAG Numerical C Library and Inference for .NET. The first example examines the reliability of a fiber product, measuring a braided cord’s strength under tension, while second example computes the survival curve for carbon fibers subjected to strain.
Scenario
Manufacturers face intense global competition, pressure for shorter product-life cycles, stringent cost constraints, and higher customer expectations of quality and reliability. In response to these needs, manufacturing industries have gone through a revolution in the use of statistical methods for product quality. A central element of this approach is a focus on product reliability, typically defined as “quality over time” centered on how long a component can be used until it fails.
Design for reliability requires a core understanding of anticipated and unexpected product failure modes. Important product areas include structural fibers (e.g., polymer and carbon fibers) used in chords (e.g., tire cord) and composites (e.g., carbon fiber composites). Although failure as a function of time (survival: time to failure) is commonly analyzed, failure as a function of some applied strain (survival: tension to failure) is equally appropriate. The only requirement is that this applied strain be measurable and is always a positive quantity.
Design for reliability often involves analyses where a treated or modified product is evaluated in comparison to a control group to address the following questions:
- What level of strain on average can the product tolerate before it fails?
- Does a particular treatment or modification results in higher reliability under strain?
- What are the risk factors that affect reliability under strain?
I will use Inference for .NET and the NAG C Library in two scenarios to answer these questions.
Example #1 – Survival of Braided Cord Subject to Strain
The objective of this study is to estimate the reliability of a fiber product in terms of the probability that a braided cord survives (does not break) beyond a certain level of applied strain (tension). Specifically, the CordData dataset contains measurements of 48 sections of braided cord, which were placed under increasing tension. During the course of our measurements, seven (7) of the braided cords became damaged and the corresponding measurements were stopped. This resulted in censored measurements (Censor=1) where the measurement before stopping the experiment indicated that the breaking tension is at least as large as the final measurement. By contrast, the other measurements (Censor=0) correspond to the tension that resulted in breaking the braided cord.
To get started, I opened a new Word document, added an Inference Parts Container, and imported the relevant data (labeled CordData). Subsequently, I embedded the NAG C# imports assembly of NAG C functions to the dynamic Inference document (labeled NAGwrapper):
I decided to initially generate a survival curve of the braided cord, by calculating the Kaplan – Meier estimates of the survival probabilities. This I achieved, by adding a code block and supporting code to utilize the class g12aac of the embedded .NET library, and to plot the subsequent results.
The following chart was the result of executing this Inference document.
Note that the median survival tension is estimated to be 54.8. Therefore we determine that if a braided cord is subjected to weathering, it has a 50% probability to surviving—that is, not breaking—to at least an applied tension of 54.8 MPa. The plot shows the survival curve including the 95% confidence intervals based on Greenwood’s formula.
Example #2 – Survival of a Single Carbon Fiber Subject to Strain
High-tech composites, like carbon fiber composites, exploit the qualities of fiber products to achieve strength with the least possible mass. Towards that end, we need to understand clearly the factors that affect strength and how to manipulate them to design the material response to strain. Accordingly, the objective of this study was to compare reliability of single carbon fibers subject to tension across four (4) groups corresponding to fibers of different lengths.
To achieve this goal, I first imported the representative data into the Inference document (labeled CarbonfiberData), and subsequently added two code blocks. The 1st code block contained code to utilize the NAG library g12aac method, as done for the braided cord data; however, this time the analysis was performed for the 4 groups of fiber lengths.
The 2nd code block used the g12bac function to derive a Cox proportional hazard model of the carbon fiber data. Both code blocks plotted the results using Inference graphing functions.
Using these coefficients, we can construct a "customized" survival curve for any particular carbon fiber length. More importantly, the method provides a measure of the sampling error associated with the predictor's coefficient. This lets us assess whether the carbon fiber length coefficient is significantly different from zero—that is, whether the carbon fiber length is significantly related to carbon fiber survival when subjected to tension.
Conclusion
Combining the Numerical Algorithms Group’s C Library and Inference for .NET eliminates the need for clunky reliability analysis software or inflexible add-ins. Instead, it is possible to test reliability of a product using trusted methods in a user-friendly environment like Word and Excel. And, with on-the-fly scripting via IronPython, the development process moves much faster. Best of all, anybody can easily pick up where I left off. By using Inference, all pertinent code, objects, data, and explanatory text is kept neatly in a single Word document, making it easy for other scientists to validate my methods or re-run the analysis using their own data.
12/24/2008
Visual Numerics’ computational analysis libraries offer robust, accurate, and reliable algorithms for use in science, technical, and business environments. Inference for .NET enables computational analysis libraries to be easily encapsulated in Word documents, along with high level scripting commands, data, and explanatory text. With these capabilities at hand, I can rapidly create tailored solutions aimed at solving specific data analysis problems.
In this example, I’m going to show you how I can use Inference for .NET and Visual Numerics’ IMSL C# Numerical Library to perform an analysis of manufacturing data and document the results.
The Scenario
A pharmaceutical manufacturing facility has been producing single dose tablet drug product for several years. Current measurement systems are based on storing finished material and performing offline quality tests to assure the finished product meets performance specifications.
Our manufacturing team is assigned to investigate the manufacturing process and improve its consistency (sigma capability) by using Quality by Design tools.
What is Quality by Design?
The principles of QbD in pharmaceutical development are fairly straightforward. QbD requires the achievement of two levels of understanding:
- Clinical Understanding, which establishes a link between the attributes of the drug product and safety and efficacy in humans; and
- Process Understanding, which establishes a link between the attributes of the drug product and process parameters, process attributes and material attributes of the active pharmaceutical ingredient (API) and excipients that go into the drug product.
By implementing Quality by Design practices, the pharmaceutical manufacturer can increase drug quality and safety while reducing production costs. In this step of the investigation, we use Quality-by-Design tools from the Statistical Process Control arena to establish the current state of the process based on an analysis of historical manufacturing data.
A Tailored Solution
We’ve been tasked with using process control charts to analyze a key tablet performance metric and determine whether the manufacturing process is in a state of statistical control. We’ll collaborate remotely with our team, using a regulatory compliant workflow enabled by Microsoft Office SharePoint Server, to create a dynamic Inference document.
To start, we open a new Word document and add an Inference Parts Container. The Visual Numerics IMSL C# Numerical Libraries contains a plethora of process control functions that members of our team have used successfully in past projects. So we place this .NET assembly (labeled ImslCL) into the Word document. Then, team members import manufacturing data (labeled ManufacturingData) from an Excel spreadsheet: 
The first question we need to answer is, "What is the problem with the Manufacturing Process." To address this we decide to generate a Shewart Control Chart by adding a code block and supporting IronPython code to utilize the class ShewhartControlChart of the embedded .NET library:
At this point, we’ve successfully created a dynamic Inference document that can be executed to create an Inference results document, producing the Shewhart Control Chart for analysis:
This chart shows us that 14 out of 90 batches failed to meet the 60-minute dissolution requirement. Now, we present these findings to our team as an Inference results document, concluding that even though the manufacturing process was not on target for process capability, the spread was small enough (within 3 sigmas) to indicate a process under statistical control.
Other members of our team perform further analysis in our dynamic Inference document using additional functions called from the VNI IMSL C# Numerical Libraries. Upon reviewing their results, our team determines that the manufacturer’s objective in development should be to move the process capability distribution toward the center while maintaining the same spread.
12/5/2008
A little over a week ago, Microsoft released version 0.9 of the DLR:
This release includes synchronized compiled binaries for IronPython and IronRuby. I found this release particularly fortuitous, as I had just begun to work on adding IronRuby as an available scripting platform within Inference for .NET. Thanks to the hosting infrastructure of the DLR scripting framework, I was able to add IronRuby support in no time. IronRuby is still currently at Alpha 3 release, and while it has a few expected quirks, the implementation is incredibly functional. Here's a quick screenshot of IronRuby code in Inference:
Incidentally, this screenshot also illustrates the new Object Browser that lists what variables are created by Inference during runtime so that you can use them in your code...yeah, don't worry, we'll cover that later. :)
Both IronRuby support and the new Object Browser will be available in the forthcoming commercial release of Inference for .NET, due in early February 2009.
10/31/2008
So far, the most often requested features we’ve had for Inference for .NET are usability enhancements, specifically things like keyboard shortcuts, etc. Users want to be able build documents more quickly using just the keyboard. To accomplish this, we added keyboard shortcut functionality into the latest release candidate of Inference for .NET.
Word/Excel Shortcuts
While in Word and Excel, you can use the following keyboard shortcuts combinations:
- CTRL-ALT-F4: Insert a new Code Block
- CTRL-ALT-F5: Insert and Edit a new Code Block
- CTRL-ALT-F6: Insert a new Expression
- CTRL-ALT-F7: Insert and Edit a new Expression
- CTRL-ALT-F8: Edit the selected code item (Code Block or Expression)
- CTRL-ALT-F9: Edit the Parts Container in Inference Studio
- CTRL-ALT-F10: Export to Word/Excel View
- CTRL-ALT-F11: Export to Webpage View
- CTRL-ALT-F12: Export to PDF View (Note: This only works with Office 2007, and if you have installed the Export to PDF or XPS add-in for Office 2007)
Code Editor Shortcuts
While in the Code Editor, you can use the following keyboard shortcut combinations:
- CTRL-ALT-ENTER: Close the Code Editor window; this is the same as clicking the OK button
- CTRL-TAB: This moves the tabstop to the next control; this is useful for tabbing out of the code editor, and then allows you to tab around the form
- CTRL-A: This selects all the text inside of the Code Editor.
Please leave me a comment if there are any keyboard shortcuts you think we missed! 10/28/2008
Continuing in my series of “I’m serious – Inference is useful!” blog postings, yesterday I put together an example of how you can document process modeling using Inference and some additional numerical libraries. In this example, I used the MtxVec Numerical Library collection provided by Dew Research. The particular example I documented was an experimental study from the National Institute of Standards and Technology (NIST) involving the thermal expansion of copper.
What is process modeling?
Process modeling entails using computational methods to describe, represent and simulate the functioning of real-world scientific and engineering processes. Computer modeling represents a complementary method to laboratory. The purposes of modeling include:
- analysis and understanding of observed phenomena;
- testing hypothesis and theories;
- predicting process outputs under conditions which are too difficult or too expensive to measure directly;
- calibration of measurement systems; and
- process optimization.
Process modeling describes the variation in one observed quantity (response) as a function of a deterministic component, typically a mathematical function of one or more quantities (factors), and a random component (noise), typically described by a probability distribution. For example, the variation in the measured expansion of a metal like copper can be described by partitioning the variability into a deterministic part, which is a function of temperature, and some left-over random error.
How does one build process models?
Process models are built by fitting experimental data to mathematical functions. Linear least squares regression is the most widely used modeling method. When people talk of using "regression", "linear regression" or "least squares," they are fitting their data to empirical models.
Nonlinear least squares regression extends linear least squares regression for use with a much larger and more general class of empirical models. Almost any closed form mathematical function can be incorporated in a nonlinear regression model. And, unlike linear regression, there are very few limitations on the way parameters can be used in the functional part of a nonlinear regression model.
Polynomial models are among the most frequently used empirical models for fitting functions. A rational function model is a generalization of the polynomial model. Rational function models contain polynomial models as a subset. For example, the function below is a quadratic/quadratic rational function model that can be used to describe the coefficient of thermal expansion of copper metal as a function of temperature,
where Y corresponds to the coefficient of thermal expansion, X corresponds to the temperature in degrees Kelvin, and B4 corresponds to estimated parameters obtained by nonlinear least squares. Nonlinear least squares parameter estimation is in iterative method which employs estimated starting values.
The data
The data result from a National Institute of Standards and Technology (NIST) experimental study involving the thermal expansion of copper. The response variable is the coefficient of thermal expansion, and the predictor variable is temperature in degrees. Let us look at the data in a simple plot.
The plot exhibits a steep initial slope that levels off to a more gradual slope. This type of response curve can often be modeled with a rational function model, like the quadratic/quadratic rational function model described earlier. The plot further indicates that there appear to be no gross outliers in the data.
Fitting the data using Dew Research MtxVec Numerical Libraries
Fitting the thermal expansion data to the quadratic/quadratic function model requires non-linear fitting. This involves a three-step process: (1) define the fit function, (2) obtain initial estimates of the beta coefficients, and (3) iterate the beta coefficients using the optimization method used in nonlinear regression. With a great deal of time and effort, one could write code that implemented and executed the algorithms of this three-step process. But there is a much easier way. Using specialized numerical libraries like those supplied by Dew Research in the Inference for .NET environment allows for rapid development and deployment of the solution using some simple IronPython glue code.
Using IronPython, we can define the quadratic-quadratic rational function to which the data will be fit. Next, we need initial estimates for the regression coefficients. As suggested at NIST pages, we'll use linear fit on selected points to get initial estimates for regression coefficients. For this we can use the MulLinRegress routine available in the MtxVec library, and then define a function to perform an initial estimate on fractional model by performing a linear fit:
Perform non-linear least squares fit
Now all we must do is put all this together and perform the non-linear fit. Towards this end, we willl use Dew Stats tMtxNonLinReg control. The call to FitModel() routine first loads data, then performs initial estimation of regression coefficients and then uses initial estimates in actual non-linear regression:
Plot the fit on top of the data
Now let take a look at the results. We create a plot that compares the experimental thermal coefficient values (symbols) with the corresponding calculated values (line) based on the non-linear fit.
Conclusion
We conclude that the quadratic/quadratic rational function model does in fact provide a reasonable empirical model for this data set. Further evaluation would reveal that a cubic/cubic rational function model does even a bit better.
10/23/2008
We finished running the last set of regression tests on Inference today, and I’m pleased to report that we’ve now shipped Release Candidate 6 of Inference for .NET. The focus of this final release candidate was to improve usability and to streamline the Getting Started process for users. Wait, did I use the phrase “final release candidate”? Yes, it’s true…RC6 represents the last release candidate of Inference for .NET. Towards that end, we’ve increased the trial time. RC6 will last for 120 days from installation (up from 60 days). For those of you exceptionally gifted in math (not me!), you will note that this means we will have the final release of Inference for .NET in early February 2009.
The response so far for Inference for .NET has been fantastic; please keep the feedback coming!
Regarding what’s new in Inference for .NET RC6, I’ll be covering some of the new features in upcoming blog postings, but here’s the overview.
New Features:
- Insert and Edit menu item for Code Blocks and Expressions
- Keyboard Shortcuts for common code editing, parts container, and export functions
- Streamlined Getting Started workflow (no more Getting Started Wizard)
- Updated and expanded Getting Started documentation
- Direct editing of Expression code in Outputs section of Inference in Excel
- Streamlined download of Sample Documents in Inference Online
- Configuration of Scripting Platforms is no longer required
Important Bug Fixes:
- Improved whitespace formatting for results document output
- Missing code editor textbox for Expression Editor fixed
- 36 other minor bug fixes
You can download the new RC6 release here. |
|
|
|
|
|
|
|
| |
|
© 2008 Blue Reference, Inc.
All rights reserved. | 3052 NW Merchant Way, Suite 100, Bend, Oregon 97701 | 541-316-2343 |
Terms of Use
 |
|
 |
|
|
|
|