free download matlab code for feature extraction for breast cancer
#1

Hi i am ujjwal i would like to get details on free download matlab code for feature extraction for breast cancer ..My friend rawin said free download matlab code for feature extraction for breast cancer will be available here and now i am living at kathmandu and i last studied in the college/school(tribhuvan University) and now am doing Mammogram breast image segmentation using knn and expectation algorithms and also classify using neural network i need help in terms of matlab code for feature extraction.
Reply
#2

Creating a multi-rate model

Normally when creating a simple model in Simulink you don't worry about sample periods - there is an abstract notion and you simulate for a number of periods (specified in the Simulation->Parameters... form). However, if you are about to create a controller rather than a model of a system to control, you often end up in a situation where some parts of the controller should execute more often than other parts. Further more, you will probably want some control over what the actual sampling rate will be - but we'll get back to that in the next section.
As it turnes out, many blocks have a "sampling rate" parameter with a default value of -1, indicating that it should inherit the sampling rate from blocks it depends upon. Other legal values in this field are work space variable names (often a variable called Ts) or a vector [Ts, 0.5] where the first part specifies the sampling/execution rate and the second specifies an offset from the start of each such sample time. It is often enough to specify specific sampling rates at in a few boxes in the beginning of the modell/controller, and let the rest inherit these values.

As soon as you have some blocks with a specific samplig period greater than 1, your system is a multi rated system. You have to manually preserve consistency when feeding signals from a faster executing part of your model to a slower part (using zero order hold blocks) and vice versa (using unit delay blocks). For details, see the Real-Time Workshop manual, chapter 7, (especially pages 11 to 16).

The Simulink manual states the following about mixed continous and descrete systems:

Mixed descrete and continous systems are composed of both sampled and continous blocks. Such systems can be simulated using any of the integration methods, although certain methods can be more efficient and accurate than others. For most mixed discrete and continous systems, the Runge-Kutta variable step methods rk23 and rk45, are superior to the other methods in terms of efficiency and accuracy. Due to the discontinuities associated with the sample and hold of the discrete blocks, the function gear and adams are not recommended for mixed continous and discrete systems.
Preparing the model for stand-alone execution on the "rt_unix" target

The code generated using Real-Time Workshop does different things depending on targets. If you generate code to a non real-time system the code will simply execute as fast as possible (no notion of real sampling time). These targets are Unix machines, PC's runing various WindowsXX systems etc. But, when generating code to a specific real-time system such as VxWorks or to a DSP (and also to a naked DOS machine) the generated program will be driven by an external clock interrupt - and one such interrupt corresponds to one "sample time" in your modell.
When your model is about to execute stand-alone, you can not use any of the nice graphical sources and sinks that is normally used to view the result of a simulation. Instead, you must save your data in one or several work space variables (using the block "To Workspace"). Here is an example:


This is a simple, discrete, multi-rate model containing two loops that increases the value of a signal by one in each iteration. In order to save the data we must construct a time reference, and store the data in a workspace variable. The Zero-Order-Hold's sets the pace to every 5:th and 20:th sample respecivly, and the Unit-Delay (with the same value on its sample parameter) guaranties the consistency when mux:ed with a signal fom the clock.

The solver parameters are then set to operat for a fixed period of 100 samples with a fixed step size of 1, and we use the discrete mode:


The simulation will halt after a short while. In order to view the result, we must now create another model :


When running this model with the same solver parameters, we will get the following scope image (which is identical to the one we would get if the scope where placed in the original model):


Generating and compiling a model program

You will use the RTW part of the parameter dialog window to specify the target. There is a directory named $MATLABROOT/rtw/c/ which contains one directory for each target. At IDA this directory contains the following:
dos/ grt/ libsrc/ rt_unix/ src/ tlc/ tornado/
The libsrc, src and tlc directories contains code or templates for code to be generated. The directories dos, grt, rt_unix and tornado contains interface code to the corresponding operating system, templates for makefiles and other target specific stuff. The default is to generate towards the general real time target (grt), which will result in a stand-alone program that runs the simulation as fast as possible. Using the rt_unix target will result in a multi-threaded program that executes according to a real-time clock -- and depending on the previlegies of that program it may even use the SunOS Real-Time scheduling class. To achieve this, you must specify the following:




