|
|
Can you explain what you actually are doing with the XOR's, what is the mathematics behind it? Im really curios about it.
modified 18-Apr-13 13:05pm.
|
|
|
|
|
|
Or you can combine two iterations so there is no swap:
private static ulong GetFib3(int n)
{
ulong a = 0;
ulong b = 1;
if (n == 0) return a;
if (n <= 2) return b;
if ((n & 1) == 0)
{
a = 1;
n--;
}
int i = n - 1;
do
{
a += b;
b += a;
i -= 2;
} while (i != 0);
return b;
}
|
|
|
|
|
Thanks for the implementation. I will compare your attempt along others posted in this thread later this day.
|
|
|
|
|
Good idea.
private static ulong
Fibo2
(
int n
)
{
ulong a = (ulong) n & 1 ;
ulong b = a ^ 1 ;
for ( n /= 2 ; n > 0 ; --n ) checked { a += b += a ; }
return ( a ) ;
}
(This version performs an extra add that I'm trying to eliminate.) Fixed. 
modified 20-Apr-13 23:17pm.
|
|
|
|
|
"
if (n == 0) return a;
if (n == 1) return b;
"
Unnecessary, wastes cycles.
"
a ^= b;
b ^= a;
a ^= b;
"
Saves a few bytes, but wastes cycles.
And yours returns 1 for n<0.
Here's a version that swaps indices rather than values.
private static ulong[] a = new ulong [ 3 ] ;
private static ulong
Fibo
(
int n
)
{
a [ 0 ] = a [ 1 ] = 0 ;
a [ 2 ] = 1 ;
int x = 2 ;
int y = 1 ;
for ( ; n > 0 ; --n )
{
a [ 0 ] = a [ x ] += a [ y ] ;
x ^= 3 ;
y ^= 3 ;
}
return ( a [ 0 ] ) ;
}
modified 21-Apr-13 1:01am.
|
|
|
|
|
Hello All,
Project Brief:
I am wanting to create a program to allow the user to model a series of beams for a structural analysis program. There are many similar programs available on the web. You create nodes (points) in 3D space, link them together with members (lines) and then apply various loads and conditions to these elements. The project will consist mostly of 3D graphics (drawing primitives) which the user can interact with in order to enter the required data.
My History:
I am a structural engineer, not a software engineer, but I do a reasonable amount of coding in my free time. I am mostly familiar with Python but I have started learning C# which I feel is probably a better fit for this project. I will probably take the Winforms option for now since it a bit simpler for me to understand and will let me focus more on the structure of the program rather than the
The Question:
I would really appreciate advice on how to structure the program so I start out on the right track. My biggest question is how should I store all of the program data the user enters. I was thinking of using a database like sqlite3 so the file type for the model becomes *.db. Other options are wrapping everything up in a class (which holds node, member, loading info etc) and then dump as xml. I don’t know which option is better or even if there are other options out there. Using a database seem logical to me since the data will be somewhat relational, I just do not have the foresight to see if there are hidden challenges with this.
Any other adviCe you can give for implementing this project in C# would also be greatly appreciated.
Thanks all for your time.
Regards Jake
|
|
|
|
|
Why do you need to roll your own solution. What do the other packages out there not provide?
Autodesk would seem like a good fit if it solves the problem(s) you need.
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan
That's what machines are for.
Got a problem?
Sleep on it.
|
|
|
|
|
Jacob Barton wrote: There are many similar programs available on the web.
What is your unique requirement that these many apps can't service.
PHP is not going to be much use to you for a winforms app  . Seriouslydoing a project of this type is not a trivial pursuit, be certain you really need to embark on it. Especially with your limited skill set.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: What is your unique requirement that these many apps can't service.
Primary Reason:
These applications are a one shoe fits all solution. They are made to service the largest community available so they can maximize their user base. There are many different engineering problems that require slightly different design solutions and this is often achieved by using multiple software packages and hand calculations. Yes this works, but it can be more efficient. The base functionality of my program will be the same as others (to a certain degree), it is the ability to add additional functionality for performing routine design tasks (specific to my particular applications) that I am most interested in.
Secondary Reasons:
1) Seems like a good project to learn OpenGL and fundamentals behind interaction with 3D scenes
2) Expands my skill base so the next time I want to undertake a ambitious project I know what skills I can leverage off.
3) I enjoy learning new things
4) I'm an engineer, making things harder then they need to be is part of my job 
If you look at how these programs work, they are not overly complex. I see graphics as my biggest challenge by far. Sure, implementing the design is not trivial which is why I asked for help. I don't care if I don't get it right the first time, but some bread crumbs to follow would be nice.
Many thanks,
Jake
|
|
|
|
|
None of which I can argue with, I consider rolling your own a primary mark of a good developer. As long as you are making this to your requirements and don't try and do the another one shoe fits all, scope creep is going to be a major irritant. If it is not core to your needs don't try and build it into your first attempt.
Unlike POH I would go for a relational database, but that is what I do, LOB apps, not engineering based calculators/modellers.
Do keep notes on your progress it could turn into an interesting article.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
A database would be a fine choice. You could go with something like sqllite or you could go with a NoSQL database like MongoDB. If I were looking to associate documents with these beams (might be an interesting addition), then I'd definitely lean towards a NoSQL solution over a traditional relational database.
|
|
|
|
|
Thanks Pete will take that on board and look into NoSQL. Are databases frequently used in this type of application (i.e. as a main filetype for an application)?
|
|
|
|
|
I've used them for this. Some companies prefer to roll their own code, but ultimately they end up creating proprietary databases.
|
|
|
|
|
Your first task is to define exactly what you want to store, and how the data is used. For instance (haven't done any structural engineering calculations since college mumble years ago, so this is uninformed):
- Can nodes be re-used (ie serve as end points for multiple beams)?
- Should join strength be a variable or ideal?
- Is there a common joint, or are one connected to side of other?
- Can you have multiple load vectors on each beam?
- What types of load do you want to model (of the five classic)?
- Do you want to distinguish between, for want of a better term, primary (entered by user) and secondary (calculated and distributed over the structure) loads?
The answers to these and similar questions should help you model the application and storage. Always start with function, and let form (e.g. GUI and storage model) follow.
For instance, I'd probably keep nodes, members and primary and secondary loads separate in a relational database, and let the loads have a relationship to a member, which has a relationship to two nodes. So that's four tables of data to start you with.
Oh, and I'd recommend using a database even if the data amount isn't going to be massive. The benefit of having a proper relational structure outweighs the extra work needed to manage it.
|
|
|
|
|
Pete, Orjan, thanks for the helpful posts.
Orjan Westin wrote: For instance, I'd probably keep nodes, members and primary and secondary loads separate in a relational database, and let the loads have a relationship to a member, which has a relationship to two nodes. So that's four tables of data to start you with.
Orjan, this is what I had in mind. I will probably start with node loads, concentrated member loads and uniform (trapezoidal) member loads. I think the database approach will keep things scalable if I decide to go further than this.
|
|
|
|
|
What you are looking for is called "choosing a design pattern" and in most cases, if you use a known design pattern, it saves time and frustration. For this project, I would suggest MVC - Model-View-Controller as your design pattern. It is an old design pattern, been around since the 60s, but it's enjoying a little bit of renaissance because Microsoft recently published a framework to help implement MVC in web sites... so, many programmers are just discovering this design pattern right now and you'll be able to find lots of blogs and information about it. Keep in mind that while the main architecture will be MVC, you will be using other design patterns at lower levels. Knowing design patterns can help with the decision you're faced with - namely, how do I start?
So here's how it would break down for your app....
Model - this is where you keep all the code that describes the real world. So, how to calculate stresses, how to store the data, all your component objects. Many developers think of the model as "only the database" but it's really supposed to be a model. Use this layer to keep code and data that represents a model of the real-world situation.
View - this is obviously the visual component. It takes model data passed to it by the controller, and renders the model in some visually compelling way for the user.
Controller - This is where the interface logic resides, and it does exert control over the view and the model - it passes data to the model for updating, and retrieves data to put into the view.
SO... can you see why, for an engineering application, this might be good? What if, for example, you wanted to web-enable your windows app? You don't have to do a complete re-write, you only have to make a web-based View.
Here's some articles...
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller[^]
http://en.wikipedia.org/wiki/Software_design_pattern[^]
|
|
|
|
|
I would consider using Windows Presentation Foundation (WPF) instead of WinForms; I think you'll have better results and better resources. 2 references I would recommend:
Practical WPF Charts and Graphics - Jack Xu
Practical WPF Graphics Programming - Jack Xu
I would suggest designing and prototyping your (data) "model" before deciding on you data store; i.e. "database". You might find that serializing / deserialing to / from XML or binary is a lot easier; particularly as your model evolves (i.e. "no database changes"). It's also easier to view / edit the data and relations in an XML file (using XML NotePad for example) in the early stages.
|
|
|
|
|
Jacob Barton wrote: My biggest question is how should I store all of the program data the user
enters
In terms of the application and what you described it probably doesn't matter.
What you should do however is create a persistence layer. That layer is ENTIRELY responsible for taking your data and storing it and retrieving it.
Then you implement one or more of the following.
1. A persistence layer that stores it in xml in a file.
2. A persistence layer that stores it in file using your own format: binary or text.
3. A persistence layer that stores it in some database.
Ideally you should have 1 or 2 along with 3. If you cannot switch them out without modifying the rest of your application (and no tricks involved) then your persistence layer is not clean. Otherwise it is good to go.
|
|
|
|
|
Jasmine, thank you "design pattern" is the terminology I was chasing. I have done an intro into programming course at Uni where they introduced this and I have created a few smaller applications using this approach. Web frameworks like Django have recently made me more aware of how powerful serparating the different layers of your application can be. Thanks for the links.
Gerry Schmitz wrote: I would consider using Windows Presentation Foundation (WPF) instead of WinForms; I think you'll have better results and better resources.
Gerry, would you mind elaborating on this a little if you don't mind. I have searched winforms vs. WPF to death and from what I can tell data binding and visual effects/appearance seem to be the highest selling points. Every article is almost the same "winforms will be around for a while to come, WPF is **better** but be prepared for a steep learning curve.". I have thought of using WPF so I can use WPF 3D instead of OpenGL but I am unsure.
jschell wrote:
What you should do however is create a persistence layer. That layer is ENTIRELY responsible for taking your data and storing it and retrieving it.
jschell,
What I am thinking of is having a DAL to retrieve and add to my database (application file). By doing this, I assume I will only need to store node / member information in the database (i.e. there is no need to store them inside the application as members of a class etc, just query the DB when their properties are required for drawing on screen etc). If I do this, do I need this layer you mentioned? I can understand it would be useful if I had everything wrapped up in my own class and just needed to read / dump to file on file open / save events. I will try goggling for persistent layers and see what I can learn on the subject.
Thanks all for you advice so far - Jake
|
|
|
|
|
It tends to help to have an abstraction to represent anything more conceptually complex than a single number. That way, you can talk about a "node" and its properties in your code, for instance. This would let both the drawing code, the calculating code, and the storage code work with a node, and not worry about where the data comes from or is used, other than what those modules need.
Assuming you have a structure with a number of nodes, members and loads (all interconnected objects of different classes), you'd retrieve this from storage, and build it up in memory. In this case, it doesn't matter whether the storage is a database, an XML file, or the pattern in a scanned-in image, as long as the storage layer knows how to extract the data. And the storage layer is only concerned with storing and retrieving data, not how it's used.
Similarly, the drawing module would only need to know how to translate your model to points and lines the rendering engine can use, so it wouldn't need to know how the model was created.
If you were to retrieve the data needed for drawing every time it's needed, it would be very inefficient and slow, and it would make it much harder to change storage method (for instance, if you decided to set up a department database with shared models).
While I'd warn against object orientation frenzy (which is where everything is shoehorned into a huge inheritance framework whether it fits or not), it might be a good idea to read up on encapsulation and abstraction and object-oriented design (I tend to recommend Grady Booch's "Object Oriented Analysis and Design" as the go-to book).
|
|
|
|
|
You'll want to use OpenGL - it's a standard in the industry, and using OpenGL will make your code more portable. Also, when building applications of this size, it is important to work from a priority list - and I mean actually write it down. Figure out what is most important, and put your effort there, and use frameworks and RAD tools to do the rest.
Since the interface isn't the important thing here, I would suggest making the interface very simple and using WinForms - it isn't worth it to you to go and learn WPF for this project because the visual interface part will probably be the easiest part of the app, and it's the least critical part too. The calculating of your results is where you want to focus your efforts. You have a large set of objects to design, and you need to focus on that. WinForms will let you design a good interface without putting a lot of effort into it.
On Data Access Layers - this is a design pattern, though there's many names for it. You will almost always create a DAL of some sort. For this application, I personally think you should go with some kind of Object-Relational mapping (another design pattern), such as the Entity Framework. With EF, you can do things two ways, database first or code first. So, you can design all your objects in C# code, then the Entity Framework can build a database for you, to store those objects. You can go the other way too - design a database and the EF can write C# code for the objects defined by the database. As you can see, this lets you focus on the important things about your data, instead of the "trivial" wiring between your app and the database. Object-Relational mapping is a known thing - let the machines do it.
Almost every modern application has a database of some kind, and for many years it's always been a relational database like SQL Server or Oracle. However, for "big data" and repetitive but small calculations, it may be better for you to use a "No SQL" type of database such as Hadoop - but I personally don't think your data will be "big" enough to warrant that. Either way, if you build your data layer as a separate module, you can swap it out later if you need to. That is the primary purpose of a separate data layer - to isolate the rest of the application from the mechanics of dealing with the database server. So basically, to answer your question, YES, you always need a data layer. Whether it will be implemented by a SQL server, No Sql server, or file system is unknown at the moment, but there will be a persistence layer of some kind for your data so you can save and load. It is important to think of it as a separate layer right from the start.
I'll let you do the Googling (EF, ORM, No SQL, etc), but are you starting to understand why apps like this are typically built by teams?
Oh also, please "reply" to our messages - I would have missed that your discussion was continuing because if you don't "reply" to us, we don't get emails. I came back here because I found your question interesting and well-stated, and that's rare.
|
|
|
|
|
Jacob, regarding WPF:
There might be a steeper learning curve with WPF, but only if you’re already steeped in WinForms. Because the “layout” model (XAML), wiring, and types of controls can be different from WinForms, it requires a mind-shift (like procedural versus object-oriented versus functional). If you’re “clear” or open-minded, picking up WPF is a lot easier.
(You’re also going to find a lot more graphics samples in WPF that you can use as building blocks; I would never suggest starting something completely from scratch. The Windows SDK will also have WPF samples).
WPF “Binding” might be (a little) difficult (because it is more flexible), but if you’re doing “graphics programming”, you will probably be less concerned with binding; you’ll will mostly be manipulation and animating graphics objects via code and “story boards”; WPF has better animation support (using “story boards”) than WinForms.
WPF has better built-in graphics support via “shapes”, “paths”, “brushes”, geometry, rotating, transforming, cameras; i.e. it is more object-oriented when it comes to graphics than WinForms; with WinForms, you are more-or-less working with pixels (IMO).
I started out with WinForms; pooh-poohed WPF at one time because it did not have a native “grid” (at that time); then was hired a few years ago to do a SCADA application in WPF, and have never looked back.
|
|
|
|
|
I would definitely echo Jasmine2501 comments on design patterns.
If you have time get yourself, and read, a copy of this book Headfirst Design Patterns[^].
It is easy to read, has lots of examples(in Java but, heck Java is virtually C#) and is not one of those university computer science style books, and well explained introduction to design patterns.
The reason I recommend this is once you get your thinking working along the design patterns route you will probably find that all the coding falls into place(my probably over-simplistic take on design patterns...).
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
