Search Results

Search found 29064 results on 1163 pages for 'network management'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 417/1163 | < Previous Page | 413 414 415 416 417 418 419 420 421 422 423 424  | Next Page >

  • CodePlex Daily Summary for Thursday, May 27, 2010

    CodePlex Daily Summary for Thursday, May 27, 2010New ProjectsBinding Navigator: Clone of WinForms BindingNavigator that is able to work with any type of DataSource. For full functionality it requires the DataSource to implement...DEWD: DEWD is an Umbraco 4.0 extension used to edit sequential data such as rows in a SQL server database table. It's meant to allow developers to quickl...Eletronic Invoice Extensions: A simple DLL to use against XSD and validate a XML.EssionCalendar: EssionCal EssionCalExpression Encoder Batch Processor: Importing your videotapes into Windows is easy with the built-in utilities, but if your importer does not encode to your desired format, you need t...Feedback Form: Feedback application makes it easier for attendees who attend an seminar/event and event organizers. Organizers of the event will no longer need to...Find in Start Menu: Find in Start MenuIE8 Web Slices Pack: IE8 Web Slices Pack is a package of 5 types of web slices ready to be customized via a mini-CMS for your web site or for your custom IE8 installer....KafTK: Iskakov AzamatMicrosoft Dynamics NAV text export splitter: Utility for splitting Microsoft Dynamics NAV object exports (in text format) into files that each contain a single object. MultiPoint Vote: Voting is more innovative and catchy through this MultiPoint application. Using MultiPoint SDK 1.5 and Visual C#, this prototype emphasizes the cap...NebDotNet: NebDotNetnsim: Some simulation issues.OpenLight Group Common Lib: This project is a set of classes commonly used across OpenLight Group projects.pstsdk.net: .NET port of PST File Format SDK: pstsdk.net makes it easier for .NET developers to access the PST file format. This is a direct C# port of the PST File Format SDK project which is ...RavenMVC: A NoSQL Demo App using RavenDB and ASP.NET MVC 2.Remics: Remics is a toolkit for reverse engineering tools. Open source (MIT license). The goal of Remics is enabling developers (or researchers) quickly...RIA Services to Legacy DAL Integration Library: RIA Services to Legacy DAL Integration LibrarySharePoint List Adapters for SSIS: SSIS source and destination components to access SharePoint lists using basic authenticationSql Query Modelling Language: This project library creates simple Sql queries.Thumb nail creator and image resizer: a user control to create thubnails and resize images for displayTK: study projectViperWorks Ignition: Ignition is application framework for WinForms and WPF business applications. Built in webservice generation, reporting and rapid application devel...XNA Image Reflector: XNA Image Reflector allows you to add Web 2.0-like reflections to images in a few clicksXNArkanoid: XNArkanoid is a Windows Phone 7 remake of the classic Taito´s Arkanoid. It´s developed in C#, using XNA Framework v4.0.New ReleasesAcies: Acies - Alpha Build 0.0.5: First alpha release. Requires Microsoft XNA Framework Redistributable 3.1 (http://www.microsoft.com/downloads/details.aspx?FamilyID=53867a2a-e249...Ajax Toolkit for ASP.NET MVC: Ajax Toolkit for ASP.NET MVC v20100527: change array datasource to json datasource allow lowercaseAttribute Builder: Attribute Builder 1.0: Attribute Builder 1.0Support for parameter-less constructors, constructors with parameters and object initialization with field and property assign...Binding Navigator: TTBindingNavigator preview: First binary release. Only control without samples.Bojinx: Bojinx Core V4.5.15: Bugs fixed: Clean up in the event handler Added more disposal features to better clean up contexts on unload. Optimized command processing fur...CBM-Command: Version 1.0 - 2010-05-26: Release Notes - 2010-05-26 - Version 1.0New Features None Changes Fixed bug where you could move to an unopened panel Fixed bug where you could ...Community Forums NNTP bridge: Community Forums NNTP Bridge V03: This is the second release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open sourcen NNTP Bridge. ...Community Forums NNTP bridge: Community Forums NNTP Bridge V04: This is the second release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open sourcen NNTP Bridge. ...Community Forums NNTP bridge: Community Forums NNTP Bridge V05: This is the second release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open sourcen NNTP Bridge. ...Community Forums NNTP bridge: Community Forums NNTP Bridge V06: This is the second release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open sourcen NNTP Bridge. ...Community Forums NNTP bridge: Community Forums NNTP Bridge V07: Release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open sourcen NNTP Bridge. This release solves...Community Forums NNTP bridge: Community Forums NNTP Bridge V08: Release of the Community Forums NNTP Bridge to access the social and anwsers MS forums with a single, open source NNTP bridge. This release solves ...Dot Game: Dot Game Network version: Now, you can play over network.EpsiRisk: EPSI RISK V1: First Stable Version of EpsiRISK ! Enjoy !Event Scavenger: Viewer 3.3.0: Added grouping functionality to Viewer. Group expanding/collapsing only supported under Windows Vista/7 and onwards. Viewer version set to 3.3.0.FAST for Sharepoint MOSS 2010 Query Tool: Version 1.0: Full Release Added sorting Added custom trim duplicates Added UI improvements Added ignore certificate errorsFoursquare for Windows Phone 7: Foursquare 2010.05.26.01: Foursquare 2010.05.26.01 Updates: Corrected issue with isPrivate, sendToTwitter, and sendToFacebookHobbyBrew Mobile: Beta 3: ATTENZIONE notifica nuove versioni via email disponibile (leggi in fondo)! Supporto alla rotazione dello schermo: Malti e Luppoli si affiancano or...IE8 Web Slices Pack: IE8 Web Slices Pack v2.0: This release of the Web Slices Pack supports 5 different Web Slices and a mini CMS to administer the info in the Web Slices.manx: manx data 1.0: Initial dump of data. This is a raw SQL dump script that deletes all existing data and inserts the initial dataset as received from Paul Williams....Microsoft Web Protection Library: WPL May CTP: This preview of the Web Protection Library includes AntiXSS - an updated Anti-Cross Site Scripting Library removes some bugs and is now usable in ...MultiPoint Vote: MultiPoint Vote v.1: MultiPoint Vote v1 Features This accepts user inputs: number of participants, poll/survey title and the list of options A text file containing th...NLog - Advanced .NET Logging: Nightly Build 2010.05.26.001: Changes since the last build:2010-05-25 19:21:49 Jarek Kowalski Reordered parameters of AsynchronousAction<T> 2010-05-25 19:16:02 Jarek Kowalski N...NodeXL: Network Overview, Discovery and Exploration for Excel: NodeXL Class Libraries, version 1.0.1.124: The NodeXL class libraries can be used to display network graphs in .NET applications. To include a NodeXL network graph in a WPF desktop or Windo...NodeXL: Network Overview, Discovery and Exploration for Excel: NodeXL Excel 2007 Template, version 1.0.1.124: The NodeXL Excel 2007 template displays a network graph using edge and vertex lists stored in an Excel 2007 workbook. What's NewThis is a minor re...OpenExpressApp let business people build application: OpenExpressApp for .Net4: 从.Net3.5 SP1 升级到.Net4 ,升级主要内容: 1. 解决了一些内存泄露问题 2. 修改了一些bug 3. 进行了部分代码重构 4. 使用MEF替代了PrismRavenMVC: RavenMVC 0.1: A NoSQL demo app in ASP.NET MVC using RavenDB.SharePoint List Adapters for SSIS: Initial Release: Contains the raw assemblies necessary to use the SharePoint list adapters with basic authentication. See the read me file for details on using in ...Sql Query Modelling Language: Sql Qml V1: This is first versionThumb nail creator and image resizer: ThumbnailCreator 1.0: This is the very first release I built it for my self so it a bit rough but i thought others might fint it usefulluptime.exe: uptime.exe v1.1: Changed the calculation of the uptime. It's now based on the LastbootUpTime value obtained from WMI.VCC: Latest build, v2.1.30526.0: Automatic drop of latest buildViperWorks Ignition: Test: TestXmlCodeEditor: Release 0.91 Alpha: Release 0.91 AlphaXNA Image Reflector: XNA Image Reflector v 1.1: This release has been compiled with XNA Game Studio 3.1, so you will need to download the XNA Runtime 3.1 in order to run it.Xna.Extend: Xna Extend (Ver 0.0.1 beta): This is the betas, betas, beta, test version (Version 0.0.1 beta). It includes only the input and audio components. If you experience any errors, o...XNArkanoid: XNArkanoid v 0.2b: XNArkanoid v 0.2. Initial beta releaseMost Popular ProjectsRawrWBFS ManagerAJAX Control ToolkitMicrosoft SQL Server Product Samples: DatabaseSilverlight ToolkitWindows Presentation Foundation (WPF)patterns & practices – Enterprise LibraryMicrosoft SQL Server Community & SamplesPHPExcelASP.NETMost Active ProjectsAStar.netpatterns & practices – Enterprise Librarypatterns & practices: Windows Azure Security GuidanceSqlServerExtensionsMono.AddinsBlogEngine.NETCustomer Portal Accelerator for Microsoft Dynamics CRMRawrCodeReviewGMap.NET - Great Maps for Windows Forms & Presentation

    Read the article

  • .NET projects build automation with NAnt/MSBuild + SVN

    - by petr k.
    Hi everyone, for quite a while now, I've been trying to figure out how to setup an automated build process at our shop. I've read many posts and guides on this matter and none of them really fits my specifics needs. My SVN repository is laid out as follows \projects \projectA (a product) \tags \1.0.0.1 \1.0.0.2 ... \trunk \src \proj1 (a VS C# project) \proj2 \documentation Then I have a network share, with a folder for each project (product), which in turn contains the binaries, written documentation and the generated API documentation (via NDoc - each project may have an .ndoc file in the repository) for every historical version (from the tags SVN folder) and for the latest version as well (from the trunk). Basically, what I want to do in a scheduled batch build are these steps: examine the project's SVN folder and identify tags not present in the network share for each of these tags check out the tag folder build (with Release config) copy the resulting binaries to the network share search for .ndoc files generate CHM files via NDoc copy the resulting CHM files to the network share do the same as in 2., but for the HEAD revision of trunk Now, the trouble is, I have no idea where to start. I do not keep .sln files in the repository, but I am able to replace these with MSBuild files which in turn build the C# projects belonging to the specific product. I guess the most troubling part is the examination of the repository for tags which have not been processed yet - i.e. searching the tags and comparing them to a project's directory structure on the network share. I have no idea how to do that in any of the build tools (NAnt, MSBuild). Could you please provide me with some pointers on how to approach this task as a whole and in detail as well? I do not care if I use NAnt, MSBuild, or both. I am aware that this might be rather complex, but every idea and NAnt/MSBuild snippet will be a great help. Thanks in advance.

    Read the article

  • The Incremental Architect&acute;s Napkin &ndash; #3 &ndash; Make Evolvability inevitable

    - by Ralf Westphal
    Originally posted on: http://geekswithblogs.net/theArchitectsNapkin/archive/2014/06/04/the-incremental-architectacutes-napkin-ndash-3-ndash-make-evolvability-inevitable.aspxThe easier something to measure the more likely it will be produced. Deviations between what is and what should be can be readily detected. That´s what automated acceptance tests are for. That´s what sprint reviews in Scrum are for. It´s no small wonder our software looks like it looks. It has all the traits whose conformance with requirements can easily be measured. And it´s lacking traits which cannot easily be measured. Evolvability (or Changeability) is such a trait. If an operation is correct, if an operation if fast enough, that can be checked very easily. But whether Evolvability is high or low, that cannot be checked by taking a measure or two. Evolvability might correlate with certain traits, e.g. number of lines of code (LOC) per function or Cyclomatic Complexity or test coverage. But there is no threshold value signalling “evolvability too low”; also Evolvability is hardly tangible for the customer. Nevertheless Evolvability is of great importance - at least in the long run. You can get away without much of it for a short time. Eventually, though, it´s needed like any other requirement. Or even more. Because without Evolvability no other requirement can be implemented. Evolvability is the foundation on which all else is build. Such fundamental importance is in stark contrast with its immeasurability. To compensate this, Evolvability must be put at the very center of software development. It must become the hub around everything else revolves. Since we cannot measure Evolvability, though, we cannot start watching it more. Instead we need to establish practices to keep it high (enough) at all times. Chefs have known that for long. That´s why everybody in a restaurant kitchen is constantly seeing after cleanliness. Hygiene is important as is to have clean tools at standardized locations. Only then the health of the patrons can be guaranteed and production efficiency is constantly high. Still a kitchen´s level of cleanliness is easier to measure than software Evolvability. That´s why important practices like reviews, pair programming, or TDD are not enough, I guess. What we need to keep Evolvability in focus and high is… to continually evolve. Change must not be something to avoid but too embrace. To me that means the whole change cycle from requirement analysis to delivery needs to be gone through more often. Scrum´s sprints of 4, 2 even 1 week are too long. Kanban´s flow of user stories across is too unreliable; it takes as long as it takes. Instead we should fix the cycle time at 2 days max. I call that Spinning. No increment must take longer than from this morning until tomorrow evening to finish. Then it should be acceptance checked by the customer (or his/her representative, e.g. a Product Owner). For me there are several resasons for such a fixed and short cycle time for each increment: Clear expectations Absolute estimates (“This will take X days to complete.”) are near impossible in software development as explained previously. Too much unplanned research and engineering work lurk in every feature. And then pervasive interruptions of work by peers and management. However, the smaller the scope the better our absolute estimates become. That´s because we understand better what really are the requirements and what the solution should look like. But maybe more importantly the shorter the timespan the more we can control how we use our time. So much can happen over the course of a week and longer timespans. But if push comes to shove I can block out all distractions and interruptions for a day or possibly two. That´s why I believe we can give rough absolute estimates on 3 levels: Noon Tonight Tomorrow Think of a meeting with a Product Owner at 8:30 in the morning. If she asks you, how long it will take you to implement a user story or bug fix, you can say, “It´ll be fixed by noon.”, or you can say, “I can manage to implement it until tonight before I leave.”, or you can say, “You´ll get it by tomorrow night at latest.” Yes, I believe all else would be naive. If you´re not confident to get something done by tomorrow night (some 34h from now) you just cannot reliably commit to any timeframe. That means you should not promise anything, you should not even start working on the issue. So when estimating use these four categories: Noon, Tonight, Tomorrow, NoClue - with NoClue meaning the requirement needs to be broken down further so each aspect can be assigned to one of the first three categories. If you like absolute estimates, here you go. But don´t do deep estimates. Don´t estimate dozens of issues; don´t think ahead (“Issue A is a Tonight, then B will be a Tomorrow, after that it´s C as a Noon, finally D is a Tonight - that´s what I´ll do this week.”). Just estimate so Work-in-Progress (WIP) is 1 for everybody - plus a small number of buffer issues. To be blunt: Yes, this makes promises impossible as to what a team will deliver in terms of scope at a certain date in the future. But it will give a Product Owner a clear picture of what to pull for acceptance feedback tonight and tomorrow. Trust through reliability Our trade is lacking trust. Customers don´t trust software companies/departments much. Managers don´t trust developers much. I find that perfectly understandable in the light of what we´re trying to accomplish: delivering software in the face of uncertainty by means of material good production. Customers as well as managers still expect software development to be close to production of houses or cars. But that´s a fundamental misunderstanding. Software development ist development. It´s basically research. As software developers we´re constantly executing experiments to find out what really provides value to users. We don´t know what they need, we just have mediated hypothesises. That´s why we cannot reliably deliver on preposterous demands. So trust is out of the window in no time. If we switch to delivering in short cycles, though, we can regain trust. Because estimates - explicit or implicit - up to 32 hours at most can be satisfied. I´d say: reliability over scope. It´s more important to reliably deliver what was promised then to cover a lot of requirement area. So when in doubt promise less - but deliver without delay. Deliver on scope (Functionality and Quality); but also deliver on Evolvability, i.e. on inner quality according to accepted principles. Always. Trust will be the reward. Less complexity of communication will follow. More goodwill buffer will follow. So don´t wait for some Kanban board to show you, that flow can be improved by scheduling smaller stories. You don´t need to learn that the hard way. Just start with small batch sizes of three different sizes. Fast feedback What has been finished can be checked for acceptance. Why wait for a sprint of several weeks to end? Why let the mental model of the issue and its solution dissipate? If you get final feedback after one or two weeks, you hardly remember what you did and why you did it. Resoning becomes hard. But more importantly youo probably are not in the mood anymore to go back to something you deemed done a long time ago. It´s boring, it´s frustrating to open up that mental box again. Learning is harder the longer it takes from event to feedback. Effort can be wasted between event (finishing an issue) and feedback, because other work might go in the wrong direction based on false premises. Checking finished issues for acceptance is the most important task of a Product Owner. It´s even more important than planning new issues. Because as long as work started is not released (accepted) it´s potential waste. So before starting new work better make sure work already done has value. By putting the emphasis on acceptance rather than planning true pull is established. As long as planning and starting work is more important, it´s a push process. Accept a Noon issue on the same day before leaving. Accept a Tonight issue before leaving today or first thing tomorrow morning. Accept a Tomorrow issue tomorrow night before leaving or early the day after tomorrow. After acceptance the developer(s) can start working on the next issue. Flexibility As if reliability/trust and fast feedback for less waste weren´t enough economic incentive, there is flexibility. After each issue the Product Owner can change course. If on Monday morning feature slices A, B, C, D, E were important and A, B, C were scheduled for acceptance by Monday evening and Tuesday evening, the Product Owner can change her mind at any time. Maybe after A got accepted she asks for continuation with D. But maybe, just maybe, she has gotten a completely different idea by then. Maybe she wants work to continue on F. And after B it´s neither D nor E, but G. And after G it´s D. With Spinning every 32 hours at latest priorities can be changed. And nothing is lost. Because what got accepted is of value. It provides an incremental value to the customer/user. Or it provides internal value to the Product Owner as increased knowledge/decreased uncertainty. I find such reactivity over commitment economically very benefical. Why commit a team to some workload for several weeks? It´s unnecessary at beast, and inflexible and wasteful at worst. If we cannot promise delivery of a certain scope on a certain date - which is what customers/management usually want -, we can at least provide them with unpredecented flexibility in the face of high uncertainty. Where the path is not clear, cannot be clear, make small steps so you´re able to change your course at any time. Premature completion Customers/management are used to premeditating budgets. They want to know exactly how much to pay for a certain amount of requirements. That´s understandable. But it does not match with the nature of software development. We should know that by now. Maybe there´s somewhere in the world some team who can consistently deliver on scope, quality, and time, and budget. Great! Congratulations! I, however, haven´t seen such a team yet. Which does not mean it´s impossible, but I think it´s nothing I can recommend to strive for. Rather I´d say: Don´t try this at home. It might hurt you one way or the other. However, what we can do, is allow customers/management stop work on features at any moment. With spinning every 32 hours a feature can be declared as finished - even though it might not be completed according to initial definition. I think, progress over completion is an important offer software development can make. Why think in terms of completion beyond a promise for the next 32 hours? Isn´t it more important to constantly move forward? Step by step. We´re not running sprints, we´re not running marathons, not even ultra-marathons. We´re in the sport of running forever. That makes it futile to stare at the finishing line. The very concept of a burn-down chart is misleading (in most cases). Whoever can only think in terms of completed requirements shuts out the chance for saving money. The requirements for a features mostly are uncertain. So how does a Product Owner know in the first place, how much is needed. Maybe more than specified is needed - which gets uncovered step by step with each finished increment. Maybe less than specified is needed. After each 4–32 hour increment the Product Owner can do an experient (or invite users to an experiment) if a particular trait of the software system is already good enough. And if so, she can switch the attention to a different aspect. In the end, requirements A, B, C then could be finished just 70%, 80%, and 50%. What the heck? It´s good enough - for now. 33% money saved. Wouldn´t that be splendid? Isn´t that a stunning argument for any budget-sensitive customer? You can save money and still get what you need? Pull on practices So far, in addition to more trust, more flexibility, less money spent, Spinning led to “doing less” which also means less code which of course means higher Evolvability per se. Last but not least, though, I think Spinning´s short acceptance cycles have one more effect. They excert pull-power on all sorts of practices known for increasing Evolvability. If, for example, you believe high automated test coverage helps Evolvability by lowering the fear of inadverted damage to a code base, why isn´t 90% of the developer community practicing automated tests consistently? I think, the answer is simple: Because they can do without. Somehow they manage to do enough manual checks before their rare releases/acceptance checks to ensure good enough correctness - at least in the short term. The same goes for other practices like component orientation, continuous build/integration, code reviews etc. None of that is compelling, urgent, imperative. Something else always seems more important. So Evolvability principles and practices fall through the cracks most of the time - until a project hits a wall. Then everybody becomes desperate; but by then (re)gaining Evolvability has become as very, very difficult and tedious undertaking. Sometimes up to the point where the existence of a project/company is in danger. With Spinning that´s different. If you´re practicing Spinning you cannot avoid all those practices. With Spinning you very quickly realize you cannot deliver reliably even on your 32 hour promises. Spinning thus is pulling on developers to adopt principles and practices for Evolvability. They will start actively looking for ways to keep their delivery rate high. And if not, management will soon tell them to do that. Because first the Product Owner then management will notice an increasing difficulty to deliver value within 32 hours. There, finally there emerges a way to measure Evolvability: The more frequent developers tell the Product Owner there is no way to deliver anything worth of feedback until tomorrow night, the poorer Evolvability is. Don´t count the “WTF!”, count the “No way!” utterances. In closing For sustainable software development we need to put Evolvability first. Functionality and Quality must not rule software development but be implemented within a framework ensuring (enough) Evolvability. Since Evolvability cannot be measured easily, I think we need to put software development “under pressure”. Software needs to be changed more often, in smaller increments. Each increment being relevant to the customer/user in some way. That does not mean each increment is worthy of shipment. It´s sufficient to gain further insight from it. Increments primarily serve the reduction of uncertainty, not sales. Sales even needs to be decoupled from this incremental progress. No more promises to sales. No more delivery au point. Rather sales should look at a stream of accepted increments (or incremental releases) and scoup from that whatever they find valuable. Sales and marketing need to realize they should work on what´s there, not what might be possible in the future. But I digress… In my view a Spinning cycle - which is not easy to reach, which requires practice - is the core practice to compensate the immeasurability of Evolvability. From start to finish of each issue in 32 hours max - that´s the challenge we need to accept if we´re serious increasing Evolvability. Fortunately higher Evolvability is not the only outcome of Spinning. Customer/management will like the increased flexibility and “getting more bang for the buck”.

    Read the article

  • Neural Networks in C# using NeuronDotNet

    - by kingrichard2005
    Hello, I'm testing the NeuronDotNet library for a class assignment using C#. I have a very simple console application that I'm using to test some of the code snippets provided in the manual fro the library, the goal of the assignment is to teach the program how to distinguish between random points in a square which may or may not be within a circle that is also inside the square. So basically, which points inside the square are also inside the circle. Here is what I have so far: namespace _469_A7 { class Program { static void Main(string[] args) { //Initlaize the backpropogation network LinearLayer inputLayer = new LinearLayer(2); SigmoidLayer hiddenLayer = new SigmoidLayer(8); SigmoidLayer outputLayer = new SigmoidLayer(2); new BackpropagationConnector(inputLayer, hiddenLayer); new BackpropagationConnector(hiddenLayer, outputLayer); BackpropagationNetwork network = new BackpropagationNetwork(inputLayer, outputLayer); //Generate a training set for the ANN TrainingSet trainingSet = new TrainingSet(2, 2); //TEST: Generate random set of points and add to training set, //for testing purposes start with 10 samples; Point p; Program program = new Program(); //Used to access randdouble function Random rand = new Random(); for(int i = 0; i < 10; i++) { //These points will be within the circle radius Type A if(rand.NextDouble() > 0.5) { p = new Point(rand.NextDouble(), rand.NextDouble()); trainingSet.Add(new TrainingSample(new double[2] { p.getX(), p.getY() }, new double[2] { 1, 0 })); continue; } //These points will either be on the border or outside the circle Type B p = new Point(program.randdouble(1.0, 4.0), program.randdouble(1.0, 4.0)); trainingSet.Add(new TrainingSample(new double[2] { p.getX(), p.getY() }, new double[2] { 0, 1 })); } //Start network learning network.Learn(trainingSet, 100); //Stop network learning //network.StopLearning(); } //generates a psuedo-random double between min and max public double randdouble(double min, double max) { Random rand = new Random(); if (min > max) { return rand.NextDouble() * (min - max) + max; } else { return rand.NextDouble() * (max - min) + min; } } } //Class defines a point in X/Y coordinates public class Point { private double X; private double Y; public Point(double xVal, double yVal) { this.X = xVal; this.Y = yVal; } public double getX() { return X; } public double getY() { return Y; } } } This is basically all that I need, the only question I have is how to handle output?? More specifically, I need to output the value of the "step size" and the momentum, although it would be nice to output other information as well. Anyone with experience using NeuronDotNet, your input is appreciated.

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 413 414 415 416 417 418 419 420 421 422 423 424  | Next Page >