I'm working on an Evolutionary Algorithms framework, but I've hit a bit of confusion when it comes to the random selection method used within Ranked Selection; should I be using the same method used in Roulette Wheel Selection (i.e. selecting each solution independently), or should I use the same method used in Stochastic Universal Sampling (i.e. selecting all solutions simultaneously). I know the latter would probably be better, but I don't want to implement it this way if it's not standard practice.
Thanks in advance!
Since every time people address Rank Selection they talk about Roulette Wheel, and SUS works with probabilities itself, and with a reference to this answer it seems you should select like Roulette Wheel.
Related
I found some information about this but I have several confusion regarding this. So when we need to use this RX.NET.
What are the important of using this items? When I need to use this?
As with every toolset, it can shape how you approach problems. Given a hammer, all your problems may become nails. It is the same with Rx.NET. It gives you a new approach. Whether you choose to use this approach for a particular problem is up to you, and as with any tool or technology, there are plusses and minuses. You will need to study and gain experience to make those sort of complex judgements for yourself.
For starters, Rx.NET allows you to cultivate the approach of programming 'reactively.' This is akin to functional programming, in the sense that you declare behavour as being composed of underlying behavior. Rx.NET allows you to specify functions over streams to give new streams. This powerful technique can be applied to almost any problem you can imagine.
For example, a program using Linq and Rx.NET to draw mouse movements as points on a screen within a bounding box would like something like:
mouseMovements.Where(box.Contains(m)).Subscribe(DrawPoint)
where mouseMovements would be your mouse event as an observable
You could declare the
myPointsInBox = mouseMovements.Where(box.Contains(m))
as its own observable and have multiple subscribers:
myPointsInBox.Subscribe(DrawPoint)
myPointsInBox.Subscribe(ConnectWithLines)
myPointsInBox.Subscribe(UpdatePointCounter)
you can make streams from streams
var everyThousandthPoint= myPointsInBox.Buffer(….).Select(…)
and then do things with them
everyThousandthPoint.Subscribe(FlashPointCounter)
You get the idea.
I'm currently writing a basic platformer game with the idea of learning the basis patterns of a 2D game development. One of them is the amazing A Star Pathfinding. After reading and study a few articles (two of them are the best: Link and http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html#S7), tutorials and source code, I did a simple A Star Pathfinding using the Manhattan method that works well for my personal learning process.
The next, and logical step, is to do the same on a platform scenario where the NPC must jump or climb ladders to reach the goal target. I've found these screencastings http://www.youtube.com/watch?v=W2xoJfT6sek and https://www.youtube.com/watch?v=Bc7tu-KwfoU that show perfectly what I want to do.
I haven't found for the moment any resource that explains the method to implement it. Can someone give me a starting point I can work with?
Thanks in advance
As far as I can tell, the only difference that jumping/ladders make is that they affect possible movement. So, all your algorithm has to do is take into account where a character can and can't move to, and the costs (if you're implementing that) of moving there.
I haven't any clean A* code around fit for an example but let me give you a few pointers when implementing A*.
First off, the most essential tip that I often find neglected in tutorials is use a priority queue.
Whenever you generate possible move states, put them into the priority queue with priority being the value of your heuristic for that move state. This differentiates A* from DFS (which uses a stack and backtracking) or simple greedy path finding (which simply goes to the best state with respect to the present state).
Next, mind those pointers! I don't know what language will you implement this but even if you do it in some language that abstracts pointers (unlike C), you have to understand the concept of a deep copy versus a plain shallow copy. I remember the first time I did A* (in Python) and I did not pay attention to this. My states were repeatedly overwritten leading to unpredictable behavior. Turns out I did not make deep copies!
That said, depending on how complex the task you have in mind, all those deep copies might clutter up your memory. While good memory management will help, for big problem instances that need real-world performance, I tend to just use iterative-deepening A* so that after every iteration, I get to unclutter my memory.
Let's say I'm making an Use Case for a game that has a scoring system. Each action you do in the game will increase/decrease your score in the game.
Here is a sketch of my Use Case:
1. ...
2. ...
...
8. The Player makes (some move).
9. The System registers the play and calculates his new score.
There is some algorithm behind calculating this new score. Should I state it in this Use Case? Should I state it in another Use Case? Should I simply omit the details of implementation of the algorithm?
Is the Use Case the correct place to state those kinds of things? Or should the Use Case just be concerned with the interactions between the Player and the System(the Game)?
I'd say I'd probably want to write down those details somewhere (if not just to make sure I really do understand them). So it looks to me maybe the best option is to make another Use Case where I describe how they work?
How are generally these kind of things done with Use Cases? Thanks
Algorithms are not interaction between user and system to create something of value.
They're a footnote or an appendix to the use case.
They're often important, but they're not interaction. Hence putting them in an appendix.
Also. All use cases are initiated by the Actor. They actor wants to play they game; they initiate things. The system generally can't initiate action -- it's passive, responding to the actor.
Algorithms don't belong in use cases. Extract them to a business rules section or document.
I suggest you to use Activity Diagram to represent algorithms and leave your Use Case steps simple in this case.
I also agree with "Johann Strydom" in his position.
Leo
We'll soon have some high school kids here in our company for some training lessons in programming for about 1 1/2 days.
We decided to do Visual Basic.NET and thought about programming a little calculator with the four basic operators.
Considering the fact that they will be here for only 1 1/2 days, this application might be "too" complex to be taught in this time range.
Do you have any ideas of what else can be taught in such a short time?
I'd say 1.5days for a calculator by a complete novice is about spot on actually.
You could set the task as a simple 4-operator to be a target. If they surpass this they can add more complex functions. If not then it could simply be just for adding for example. The complexity is expandable depending on the student.
Simplefied version, only plus and minus. Or a leet/1337 translator, only requires them to do:
newBox.Text = oldBox.Text.Replace("l", "1").Replace("e", "3").Replace("t", "7")
I would think the calculator would be doable. Your basically only doing a simple form with some buttons and some basic logic on the various click events for the operators. Only issue would be the logic for chaining the operands and operators.
You might want to do a trial run by yourself of the project, and think where you would break it into steps to explain and such and see how long it takes.
Rock Paper scissors game? This would be good for if statements... Then if they grasp that the concept of conditional statements you could move on to a select case example. I find once most people understand that programs are based on conditions they generally can grasp much of the more advanced concepts much quicker. Conditional circuts were after all the beginning of computing.
When I was at school I started off by building a simple application that has a few buttons and on click it changes the background colour. Then you add more functionality such as a message box, then maybe a button that closes the applicaiton. Talk to them about the debugger/compiler and explain to them how it is very similar to making a cake with all the ingredients (I wish somebody explained it to me like that back then). You can make it as simple or as complicated as you want. Or instead of a real calculator you can teach them how to create a Reverse Polish Notation calculator (i.e in order to add 5 to 3 you would click: 5 then 3 then + which will return 8. Anyway trying not to get carried away here. Good luck and most important of all: make it fun for the future generation of programmers"
As a second interview I get people to sit down and write code...I try to make the problem really technology independent.
My programming problems that I have don't really exercise peoples OO abilities. I tend to try and keep the coding problem solvable within 2 hours ish. So, I've struggled to find a problem small enough and involved enough that it exposes peoples OO design skills.
Any suggestions?
This is a problem that I use with some trainings, looks simple but is tricky OOP-wise:
Create model classes that will properly represent the following constructs:
Define a Shape object, where the object is any two dimensional figure, and has the following characteristics: a name, a perimeter, and a surface area.
Define a Circle, retaining and accurately outputting the values of the aforementioned characteristics of a Shape.
Define a Triangle. This time, the name of the triangle should take into account if it is equilateral (all 3 sides are the same length), isoceles (only 2 sides are the same length), or scalene (no 2 sides are the same).
You can go on and on with quadrelaterals (which include squares, rectangles, rhombi, etc) and other polygons.
The way that they would solve the above problems would reveal the people who understand OOP apart from those who don't.
ideally, you want to present a problem that appears difficult, but has a simple, elegant, obvious solution if you think in OO terms
perhaps:
we need to control access to a customer web site
each customer may have one or more people to access the site
different people from different customers may be able to view different parts of the site
the same person may work for more than one customer
customers want to manage permissions based on the person, department, team, or project
design a solution for this using object-oriented techniques
one OO solution is to have a Person, a Customer, an Account, and AccountPermissions, where the Account specifies a Person and a Customer and an optional Parent Account. the use of a recursive Account object collapses the otherwise cumbersome person/team/department/project structure a direct ERD solution might yield
I have used the FizzBuzz Programming Test. And shockingly can corroborate the claims made by the article. As a second follow up I have asked candidates to compute the angle(s) between the hands on an analog clock. We set up a laptop with VS 2008 installed and the stub in place. all they have to do is fill in the implementation.
I am always stunned at how poorly candidates do on these two questions. I really am.
Designing Social Security Application is something which I ask a lot of people during interviews.
The nice thing about this is everyone is aware of how it works and what things to keep track of.
They also have to justify their design and this really helps me get inside their head :)
(As there is lots of flexibility here)
Kind regards,
Whether or not people do some coding in the interview, I make it a point to ask this:
Tell me about a problem you solved recently using object oriented programming. You'd be surprised how often people cannot answer that simple question. A lot of times I get a blank stare, or they say something like "what do you mean? I program in .NET, which is all object oriented."
These aren't specifically OO Questions, but check out the other questions tagged interview-questions
Edit: What about implementing some design patterns? I don't have the best knowledge in the area but it seems as if you would be getting two questions for the price of one. You can test for both OO and Design pattens in the one question.
How about some sort of simple GUI. It's got inheritance, overriding, possibly events. If you mean for them to actually implement as part of the test then you could hand them a blank windows-form with an OnPaint() and tell them to get to it.
You could do worse than ask them to design a MapReduce library with a single-process implementation. Will the interface still work for a distributed implementation? What's the exception-handling policy? Should there be special support for chaining MapReduce jobs in a pipeline? What's the interface to the inputs and outputs? How are inputs chunked up? Can different inputs in one job go to different mappers? What defaults are reasonable?
A good solution in Python takes about a page of code.
I've got a super simple set. The idea is mainly to use them to filter out people who really don't know their stuff rather than filtering in the rock stars.
These are all 5 minute white-board type questions, so they are really not that hard. But the act of writing up code, and talking through it reveals a lot about a candidate - and is brilliant for exposing those that can otherwise BS through the talk.
Write a method that takes a radius of a circle as an argument, and returns the area of the circle (You would be amazed how many people struggle on this one!)
Write a program that accepts a series of numbers as arguments from the command line. Add them up, and print the sum
Write a class that acts as a keyed counter (basically a map that keeps track of how many times each key is "counted")