When this is done, hit the "Build" button. The result will be a trace of the activities:
>>
### Starting RTW build procedure for model: multirate
### Invoking Target Language Compiler on multirate.rtw
### Loading TMW TLC function libraries
### Initial pass through model to cache user defined code
### Creating source file multirate.c
### Creating part 1 of registration file multirate.reg
### Creating parameter file multirate.prm
### Creating model header file multirate.h
### Creating part 2 of registration file multirate.reg
### TLC code generation complete.
### multirate.mk which is generated from
/sw/matlab-5.1/rtw/c/rt_unix/rt_unix.tmf is up to date
### Building multirate: make -f multirate.mk
cc -c -g -DMULTITASKING -D_SVID_GETTOD -D_REENTRANT -DMODEL=multirate -DRT
-DNUMST=4 -DTID01EQ=1 -DNCSTATES=0 -I. -I/sw/matlab-5.1/simulink/include
-I/sw/matlab-5.1/extern/include -I/sw/matlab-5.1/rtw/c/src
-I/sw/matlab-5.1/rtw/c/libsrc multirate.c
cc -D_REENTRANT -o multirate multirate.o rt_main.o rt_sim.o rtwlog.o
thread.o rtwlib.a -lm -lthread
### Created executable: multirate
### Successful completion of RTW build procedure for model: multirate
>>
You now have a program called multirate in your directory. You start it by typing (at the matlab prompt):
>> ! multirate 1000

Simulation Finished
Created multirate.mat
Saving thread logg...
Wrote thread logg on threads.log
>>
There will be slightly more trace print out than shown above when you run the program, but we postpone the explanation of the to the next section. At this point you can load the result back into matlab with the command:
>> load multirate.mat
Then you view the result as specified previously but with all workspace variables prefixed with "rt_" !!
Pittfalls when generating multi-threaded code:

You can't specify a sampling rate in the "To Workspace" block, let it inherit the value.
Memory boxes must inherit sampling rate (a special check button to press)
You must have a multi-rate model, or matlab will generate single threaded code - and that is not supported yet on the rt_unix target.

True real-time execution and how to view execution statistics

When generating code for our rt_unix taget, the purpose is to study the scheduling and execution of threads rather than actually executing a real-time program to control something. The program will therefore provide some alternative features and print out extra trace information. The complete set of parameters to the program is the following:
modelname time [schedulingpolicy]
where modelname is the name of your model and also the name of the executable and time is an integer or real for how many milliseconds the model should execute (translates into a number of iterations according to specified sampling rate in your model). Parameter schedulingpolicy describes how the Unix system should execute your program, and valid arguments are one of TS, RMS or EDF. If you start the program from the matlab prompt, remeber to prefix it with ! to actually run it in a shell below matlab. The following is an example of printout when starting from within matlab with schedulingpolicy RMS:


