I'm looking to find out a little more about the automated generation of decision trees using SAS Enterprise Miner.
I'm looking to find out what types of decisions were made and basically the meaning of the example decision tree and each of its components.
If anyone might have some helpful info on this, It would be great to hear it.
Related
I would like to develop a decision support system for diagnosis disease. I am newbie for the programming. Can anyone suggest which programming language is most suitable?
That really depends on what you want to do exactly (do you want to use prebuilt libraries?).
I see you added weka as a tag. Java is a good option, since it's so versatile, powerful, fast and fairly easy to use, implementable as a web service, plus you can use the weka library for quickly building trees.
But really, any other programming language (C++, python, matlab) will have the power to build a tree.
You have to design a decision mathematical model. In order to do that, you need a back ground in statistic, data mining or even fuzzy logic.
And then, you code the decision making algorithm to get the final results. I suggest you should have a validation phase to ensure your program is useful and correct.
I'm architecturing a Multi Agent System (MAS) framework to describe Beliefs-Desires-Intents (BDI) agents in Haskell (i.e. agents are concurrent, communicating monadic actions).
I searched on the web throughly but I wasn't able to find any reference on similar works, apart from a technical report of an unfinished work, Specifying and Controlling Agents in Haskell.
Do you know about any existing implementation or research paper dealing with BDI agents that can be defined in Haskell or in any other functional language, please?
My aim is to find possible related works, everything that could manage a system of concurrent intelligent agents written in a functional language. I don't need anything specific, I just want to find out whether my work has something in common with existing approaches.
edit: I managed to find a reference to Clojure, a lisp dialect that supports a form of agent programming very close to the actor model, but it's not meant to directly support BDI agents (one should implement another layer on top of it to get the BDI part done I guess).
To sum up, it doesn't seem like there are proposals for BDI-style communicating agents described by means of functional languages, so together with a friend/colleague of mine we collected info about related work, put together some ideas, and we wrote a short position paper that I will present at the DALT2012 workshop. It's a really preliminary work, so do not expect too much from it, but I think in the future it may evolve in something interesting.
Alessandro Solimando, Riccardo Traverso. Designing and Implementing a Framework for BDI-style Communicating Agents in Haskell. DALT 2012, Workshop notes, pages 108--112.
EDIT:
I later found this project on GitHub, which uses free monads (whatever that means, I don't know about them) to provide a framework for multi-agent systems: https://github.com/fizruk/free-agent.
I have seen UML mentioned several places in the last few years, but never had a compelling reason to use it at work so far. Is there any value in putting the time and effort to learn it? (I am a Ruby on Rails developer.)
Edit: I'm also looking for stories about how UML has made a difference in your projects to give me an idea of how I might use it.
Yes. It is the international standard methodology for systems analysis and design. When moving from the initial analysis phase through the project life-cycle, the UML gives a good road-map on where to go and how you got there. A few benefits:
It shows requirements in a way that clients / customers / management can understand.
You can iterate the model and not lose track of where the model was before
Shows exactly how you got from point A to point B
It's a standard, so anyone who knows UML will be able to interpret your diagrams
The "quickest" way to share ideas without needing to go through the entire code-base
No, save your time and don't learn it. If you are a coder and work alone and are a very careful person, you can completely ignore UML.
But, if you work with other people and want to share the result of your work, UML is a Unified language, a lingua franca that even non technical customers understand (at a certain level).
Yes and no.
Yes, learn the basics. Have a quick look at at the different diagram types etc. and have a general idea. That will help you eliminate your hesitance when someone boasts about UML.
No, if your work doesn't require to work with UML, you don't necessarily need to know UML to write good applications. If you need to discuss something on a white board just draw a few circles. That'll do.
It only helped me to produce documentation to management to impress them a little. Other than that I only find the deployment diagrams somewhat useful, that's all.
If you look at UML as a merely graphical language you consider just a very small part of it. You should instead look at UML as the primary language of the Model Driven Architecture framework which is very well implemented in Eclipse.
In Eclipse UML is (correctly) considered as a Platform Independent language with a solid syntax defined by the MOF (ECORE in Eclipse) and semantics defined by the UML specification (http://www.omg.org/spec/UML).
In Eclipse there are good implementation of the two main languages defined by the OMG for Model To Text and Model to Model transformation specifications which are respectively MOFM2T (ACCELEO in Eclipse) and QVT.
Also Eclipse provides an implementation of the Object Constraint Language (OCL) which is used by both QVT and MOFM2T to evaluate queries on models.
All this means you can easily define your own Model to Text and Model to Model transformations , in the form of Eclipse plugin, turning your UML models into whatever you need.
Now I use that to automatically generate thousands of LOC, documentation and tests with an impressive return on investment.
However I know the majority of people doesn't even know UML is a language but think it is just about tiny pictures.
Look at this links for some simple example
http://lowcoupling.com/post/46522537374/the-model-driven-architecture
http://lowcoupling.com/post/47800863669/qvt-in-place-transformations
http://lowcoupling.com/post/47347056110/models-to-text-transformations-with-mofm2t-and-acceleo
I think it's a question of scale in two dimensions: size of problem and size of team.
When a design gets to a certain size diagrams become useful in two ways: first, they help you reason about design issues. second they help you communciate the design to other poeople.
So if the team is say 20 or 30 it really does help to have some clear documentation of pieces of the overall design.
Personally I use UML maybe four or five times a year, but when I need it, I really need it. It really is better to ase a standard diagramming technique that devise your own. And with good tools it's pretty painless.
I would say that I use only a small subset of UML, class diagrams and occasional collaboration diagrams.
What are the best modeling languages to know. What are the most important things to know about the modeling languages. Espically BPMN as it seems like an interesting topic.
I think BPMN may have some use in companies that have very formal approach to writing specifications, the same kind that would use UML for describing every aspect of simple cancel button. Majority of developers heard only of UML and even that is not really well understood, nor employed extensively in practice.
As usual, the really important questions you want to ask are:
What do you want to model?
Who are you writing this for?
If you are doing this for yourself, you may just as well use your own notation made up ad hoc. It will be faster than going through pages of spec written by experts from OMG (Object Management Group, though Oh My God is not a bad explanation either ;-)).
If you need to share the doc with others, UML seems like a good choice. It is sort of understood by the community and all ambiguity you can always rewrite in plain English.
If your client requires BPMN, then well -- read on it and learn it well. Maybe hire consultants to verify if you are doing it right. If you are not required by contract to use it, then -- for Gods sake -- go write code and document it well and not spend too much time pondering which modeling thingy is most hip now. None isn't and none will be any time soon.
IF you are involved in a ERP implementation, getting the business processes right upfront can save you a lot of trouble down the road.
Organisations know surprisingly little about their inner workings and it's the ERP developers that get the beating when their software doesn't fit to the company. If you can soften that clash of cultures by doing a bit of proper analysis before the development phase, then you are doing the right thing.
BPMN is really one of the easiest and most simple methods there is for the job. Making up your own way of describing Business processes is just reinventing the wheel. Check out some of the free tools on the market; BizAgi for instance.
Good luck.
I'm looking into a way to build a system that will help our sales team spec a product.
The ideal system would ask some base questions which is common amongst all products. Further questions would then branch from these answers. From what I can figure this is essentially a big decision tree/expert system I've been asked to build.
I wondered if anyone has had experience in building such a system and can provide some reference or can recommend a framework/software to support such a system?
You could use the answers to questions as values of attributes and then build a decision tree based on these attributes to classify the products. Is this the sort of situation your in?
If so, what are you looking for? Algorithms? Take a look at things like ID3, it is a decision tree algorithm which could work for a situation like yours. I'm not familiar with any specific frameworks/software for decision trees. Let me know if there is any more details you can give about what sort of help you need.