|
So far the linear sieve has not been mentioned nor shown in code in this thread, and it is
not the way I would recommend to have a program determine primality for a specific number.
The sieve methods are fine to explain the concept, and to execute by hand (i.e. for small
numbers) since no divisions are required at all; successive division attempts are the normal
first-order attempt in a program.
For large numbers (say above 100 digits) completely different techniques are available
and are getting refined all the time to investigate primality; most of them use shortcuts
that reduce the computational effort tremendously at the expense of a little uncertainty
(false positives for some tests, false negatives for other tests). And special libraries
("big integer" or "multiple precision" are used to operate on those numbers).
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
hi
is that anyWay or any Compiler or ... that convert or transfer my c# code to IC or MicroController ?
thanks ..
|
|
|
|
|
Yes - it's still zeros and ones at the end of the day so could be stored on an eeprom.
What use it would be I don't know as it will never run without the Operating System plus .net framework. You would need to develop a hardware driver as well to communicate between your eeprom/microcontroller and the operating system/framework.
If you want it as a standalone thing without a computer connected then no as the operating system and .net framework need a PC to run plus attempting to copy them would be highly illegal.
|
|
|
|
|
DaveyM69 wrote: What use it would be I don't know as it will never run without the Operating System plus .net framework. You would need to develop a hardware driver as well to communicate between your eeprom/microcontroller and the operating system/framework.
You'd only need this if you were trying to run a MSCLR C# app complied to MSIL (Built in MSVS IDE) application on a µC. You could in theory write in C# syntax/style in a special IDE for a µC that translates C# syntax to machine code for your µC. I don't really see the point in such an IDE because standard C syntax is close enough for anyone who knows C# to switch to.
DaveyM69 wrote: If you want it as a standalone thing without a computer connected then no as the operating system and .net framework need a PC to run plus attempting to copy them would be highly illegal.
The C# syntax/styling isn't protected else the Mono CLR and monoIL would have been shutdown years ago, not that MS didn't try before actually supporting them...
Some things that are close would be J2ME (Java µ Edition) which is close to C# and Java...
Why not just learn C to run on a µC anyway?
|
|
|
|
|
thanks SpacixOne
you mean that i don't use any ide for programmer to microController with c# support ?
|
|
|
|
|
hello everyone ,
i would like to know if someone have any code example for the next situation :
i want to write a program that will write events to a log file.
there are 2 kind of events ( high , normal (priority))
two queues ( for each event type )
all the events will be inserted to the queue first( the queue manage the log file writing )
for each queue there is "max events per queue" parameter , wich means
that if the queue is full , i need to create a new one ( and so on ...)
each new queue will create a new thread...
all this will run with threads ( number from the user)
ofcurse that the high event will get more priority, but also take care of starvation ...
i'm lost ...
Thanks,
kris
|
|
|
|
|
kriskris wrote: i'm lost ...
Where are you lost?
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
kriskris wrote: the next situation
what was the previous one?
Do rate the reply, if it helps or even if it doesnot, because it helps the members to know, what solved the issue. Thanks.
|
|
|
|
|
How can I load an assembly (dll) as non domain-neutral in my own created AppDomain?
Background:
After doing his work I have to unload these assembly by code. But jet these assembly stays in the AppDomain of my main-application.
Thanks for your help!
Olaf
|
|
|
|
|
hi all.
i write a bho to find useful hyperlink clicks of user in a page.
in other case how times user click in a page that occurred to open a new external page.
i try to do it in Befornavigate2 event. but i found when it raised I'm in new page, not in parent page .
help me where i should do it?
sepel
modified on Saturday, January 26, 2008 5:36:50 AM
|
|
|
|
|
How can I write a program that ads an item on windows right click menu?
I've searched for articles in this topic but no result...
_____________________________
...and justice for all
APe
|
|
|
|
|
This is very simple to do in .NET 2.0
From ToolBox [ Menu and ToolBar Section ]
ContextMenuStrip
Create Your Menu As simple as create normal menu bar.
Now If you want it on rightClick on an item..
e.g : ListView
Now in PropertSection , Select ContextMenuStrip and select your selected menu.
Thats all.
if you check this article http://www.codeproject.com/KB/cs/NetWorkSpy.aspx[^]
here i have used Similar thing
|
|
|
|
|
If you mean the Shell's own context menu it's a little trickier.
See here[^]
|
|
|
|
|
|
I really like intellisence but I for sure don't know every good shortkey and so on. Where can I read about all intellisence can give me as a developer?
For e.g. whern I write these lines:
string str = "Hello all";<br />
str.Split(' ');
I automaticaly want VS to create a variable (string[]) that catches the return value from the Split-function. Is that possible?
string str = "Hello all";<br />
string[] arr = str.Split(' ');
_____________________________
...and justice for all
APe
|
|
|
|
|
d00_ape wrote: Where can I read about all intellisence can give me as a developer?
Reading the documentation[^] would be a good start. However Intellisense won't automatically generate code for you.
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
Hi,
I am planning a win forms app that bascially has a shell
that has plugins to provide functionality.
I want to be able to create a library of subclassed
win form controls that I can control the font
colors etc so that when the app font is changed for
exmaple all controls in all plugins change.
So my question is should I allow the plugins
to refernece the control libary and pass to
the plugin the application properties.
Or
Provide a control service main app
to the plugin that would allow the
app to control application properties
What is the best way to do this?
rotsey
|
|
|
|
|
If I follow you logic correctly...
The first way would be best if the properties are to be read only to the plugins
The second way would be best if you want the plugins to be able to globally alter the properties (the extra 'control service main app' would sort of act as a server with the plugins and application acting as clients)
... although both ways could potentially acheive both results.
|
|
|
|
|
So, I found out by accident that a class doesn't actually need to implement IEnumerable to be able to foreach over it.
This works just fine (VS2005):
class X
{
private List<int> mList = new List<int>() ;
public X() { mList.Add(1) ; mList.Add(2) ; mList.Add(3) ; }
public IEnumerator GetEnumerator() { return mList.GetEnumerator() ; }
}
X x = new X() ;
foreach ( int n in x )
System.Console.WriteLine( n ) ;
MSDN confirms[^] this behaviour:
Evaluates to a type that implements IEnumerable or a type that declares a GetEnumerator method.
Although this[^] suggests that it's a C# thing only.The reason for implementing IEnumurable therefore, is (a) to identify the class as enumerable/foreach-able, and (b) to provide a language independant implementation that will work in other languages that don't provide the C# foreach performance "hack". But even given that, it still begs the question: why did the C# team feel the need for foreach to accept objects that don't implement IEnumerable?
But it gets worse when using generics. Deriving X from IEnumerable<T> forces you to implement both the generic (expected) and non-generic (huh?!) version of GetEnumerator():
class X : IEnumerable<int>
{
private List<int> mList = new List<int>() ;
public X() { mList.Add(1) ; mList.Add(2) ; mList.Add(3) ; }
IEnumerator<int> IEnumerable<int>.GetEnumerator() { return mList.GetEnumerator() ; }
public IEnumerator GetEnumerator() { return mList.GetEnumerator() ; }
}
X x = new X() ;
foreach ( int n in x )
System.Console.WriteLine( n ) ; Except that when stepping through the debugger, foreach uses the *non-generic* GetEnumerator(). So why even bother having the generic one?
I'm pretty new to C# but this seems kinda dumb. Am I missing something?
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Taka Muraoka wrote: I'm pretty new to C# but this seems kinda dumb. Am I missing something?
Not really. The biggest thing you're missing is the fact that when .NET 1.0 was first released there were no real internal guidelines being followed by the team. As the outside world started using the Framework more and the team got smarter about what they were trying to do, guidelines started to form and best practices started to take shape.
The fact that C# implements a foreach iterator was done mostly as a convenience for the developer more than anything else. There is always an argument over which one provides more performance and there are cases where one wins over the other.
The reality is that any type which should support "foreachable" behavior should implement the interface. The rules for implementing the generic IEnumerable<T> exist that way because IEnumerable<T> implements the IEnumerable interface.
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Thanks for the info.
Scott Dorman wrote: The fact that C# implements a foreach iterator was done mostly as a convenience for the developer more than anything else.
Given that this kind of feature is pretty standard in modern languages, I'd say it's perhaps a little more than a developers' convenience. But it wouldn't even occur to me to do it any other way than via the IEnumerable interface. For someone to say "we'll have it accept anything that has a GetEnumerator() method" suggests to me someone who doesn't really know what they're doing
Scott Dorman wrote: The rules for implementing the generic IEnumerable<t> exist that way because IEnumerable<t> implements the IEnumerable interface.
This is the one that really baffles me. The generic GetEnumerator() doesn't appear to get called so I don't quite see the point of having IEnumerable<T> at all. You might as well just derive from IEnumerable :shrug:
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Taka Muraoka wrote: Given that this kind of feature is pretty standard in modern languages, I'd say it's perhaps a little more than a developers' convenience.
Just because it's in most modern languages only means it's a popular feature. I think what you will find behind the scenes in the IL is pretty much the same calls if you used a class that implemented IEnumerable or one that didn't. The code generated is still a call to GetEnumerator and then calls to GetCurrent .
The fact that foreach works without IEnumerable was probably done in order to provide the most flexibility. I wouldn't necessary say that it suggests "someone who doesn't really know what they are doing".
Taka Muraoka wrote: This is the one that really baffles me. The generic GetEnumerator() doesn't appear to get called so I don't quite see the point of having IEnumerable<t> at all.
What are you using to determine that the generic GetEnumerator isn't being called?
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: I think what you will find behind the scenes in the IL is pretty much the same calls if you used a class that implemented IEnumerable or one that didn't. The code generated is still a call to GetEnumerator and then calls to GetCurrent.
I haven't really bothered looking too deeply into IL but as a hard-core C++ guy, it certainly doesn't make any sense.
Scott Dorman wrote: The fact that foreach works without IEnumerable was probably done in order to provide the most flexibility. I wouldn't necessary say that it suggests "someone who doesn't really know what they are doing".
Well, it doesn't really make any sense from a general OO point of view, either
Scott Dorman wrote: What are you using to determine that the generic GetEnumerator isn't being called?
Just stepping through in the debugger. Modifying it in the code sample in my OP to return null seems to have no ill effects.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|
|
Taka Muraoka wrote: I haven't really bothered looking too deeply into IL but as a hard-core C++ guy, it certainly doesn't make any sense.
The IL is much closer to reading assembly than anything else, but it can sometimes reveal some interesting results.
Taka Muraoka wrote: Well, it doesn't really make any sense from a general OO point of view, either
I can't disagree with this. I was only saying why I think it might have been done that way.
Taka Muraoka wrote: Just stepping through in the debugger. Modifying it in the code sample in my OP to return null seems to have no ill effects.
What you are seeing is actually correct behavior for your code. You have explicitly defined the IEnumerable<T>.GetEnumerator() and implicitly defining the IEnumerable.GetEnumerator() . Since IEnumerable.GetEnumerator() is public (and implicit) this code gets called. There are a few ways to change this so it calls the generic enumerator:
1: Leave your class X defined as is, and change the call in the foreach loop to read
foreach (int n in (IEnumerable<int>)x)
{
System.Console.WriteLine(n);
} 2: Leave the foreach call as is, and change X to read:
class X : IEnumerable<int>
{
private List<int> mList = new List<int>();
public X()
{
mList.Add(1); mList.Add(2); mList.Add(3);
}
IEnumerator<int> IEnumerable<int>.GetEnumerator()
{
return mList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return mList.GetEnumerator();
}
} or
class X : IEnumerable<int>
{
private List<int> mList = new List<int>();
public X()
{
mList.Add(1); mList.Add(2); mList.Add(3);
}
public IEnumerator<int> GetEnumerator()
{
return mList.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return mList.GetEnumerator();
}
}
Scott.
—In just two days, tomorrow will be yesterday.
—Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[ Forum Guidelines] [ Articles] [ Blog]
|
|
|
|
|
Scott Dorman wrote: 1: Leave your class X defined as is, and change the call in the foreach loop to read
foreach (int n in (IEnumerable<int>x)
{
System.Console.WriteLine(n);
}
This is obviously kinda ugly. The intent of deriving from IEnumerable<T> is to enforce type-safety and I was hoping that the compiler would be smart enough to realize that X can only be iterated over using int's and nothing else.
Scott Dorman wrote: 2: Leave the foreach call as is, and change X to read:
Both these work but there are still some oddities.
The following code compiles but throws a cast exception at runtime, which is what one (or at least I) would expect:
class X
{
private List<int> mList = new List<int>() ;
public X() { mList.Add(1) ; mList.Add(2) ; mList.Add(3) ; }
public IEnumerator GetEnumerator() { return mList.GetEnumerator() ; }
}
foreach ( X n in x )
System.Console.WriteLine( n ) ;
But using the modified foreach with either of your #2 code samples doesn't even compile ("Cannot convert int to X"). So it seems that there's now no way to get into the non-generic GetEnumerator() I don't particularly want to but it annoys me that I have to define this method but it never gets used
So, it looks like foreach is ignoring whether the object it's iterating over derives from IEnumerable or IEnumerable<T> and just looks for a public GetEnumerator() method (which is kinda lame). But then how does it know which GetEnumerator() to use in your 2a code? Both of them are public in their respective interfaces, and yes, I tried reversing the order they are defined in I was kinda hoping the compiler could infer which one to use by the type being used in the foreach statement but for some reason, it's only allowing the generic one to be used.
Oh well, I guess we can just chalk this one up to C# evolving on the fly. Thanks for your help.
I enjoy occasionally wandering around randomly, and often find that when I do so, I get to where I wanted to be [^].
Awasu 2.3.2 [^]: A free RSS/Atom feed reader with support for Code Project.
|
|
|
|