>> !robot_stud 5000 RMS
Initiate semaphore RT-Clock...
Enetring prioIo_init: Class=IA, Prio=0 (0)
setup for scheduling class `RT'
Exiting prioIo_init: Class=RT, Prio=4 (59)
Registered RTClock, add processes...
Tasks started.
Sample rate set to 5ms (system granularity:10.0 ms)
Scheduling data for pid 15771, lwp 1: Class=RT, Prio=4 (Max: 59)
Scheduling data for pid 15771, lwp 4: Class=RT, Prio=2 (Max: 59)
Scheduling data for pid 15771, lwp 6: Class=RT, Prio=3 (Max: 59)
Scheduling data for pid 15771, lwp 5: Class=RT, Prio=1 (Max: 59)
tBaseRate - freq. 2 has OVERRUN!

Execution finished
Created robot_stud.mat
Saving thread logg...
Wrote thread logg on threads.log
Before we explain the trace, a short explanation of the SunOS scheduling classes is needed. In order to accomodate the needs of as many different applications as possible, the SunOS is capable of executing different programs according to different scheduling principles, not only different priorities. It is also possible to write a new scheduler and dynamically load it into the kernal if the need should arise. Currently, the following SunOS scheduling classes exist:

TS - traditional time-sharing. Normal users have a priority (or "nice-level") between 0 and some negative, system dependant number (-60 on SunOS). If you are the super-user you may "nice-up" your program above 0 (max +60). The actual priority of a program running in this class is gradually lowered as the program executes, and is reset to original value a while after it has been pre-empted. The actual values of how soon and fast the priority is lowered depends on the nice value, among other things.
IA - interactive class. This is a variant of time-sharing where the window system raises the nice-level automatically when the mouse is over the controlling terminal for the program. This results in faster response for interactive applications, and is what most normal programs use.
SY - system scheduling. This is a special class for special system software, and it is not possible to make other programs run in that class.
RT - real-time class. Programs executing in this class are strictly executed according to priority - the highest prioritized program will execute until it decides to hang on a semaphore or other synchronisation object. When a high prioritized process in the RT class becomes runnable it will imediately be scheduled and preempt all other activities. If we construct an infinite loop we will hang the entire machine, and you will have to use the "power-off" method to get out of the situation!
When we execute a matlab model without scheduling policy argument the model will be run with different negative nice values for the different threads in the model. If the argument TS is supplied, the model will be executed with different positive nice vlaues, resulting in somewhat better performance than the first alternative. If RMS is supplied, all threads in the program will be scheduled in the RT class, with priorities assigned according to the RMS principle. In future versions we might consider implementing EDF, or to leave that as an exercise.
Now, looking back at the print out above, we can notice the following: The first thing the program does is to change scheduling class to RT and rise its own priority to 4. Then it register an interrupt handler to catch SIGALRM signals from the kernal, it spawns threads (or lwp - light-weight processes in SunOS terminology) needed for the matlab model and instructs the system to send SIGALRM signals every 5:th millisecond. However, the system resolusion is 10ms and this is the fastest rate at which alarms can be sent. The matlab code will actually execute at 50% "slow-motion". At this point the main program will rest, waiting for an exit semaphore to be signalled upon by any thread that think it is time to halt. The matlab threads spawned erlier are now free to start, and the first thing they do is to print out diagnostics about their scheduling class and priority. A short period into the execution it is discovered that one of the threads has overrun its period. Hence, the program terminates and the collected log records are saved to a file. See separate documentation describing the target interface layer for details about this.

To view the saved log and study which thread executed when, use the program logTool. At the matlab prompt you type:

>> !logTool &

You will soon get a window with the following appearance:


[Picture of logTool]
Use the magnifying glass in the overview section of the tool to select the aproperiate part of the log. Thicker lines in the magnified part shows threads that are active, and a vertical line at the rightmost end of a thick line shows that the thread has put itself asleep by waiting for a semaphore, as opposed to have been interrupted by another thread (e.g., see thread tRate1 which is interrupted by the second activation of RTClock - the signal handler receiving SIGALRMs from the kernal - and tBaseRate) and resumed later on. If a thick line representing an activation is marked with mouse button 1, the log records registered for this activation is presented in the text area. Each log record contains the following information:

the name of the thread
time in milliseconds from the start of the program (real time, not cpu time)
a count of how many times this thread has volentarily put itself asleep (vctx) by waiting for a semaphore or alike, and another count of how many times the OS has preempted the thread (ictx). You will notice that the ictx counter may change value when the program has been executed in time sharing mode since a program other than the threads within the logged matlab program has preemted the thread.
the name of the log event, where RUNNING is a special event registering a precise measurement of how long it took to execute the actual matlab code - this is the only method of separating model specific execution time from loging and other overhead.
a comment field with (hopefully) explanatory strings...

More refrence :http://ida.liu.se/~m_reap/ROBOT/multirate.html
Reply

Important Note..!

If you are not satisfied with above reply ,..Please

ASK HERE

So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: breast cancer image processing ppt, breast cancer expert system pdf, the grt popa, seminar on breast cancer by image processing, breast cancer and immage processing, matlab code of classification breast cancer using, classification of breast cancer using matlab,

[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  salaam chaus superfast english book pdf free download 2 26,189 30-06-2019, 09:27 PM
Last Post: Sharad7shakky
  engineering mathematics 2 by dr ksc pdf free download 2 6,172 21-02-2019, 01:00 PM
Last Post:
  matlab code 1 3,438 31-01-2019, 02:52 PM
Last Post: [email protected]
  free download ksc m3 textbook vtu 1 2,985 11-12-2018, 10:50 PM
Last Post:
  free download college alumni php project 1 2,617 29-11-2018, 08:33 PM
Last Post:
  computer aided design vijayaraghavan book free download 2 10,004 27-11-2018, 04:49 PM
Last Post:
  special electrical machines by dhayalini pdf free download 1 3,141 16-11-2018, 08:38 AM
Last Post:
  underwater optical communication matlab code 0 3,291 02-11-2018, 07:32 PM
Last Post: Guest
  ns2 source codes free download for hello flood attack 0 2,824 31-10-2018, 02:42 PM
Last Post: Guest
  cs6503 theory of computation book free download pdf 0 11,572 28-10-2018, 05:29 PM
Last Post: Guest

Forum Jump: