http://digital.ni.com/public.nsf/allkb/9B99C4C98952F38486256298005A236D
Field Wiring and Noise Considerations for Analog Signals
http://www.ni.com/white-paper/3344/en
Wednesday, November 14, 2012
Thermocouples Vs. Thermistors (Temperature Measurement)
http://www.veriteq.com/validation/thermocouples-vs-thermistors.htm
Measuring Temperature: Managing Errors & Calibration:
Signal Errors & Noise
Measuring Temperature: Managing Errors & Calibration:
Signal Errors & Noise
Monday, November 12, 2012
assert() Function Example Program in C
http://www.java-samples.com/showtutorial.php?tutorialid=595
The macro assert() can diagnose program bugs. It is defined in ASSERT.H, and its prototype is
The argument expression can be anything you want to test-a variable or any C expression. If expression evaluates to TRUE, assert() does nothing. If expression evaluate to FALSE, assert() displays an error message on stderr and aborts program execution.
How do you use assert()? It is most frequently used to track down program bugs (which are distinct from compilation errors). A bug doesn't prevent a program from compiling, but it causes it to give incorrect results or to run improperly (locking up, for example).
Analysis:
The action of assert() depends on another macro named NDEBUG (which stands for "no debugging"). If the macro NDEBUG isn't defined (the default), assert() is active. If NDEBUG is defined, assert() is turned off and has no effect. If you placed assert() in various program locations to help with debugging and then solved the problem, you can define NDEBUG to turn assert() off. This is much easier than going through the program and removing the assert() statements (only to discover later that you want to use them again). To define the macro NDEBUG, use the #define directive. You can demonstrate this by adding the line
#define NDEBUG
Note that NDEBUG doesn't need to be defined as anything in particular, as long as it's included in a #define directive.
The macro assert() can diagnose program bugs. It is defined in ASSERT.H, and its prototype is
The argument expression can be anything you want to test-a variable or any C expression. If expression evaluates to TRUE, assert() does nothing. If expression evaluate to FALSE, assert() displays an error message on stderr and aborts program execution.
How do you use assert()? It is most frequently used to track down program bugs (which are distinct from compilation errors). A bug doesn't prevent a program from compiling, but it causes it to give incorrect results or to run improperly (locking up, for example).
Analysis:
The action of assert() depends on another macro named NDEBUG (which stands for "no debugging"). If the macro NDEBUG isn't defined (the default), assert() is active. If NDEBUG is defined, assert() is turned off and has no effect. If you placed assert() in various program locations to help with debugging and then solved the problem, you can define NDEBUG to turn assert() off. This is much easier than going through the program and removing the assert() statements (only to discover later that you want to use them again). To define the macro NDEBUG, use the #define directive. You can demonstrate this by adding the line
#define NDEBUG
Note that NDEBUG doesn't need to be defined as anything in particular, as long as it's included in a #define directive.
Sunday, November 11, 2012
SPMD
We compiled a single program -- we didn't compile a different program for each process-- and we did this in spite of the fact that process 0 is doing something fundamentally different from the other process. This is quite common in parallel programming. In fact, most MPI programs are written in this way. That is, single program is written so that different processes carry out different actions, and this is achieved by simply having the processes branch on the basis of their process rank. (SPMD) Single Program multiple data.
--An introduction to Parallel Programming,
Peter S. Pacheco
University of San Francisco
--An introduction to Parallel Programming,
Peter S. Pacheco
University of San Francisco
Monday, November 5, 2012
Extreme programming
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.
Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.[2][3][4] The method takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if a little is good, more is better.[clarification needed]
------Wiki
Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.[2][3][4] The method takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if a little is good, more is better.[clarification needed]
------Wiki
Thursday, November 1, 2012
Ubuntu 12.04 cannot login, bounces back to login splash
Press CTRL+ALT+F1 and log in there and run:
sudo chown -R $USER:$USER $HOME
Then press CTRL+ALT+F7 and try to log in
Subscribe to:
Posts (Atom)