This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
class System.Random .. why not static?
Following on from "Generated random numbers are always equal", I was wondering;
Why doesn't the Random class expose a static method for Next with an optional minimum and maximum? This might sound like a silly question, but from experience, 9 times out of 10 I want to generate a random number, without having to explicitly specify a seed? Am I missing something obvious, is there a reason for this? Or is there in fact a method that I'm explaining that I'm yet to discover?
This might sound like a silly question, but from experience, 9 times out of 10 I want to generate a random number, without having to explicitly specify a seed?
You shouldn't be using a static method for that though. You should be using an instance method on something which does maintain state. If you create a new instance of Random every time you call Next, you'll end up with repeated numbers if you call it several times in quick succession.
You should regard "a source of random numbers" as a dependency like any other, IMO - injectable in order to be testable. Of course, if you're not using dependency injection then this argument may not apply... but then you've got other problems.
You probably want one instance of Random per thread, as Random isn't thread-safe.
See my article on random numbers for more details and code samples.
Related
We have a knowledge base with near 1000 answers and a average of 15 alternate questions for each one of them. We are training the base both adding alternate questions as trying to indicate the correct answer using the portal.
We have struggling to improve the precision but without relevant success yet. An important problem is that base has a lot of similar answers between themselves, many times the difference among them is only an year (e.g. 2014 or 2018).
Some times when we use the GenerateAnswer API we need increase the parameter top a lot to receive the correct answer. For some questions we need assign the value 500 for top parameter, otherwise we get other answers with high scores, but still incorrect.
We thought that we could increase that results using the portal to train the knowledge base indicating the correct answer, but when we are trying it, we get just the first three top ranked answers, all incorrect.
*Note: We already migrated a test base to new approach (Language services/Question Answering) hoping that could be help us, but the problem stays, actually a bit worst.
How can we deal with this kind of situation? Can we change the top parameter value used by the portal? Are there another ways we can use to improve the rank?
This question already has answers here:
High resolution timer in C#
(5 answers)
Closed 5 years ago.
No matter where I look, I can't find a good answer to this question. I'd like to have something happen at a given BPM (in my example, I'm using BPM), but the basic C# Timer class isn't working for me. Since it only measures in milliseconds, any actions performed within the timer get noticeably unsynced from the music. I've attempted to use this MicroTimer Library but with no luck! Though it can be quite fine grained, it's resource heavy and it doesn't have the resolution necessary. I understand I can have a function with a counter, but is there a good way to do this with Visual Studio's libraries (like the basic timer)? I hear those aren't as processor hungry.
I doubt you'll get the kind of time resolution you're looking for in a managed language like C#.
Hell, even if you were writing in C the OS could decide another process is more important and just like that you're out of sync.
Maybe consider using the timer, but resyncing every second or half second? I'd default to another user if they have experience in this area, but I'd at least give that a shot. Or go by the system clock ticks?
This question already has answers here:
Is a GUID unique 100% of the time?
(24 answers)
Are GUID collisions possible?
(19 answers)
Closed 9 years ago.
I generate keys for my software as:
Guid.NewGuid().ToString();
that returns something like: 15c6bd70-8d3c-42d0-bb24-40da6e08ed9d
anyways everytime someone purchases a new software I generate a new key. can it be possible that I generate the same key twice? Everytime someone purchase the software I call the method: Guid.NewGuid().ToString() Should I append a counter at the end of each guid to be 100% sure that there cannot be duplicates?
Edit
A constructor of the Guid class takes a byte array of 16 bytes as a parameter. If you serialize the current date (8 bytes) then append another 8 random bytes to the constructor of the GUID will that be 100% secure? I am just asking for learning based on your answers I will probably just have Guid.NewGuid()
An excerpt from one of the best blog series ever written about the Guid:
There are a number of possible strategies for making a unique GUID, and in fact information about the strategy used is encoded in the first four bits of the third "group"; almost every GUID you see will be of the form {xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx} or {xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx}.
If there is a one in that place then the algorithm used to guarantee uniqueness is essentially a variation on the ISBN strategy. The GUID is guaranteed to be unique "in space" by choosing some of the bits as the MAC address of the network card in the machine. (The tricky problem of ensuring that no two network cards in the world have the same MAC address is solved somehow by someone else; how that problem is solved, we don't particularly care. The cost of solving that problem is passed on to you, the consumer, in the purchase cost of the network card.)
In short, it's very unlikely that they would ever collide.
Yes, it's possible, but extremely unlikely. The probability for a GUID collision is about as likely as a bit in the GUID changing spontaneously in memory, and that kind of thing is not something that you normally worry about.
You can already be 100% sure, that is of course if you dont mean that you need to be 100.000000000000000000000000000000000000% sure.
Just use the Guid.. no need to append anything. Unless you expect to sell more copies than there are atoms in the universe (unlikely).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the purpose of the Tuple(T1)/Singleton in .net?
Trying to mimic a Tuple as implemented in .Net 4 (For .Net 3) I just realized there is a Tuple(Of T)? This was quite a surprize!
Why would anyone do this
Tuple<string> result = new Tuple<string>("Data");
Instead of this
return "Data";
Isn't the whole point of a tuple that its a container for "loosely related data that isnt cohesive enough to make another class"? Am I missing something?
There are a finite number of tuple-arities in the library, so to define an 8-tuple, you use the kind with 7-elements whose 'rest' argument is a one-tuple. See
http://msdn.microsoft.com/en-us/library/dd383325.aspx
This is a carry over from set theory that might not have much use for a software developer.
Tuples are simply ordered lists of elements. An N-tuple has n elements, and n can be one, which is called a singleton. You probably won't have much use for a 1-tuple in code, but I'm guessing the C# team put it in there for completeness.
http://en.wikipedia.org/wiki/Tuple#Etymology
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to know how many parameters can be passed to function, I mean what is good programming practice, regarding passing the parameters to function?
Code Complete suggests a maximum of 7. This is because of The Magical Number Seven, Plus or Minus Two:
...the number of objects an average human can hold in working memory is 7 ± 2; this is frequently referred to as Miller's Law.
Here's an excerpt from Code Complete 2nd Edition:
Limit the number of a routine’s parameters to about seven
Seven is a magic number for people’s comprehension. Psychological research has found that people generally cannot keep track of more than about seven chunks of information at once (Miller 1956). This discovery has been applied to an enormous number of disciplines, and it seems safe to conjecture that most people can’t keep track of more than about seven routine parameters at once.
The fewer the better, but only if it still makes sense. I've never heard of a standard number of params to be passed, but I have heard of ways to keep them down better.
For example, don't do this:
public void DoSomething(string name, int age, int weight, ...) { }
but rather:
public void DoSomething(Person person) { }
but hopefully that goes without saying. But also, I would recommend not creating a weird class just to trim down the parameter count.
IMHO 5 at MAX.
6 is too much for me and 7 overwhelming!
According to Clean Code - maximum 3
If you have many things you would like to pass to a function you may want to look at some other means of transferring that data as opposed to simple parameter passing. For example in certain cases it may be better to generate an XML file and then pass values related to getting data around that XML file. If you are running a web app it may be simply passing data through sessions or post rather than get or function calls that will simplify your life.
Also you may want to store some of that information as member variables.
I would recommend no more than 4. You don't want your lines to get much longer than 30 characters long unless you are generating some massive string, but even then it becomes really unreadable and gross (although necessary especially for javascript).
It's good programming practice to write programs so that they are easy to read. Personally I try not to write functions which have more parameters than can be displayed on one line on the screen. Usually that is no more than five or six parameters at most.
some ARM compilers pass three or less parameters using registers and any more than three are stacked. The stacked type call is slower than the call using registers so in this case you should use three or less parameters, for speed.
Depending on the architecture, more than 1-3 will cause passing on the stack. This is slower than passing via registers. From a performance standpoint, it is best to pass either a pointer to a wrapper class or a pointer to a struct. This ensures that only one value is passed in and saves some writes/reads to memory.
If you don't know how many parameters you are going to pass to a function use param for sending variable arguments to a method.