|
I wonder what optimization algorithm should be used for such a problem:
x: independent variable
y: dependent variable
For y = f(x), find all x such that:
sum of y is > p where p is a positive integer
sum of y is the minimum of all sums that are greater than p
|
|
|
|
|
Try the Algorithms forum.
|
|
|
|
|
I am looking to find some mathematical way to determine a relative rating among users.
For example, ( A1:5 = completion of task A1, taking 5 seconds)
Bob : A1:5 A2:6 A3:15
Joe : A1:5 A2:10 A3:15
What I am looking to come up with is a numeric rating of who is better at the "A" task based on how fast they complete each task. ( the shorter the time, the better )
So in the above example, Bob, would have a higher rating, and this is pretty easy to figure out.
However, when more, and unequal completion of the tasks are added... it starts to get complex:
Bob : A1:3 A2:9 A3:12 B1:20 B2:10 B3:1 D1:15 D2:20
Joe : A1:5 A2:11 A3:13 B1:15 B2:12 B3:2 C1:4
Is there a mathematical model that describes what I am trying to achieve?
modified 5-Mar-14 13:19pm.
|
|
|
|
|
M i s t e r L i s t e r wrote: Is there a mathematical model that describes what I am trying to achieve?
Probably, but we'd need to know what you're trying to achieve first!
With your first example, it looks like you're summing the time for all the tasks, and ranking the users based on the total. Would that work for your second example?
Are you ranking each user on each task, summing the ranks, and then ranking the users on that total?
Try to talk exactly through what you want to do step-by-step. If the answer doesn't jump out at you, write down the steps and post them here.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So what I am trying to achieve is this:
A bunch of users perform N number of tasks. Each task can have 1-M sub tasks. eg:
Task[ 0 ] : Sub tasks = 2
Task[ 1 ] : sub tasks = 3
User A
Task[0][0] = 20
Task[0][1] = 35
Task[1][0] = 45
Task[1][1] = 42
Task[1][2] = 56
User B
Task[0][0] = 15
Task[0][1] = 26
Task[1][0] = 49
Task[1][1] = 22
Task[1][2] = 39
|
|
|
|
|
OK, but how are you wanting to rank the users?
Are you just summing the total time for all sub-tasks of all tasks and ranking based on that?
Are you summing the time for the sub-tasks of each task, ranking the users per task, summing the ranks for all tasks, and then ranking the users based on that?
You need to explain how you want to get from a series of tasks, sub-tasks and times to a rank for the user. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I've recently been having doubts about the way I've been approaching certain aspects of OO design in my projects (C#), and am looking for some advice. I use Castle Windsor IoC/DI framework, where dependencies are injected via class constructors. I also use a mocking framework (Moq) for my unit tests.
To support both frameworks I tend to find myself doing one of two things:
- creating an interface for every class, even if it's internal, or unlikely to have more than one concrete implementation (such as helper classes)
- or, I'll make such a class "mockable", which requires giving it a parameterless constructor, and marking its members as "virtual".
Both of these approaches feel like I'm writing additional code just to satisfy these two frameworks (particularly unit testing), but it does mean I can test a class in isolation, without it calling into potentially complex helper class functionality (which is the whole point of a unit test isn't it?).
My projects are typically self-contained desktop applications with no public API. Some articles I've read suggest that I should therefore not be using things like DI and interfaces, and I shouldn't even be unit testing internal classes. If I followed the latter advice then none of my code would be covered! (If you're wondering, I'm able to unit test internal classes because I use the "InternalsVisibleTo" attribute in my assemblies).
I'm now wondering if I'm taking the "separation of concerns" aspect of OO too far? Am I right to be using dependency injection with internal classes that will only ever have one concrete implementation (e.g. a "helper" class)? Or should I ditch DI and just instantiate such dependent classes? The latter would of course create a strong-coupling, making unit testing more difficult, especially if that helper class contained complex functionality, did database work, etc.
I hope I've made my concerns clear. To summarise, I guess I would like to know if I'm not using DI for its intended purpose, and whether my approach to unit testing and mocking is correct.
|
|
|
|
|
I'd guess that any meaningful answer has to be based on the reasons you are using the techniques. Interfaces and a framework in a team environment and managed in a central way can be, as I found, a very good way of managing the code people write and also a extremely useful mechanism that enables the interaction of code written in different languages and by different teams. The ability to have another person write a test based on an interface is also very useful.
If you're working by yourself some of the benefits interfaces can bring as just mentioned might be regarded as wasted coding time but perhaps bring benefits that are worth the extra code at design and debug time and also in introducing some discipline. However if you're writing code that you expect others to have to work with in the future you're probably contributing to their being able to understand it relatively quickly - though are probably demanding a fair level of expertise from those future people by your selection of framework etc.
Also if your code is part of a generic platform used across applications then using interfaces etc. probably contributes to that. However if its for a specific instance then as you suggest you may be adding generality that's not required.
From another perspective i.e. yours, rather than 'the company' are you learning skills and methods that improve your standards - it can get very boring doing the simple things without new approaches.
I suppose you've got to way the pros and cons on each technique from say a client, company(over say a N year period) and personal perspective to reach a real conclusion.
|
|
|
|
|
Does anyone know about what tools and technologies are used to develop CodeProject? I am also interested in the hardware configuration. I tried to search for it, but couldn't find any information on it. I would appreciate it if anyone can share that information
|
|
|
|
|
|
|
|
|
No, I meant my answer is incomplete one. I just gathered possible things to answer your question.
thatrajaCode converters | Education Needed
No thanks, I am all stocked up. - Luc Pattyn
When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is - Henry Minute
|
|
|
|
|
Oh, I am sorry. I understood it differently. Thank you for your articles, I am reading them at the moment. They seem to have alot on ASP.NET side of the website, very informative.
Regards
|
|
|
|
|
Over the years I seem to go back and forth over what I prefer regarding multiple method names vs a single method with a discrimination parameter.
Sometimes I prefer multiple, similar methods:
LogError(sometext)
LogWarning(sometext)
And other times I see it more as a single method with an enumerated parameter:
Log(type, sometext)
It seems pretty subjective as to what conveys intent best and makes using the class easier.
Any opinions? (Particularly interested in thoughts that contain an objective reason. I already have subjective thoughts that keep varying over time.  )
Thanks.
|
|
|
|
|
Harley L. Pebley wrote: Any opinions?
There are bigger problems to worry about would be my thought.
|
|
|
|
|
Other problems, of course. Relative size is a matter of opinion. In this case, the API is the primary way for users to access the rest of the product. It's pretty important.
|
|
|
|
|
Harley L. Pebley wrote: It's pretty important.
No it isn't. Which is obvious based on your experience. Both exist and both are used. Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'.
And it is possible that one or the other is better based on specific usage (class and how it will be used.)
And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
|
|
|
|
|
jschell wrote: No it isn't. Which is obvious based on your experience.
LOL. Pretty condescending statement, don't you think?
jschell wrote: Unless you can demonstrate that a significant number of bugs result from one or the other then neither is 'better'.
Sure, that's one way to measure 'better.' And there are two sides to that bug count: the users' and the implementers'. But there are other measurements of 'better' too: ease of discover-ability, semantic clarity, ease of use and ease of implementation among them. It's these more subjective qualities that I was looking for feedback and opinion on.
jschell wrote: And lets say you can determine that bugs are caused by this, how do those number of bugs compare to the ones caused by logic, design and requirement problems compare?
Sorry, I don't understand the relevance of this question. Are you still trying to make the point that this isn't important? If so, that's fine. I simply disagree. The floorplan and architecture of a house is just as important as the quality of materials and workmanship in framing, plumbing and electrical work. If any of it sucks, home buyers will look elsewhere. The API of a public library is as important as the private implementation. If either one sucks, users will look for alternatives.
|
|
|
|
|
Harley L. Pebley wrote: LOL. Pretty condescending statement, don't you think?
Not sure I understand that. Perhaps you misunderstood what I was saying.
You already pointed out that you have seen both used AND that it is unclear to you that either is better. Those two things together represent your "experience" and it is that to which I was referring.
Harley L. Pebley wrote: But there are other measurements
I doubt it. Especially the "ease of implementation". But if you know of a way to measure (some objective process that arrives at a numerical result) then I would certainly like to hear about.
Of course someone might just like it better, but that isn't the same.
Harley L. Pebley wrote: Sorry, I don't understand the relevance of this question.
The answer to the original question is not relevant unless you can show that the number of problems caused by this are significant. That can only occur if either your application has a very low number of bugs caused by the things I mentioned (which is where I see most bugs occur) or because, in fact, this idiom causes a massive number of bugs in your application (overriding the other type.)
If that isn't your situation then focusing on reducing the other types of bugs is more effective.
|
|
|
|
|
jschell wrote: Perhaps you misunderstood what I was saying.
Perhaps so. Typically when I hear people refer to "in my (your) experience" they are referring broadly to the sum total of all experiences, not narrowly to the one under discussion. I apologize.
As to the rest of our conversation, we're going meta into the importance/relevance of the question relative to other things and away from my original question. I think we view things through different lenses and just disagree, which is cool. Different perspectives provide food for thought.
Thanks for the feedback.
|
|
|
|
|
According to Robert C. Martin's Clean Code, use different functions: the function names give you additional information on the purpose, thus making the code better readable.
|
|
|
|
|
According to Eddy, it is not DRY.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Interesting. How do you see multiple methods violating DRY?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
