|
This is just off the top of my head and admittedly not very performant.
int num = 12700000;
int answer = num;
while (--answer > 1) {
if (num % answer == 0) {
break;
}
}
Console.WriteLine ((answer > 1 ) ?
string.Format ("The largest number that divides {0} is {1}.", num, answer) :
string.Format ("Sorry, {0} is a prime number.", num));
}
/ravi
|
|
|
|
|
Here's an idea based on the idea that your problem is one of finding the nearest prime divisor of integer 'n by integer 'd:
private bool findNearestPrimeDivisor(int n, int d, out int? result)
{
int mod = n % d;
if (mod == 0)
{
result = null;
return true;
}
bool primeFound = false;
int prime = 0;
for (int i = mod; i < d + mod; i++)
{
if (n % i == 0)
{
primeFound = true;
prime = i;
if (i > d) break;
}
}
if (primeFound)
{
result = prime;
return true;
}
result = null;
return false;
}
int? factor;
int testn = 12700000;
int testd = 6269;
if (findNearestPrimeDivisor(testn, testd, out factor))
{
if (factor == null)
{
Console.WriteLine("{0} is an integral divisor of {1}", testd, testn);
}
else
{
Console.WriteLine("{0} is the nearest integral divisor of {1} to {2}", factor, testn, testd);
}
}
else
{
Console.WriteLine("No near prime divisor found.");
} Note: I am not advanced enough in computer science to evaluate how "robust" this may be; this is written "off the top of my head." I welcome any feedback, or correction.
« I am putting myself to the fullest possible use which is all, I think, that any conscious entity can ever hope to do » HAL (Heuristically programmed ALgorithmic computer) in "2001, A Space Odyssey"
|
|
|
|
|
Thanks to Ravi and Bill for both of your answers. I was hoping there would be a way to get the answer required without checking each individual number. There are gaps between divisers of millions in some cases. I shall play about with your suggestions and see what the performance is like.
|
|
|
|
|
Just out of interest here is my modified code. It will search in a both positive and negative direction so that it not be biased either way.
private int FindNearestDiviser(int n, int d)
{
int positiveSearch = d;
int negativeSearch = d;
if (n % d != 0)
{
while (n % ++positiveSearch != 0
&& n % --negativeSearch != 0) ;
if (n % positiveSearch == 0)
{
d = positiveSearch;
}
else if (n % negativeSearch == 0)
{
d = negativeSearch;
}
}
return d;
}
|
|
|
|
|
I like this approach !
« I am putting myself to the fullest possible use which is all, I think, that any conscious entity can ever hope to do » HAL (Heuristically programmed ALgorithmic computer) in "2001, A Space Odyssey"
|
|
|
|
|
hello every one m stuck in to creating application whose abstract work is to copy some file from host machine to network machins sheard folder,
i m doing something like this in c#
string lscmd = "robocopy "+ lsCurentWorkingDirectory+ " \\\\CPU219\\Test$ " + lsFileName;
ProcessStartInfo ProcessInfo;
ProcessInfo = new ProcessStartInfo("cmd.exe", "/c " + lcmd);
ProcessInfo.CreateNoWindow = true;
ProcessInfo.UseShellExecute = False;
process = Precess.Start(ProcessInfo);
process.waitforExit();
when m runing this code through windows services its get stuck at process.WaitforExit(), and when m runing this by normal console applicatin application it works well,
plz help me
|
|
|
|
|
its most likely a permissions issue (ie the service is running under an account that doesn't have permission to the share) - have a look here and see if this points you in the correct direction http://serverfault.com/questions/177139/windows-service-cant-access-network-share[^]
[edit] one thing you could do, is try using account credentials (Domain, UserName and PassWord) in ProcessInfo - use your account for the moment, but make sure you blank them out after you've tested it (just so no-one sees your credentials) - if it works, that gives you options [/edit]
|
|
|
|
|
Download video on youtube of what documentation do I need ? if there are good examples raid
|
|
|
|
|
|
This was the old material can not be used for current
|
|
|
|
|
Well, I still use this library without any problems.
|
|
|
|
|
If you have examples are included for my reference to it ?
|
|
|
|
|
The examples on the GIT still work perfectly.
the only thing I adjusted was in DownloadUrlResolver.NormalizeYoutubeUrl to also implement google search Links and extract the real url from them. Everything else still works like a charm.
Just follow the Instructions on the repository.
Greet$
|
|
|
|
|
Hi,
I am creating one desktop application.in that application i want to add item without repetition.If i add duplicate item into datagridview this item can not be add but update their existing value.please help me.
|
|
|
|
|
Search the grid for that item already existing, and add or update as necessary.
|
|
|
|
|
I have a scenario where the application starts up and spawns a worker thread. When the main thread exits, I want the PROCESS (and the worker thread) to stay alive until its done doing its thing and then the whole process can exit. So I did something like this:
Thread threadCurrent = Thread.CurrentThread;
Task.Run(() =>
{
while (threadCurrent.IsAlive || (_queue.Count > 0))
Thread.Sleep(250);
});
This does exactly what I want. When the main application exits, the process keeps running until the queue is finished processing (_queue is processed in a separate thread, this code piece keeps the process alive) and then the process shuts down.
I'm not happy with the Sleep(250) portion because that part is going for the entire lifetime of the application. It's not spinning the CPU or anything. I'm just looking for a better way to do it.
I tried threadCurrent.Join(), however, that only works if the app is running in the debugger. I don't get why. If I have a debugger attached, the Join() blocks until the main thread is done as expected. If I don't have a debugger attached, the Join() never returns.
EDIT: I should also note that this code in a library, so I can't really require the developer to do anything special in the main thread to make this work.
|
|
|
|
|
|
As I specifically mentioned in my post, Thread.Join() only works on the main thread if the debugger is attached. I guess the debugger kills the main thread while without the debugger, the thread is not killed.
|
|
|
|
|
SledgeHammer01 wrote: only works on the main thread if the debugger is attached
That is definitely untrue. I use Join all the time.
|
|
|
|
|
Not what I'm seeing. If I do threadCurrent.Join() it works as expected IF THE DEBUGGER IS ATTACHED. When the main thread "is done" and my queue is empty, the whole process exits. If I ctrl-F5 it, it does keep the process alive, but it never gets past the threadCurrent.Join() and the process stays alive forever. Keep in mind that my worker thread is a FOREGROUND thread. That is required to keep the process alive.
|
|
|
|
|
OK, I second the remark that what you're saying isn't true.
You're going to have to back up what you're saying with the code because I think you're misinterpreting what the code is really doing.
|
|
|
|
|
If you say so ... but here you go... here's a simple console app that demonstrates it. Run this IN THE DEBUGGER (F5) and the process will exit after 5 seconds. Now run it again with CTRL-F5 (NO DEBUGGER ATTACHED) and you'll see the process never exits.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
namespace ConsoleApplication2
{
class Program
{
static bool b = false;
static void Main(string[] args)
{
Thread threadCurrent = Thread.CurrentThread;
Task.Run(() =>
{
threadCurrent.Join();
b = true;
});
Thread _threadWorker = new Thread(new ThreadStart(Worker));
_threadWorker.SetApartmentState(ApartmentState.STA);
_threadWorker.Start();
Thread.Sleep(5000);
}
private static void Worker()
{
while (true)
{
Thread.Sleep(100);
if (b)
break;
}
}
}
}
|
|
|
|
|
Very interesting. Well, I verified it. That's the most screwed up thing ever.
But, I hate to tell you this, but the one running under the debugger is lying to you. It's the one that's screwed up, not the one executing out of the debugger.
For some reason, the debugger is keeping the Task alive when it shouldn't be. Tasks are running out of the thread pool, which are all background threads. When your main thread exited, it took the Task with it, killing the threadCurrent.Join and never allowing it to get to b = true . That's why your worker thread stays alive.
I'd convert the Task to a foreground Thread instead.
[EDIT]
Oh, I almost forgot! You might want to post this on Connect[^] for a possible Visual Studio bug.
|
|
|
|
|
Tried the code this morning, first thing I did was change it to a foreground-thread. Strangely enough that made no difference at all.
I can imagine that the main-thread isn't terminated, but stopped by the debugger. That would explain why the background-task that should have terminated didn't.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Oh, I was going to try make that a foreground thread... so thanks for saving me the trouble .
Check out my response to Dave that further proves his explanation is not correctly. The main jist of the two further examples I posted was to prove that the Task is most certainly not getting killed and I wouldn't expect it to since the process is still alive.
|
|
|
|