|
You could implement the jostling of the break valve as an event driven interface on a linked list and use a generic func type to adjust the values in the list, the list would contain the ascending and descending pressure values.
Once you find the right math....
|
|
|
|
|
Easier said than done. That's pretty close to the concept I have been working with -- keeping a list of "pressure zones" (sub-divisions of the brake pipe according to how far air can travel in one computation cycle) and trying to do relative comparisons of pressure from zone to zone. But there are a lot of complications that present themselves once you really dig into it.
|
|
|
|
|
FWIW: I did not read the article, but from your description it sounds like an "RC ladder network" (example[^] with each Y a capacitor (holding air), and each Z a resistor (preventing "air" to flow from one capacitor to the next). Such networks are pretty simple to simulate in the time-domain. I haven't done it recently, I did hundreds of those some decades ago.
ADDED
the ref to the book was mainly to the diagram; I am not suggesting one starts calculating transfer functions or Laplace transforms, a simple delta-V over delta-T simulation should do.
/ADDED
|
|
|
|
|
I read the article, very interesting. I think I'll stick to my Allen 10 Wheeler.
Dave.
|
|
|
|
|
I have a square that is created in 2D points that can be dragged about and it rotates depending on where the mouse drags ect.
The problem I am facing is getting the angle in radians as there is a texture that I would like to apply over the wireframe.
I have this so far to get the angle:
void GetAngle()
{
float dx = Points[0].Position.X - Points[1].Position.X;
float dy = Points[0].Position.Y - Points[1].Position.Y;
float angle = (float)Math.Atan2(dy, dx);
_angle = angle;
}
This works fine apart from that when the square is rotate (points) the texture rotates accordingly but its position changes, here is a screen shot of the issue.
http://img339.imageshack.us/img339/7786/captureas.png[^]
The texture should be inside the wire-frame.
If i rotate it to the left instead to the right the texture is below the wireframe!
This is a link to the project :
http://www.mediafire.com/?2i62poeedyw192n[^]
It is in C# and uses the XNA game programming engine.
Thanks for your help! 
|
|
|
|
|
You need to rotate around the CENTER of your object.
Find the coordinates of the center (xCenter, yCenter), then subtract this point from all the points in your object, do the rotation, and finally add (xCenter, yCenter) back to each rotated point.
|
|
|
|
|
I figured out a better way! (although when you here it you may laugh...)
In the rendering of the spritebatch the "position" argument is Point[0].Position and the origin is Vector2.Zero xD
Simple yet for some reason I didn't get it straight away 
Thank you though, that way would had worked well ! 
|
|
|
|
|
I have a program where a (indirect) recursive call to a certain function is forbidden.
It could easily introduce bugs that are hard to find.
(This function is the "core" of a finite state machine)
For now I throw an exception if someone still makes a recursive call to this function.
But if a certain condition never happens during debugging,
the recursive call might stay in the program.
It made me wonder if there is a feature in some compilers
(doesn't matter what language, any language. this is a very general question)
that detects recursion of a function and gives a warning/error
during compilation?
|
|
|
|
|
Define a static variable for the function you're trying to protect from recursion, and give it an initial value.
Then at the beginning of the function, test this variable and throw an exception if it DOESN'T have this initial value. If it does, set the variable to a different value, then reset it to the initial value just before you leave the function.
This detects recursion at run time. A few languages (like PL/I) require you to declare recursive functions as "recursive", but as far as I know, most languages won't allow you to detect and prevent recursion at compile time.
|
|
|
|
|
It's not a compiler function, but I believe there are code analysers out there that can build a (static) call graph. Loop in graph <=> recursive calls. Of course if you're using dynamic calling mechanisms (C: function pointers, Java, etc: reflection) you can hide recursion from static analysers, but that might be within the scope of manual checking. Of course, FSMs generally use such mechanisms, so you might wind up back where you started... Such is life. [Famous last words of one Ned Kelly, Australian Bushranger.]
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
|
OpenCL uses a subset of C-99 that explicitly does not allow recursion. to answer one of your questions.
|
|
|
|
|
I'm laying out various objects (FrameworkElements) on a surface (Canvas) and I've implemented all the usual algorithms for aligning them vertically (top, bottom and middle) and horizontally (left, right and center). Now I want to implement a distribute function that will evenly distribute selected objects. Now this would be easy if the all the objects are the same size (find the left most and right most objects, divide the space between them by the number of objects and then set the positions of the objects), but it's a bit more complicated when objects potentially have different sizes.
My brain feels a little backed up right now, is there a well-known and easy algorithm for doing this?
|
|
|
|
|
You need to define the goals of your layout. The vagueness of your task definition is what's making it seem difficult.
A good starting point would be asking yourself WHY the straightforward distribution is unsatisfactory when the objects have different sizes.
|
|
|
|
|
Okay, here's what I have. It seems to produce reasonable results, but I'm open to suggestions for making it more efficient (also, there might be flaws in my logic that I just haven't found yet). For distributing objects horizontally:
- Give an set of objects
- Iterate through the set and find the object with the left-most edge (leftObj) and the value for its left edge (left), and the object with the right-most edge (rightObj) and the value for its right edge (right). Left and right define the limits of my space and leftObj and rightObj don't need to be moved.
- The range in which to distribute the remaining objects is the (left-most edge of rightObj) - (right-most edge of leftObj).
- Now, from my set of objects, I must remove leftObj and rightObj (since they don't move) and sort the remaining objects by their left-most edge (maybe center would be better here?)
- Iterate through my new set of objects and subtract the widths of each object from the range. What's left at the end is the space I need to distribute between the remaining objects.
- Define step as the remaining range divided by the number of object remaining plus 1.
- Define position (where to put the first object) as the right-most edge of leftObj + step.
- Iterate through the remaining objects - for each object set the left-most edge to position. Then increase position by step + the width of this object.
So there you have it. I have to iterate through my list of objects at least 3 times, and I need to sort them once. The number of objects is never likely to be very large, and execution speed on my development laptop is essentially instant, but that doesn't mean I'm not interested in how to make it more efficient purely from an academic point-of-view.
|
|
|
|
|
Sorting the objects first would avoid having to search for the leftmost and rightmost objects; after the sort they're the first and last objects. That's the only optimization I can see.
|
|
|
|
|
Well, I thought that too, but there is a problem with that. If I sort them by the left-most edge, then it's possible that the item with the highest left-most edge isn't the right-most object if there is another object that has a smaller left-most edge (i.e. is further to the left), but it wider such that it's right-most edge is actually more to the right. And the same is possible if you use right edges instead (but on the left-side instead).
So I'm not sure that there is a search criteria that will always guarantee that the first element with be the left-most and the last element will be the right-most.
{-A-} {-B-}
{---C----} {---D---}
Example: if a sort by left-edge ({), C is the left-most element, and B is the right-most. If a sort by right-edges (}), A is the left most and D is the right-most. Neither of these is correct!
|
|
|
|
|
As I suspected, the problem appears to be in the task definition.
From your description, it appears the most extreme coordinates are the most relevant. You might try sorting from the outside in:
1. Get the leftmost element, and make that the first item in your "sorted" list. (It's not a real sort, because what we have here is called a "partial order".)
2. Get the rightmost element, and make that the LAST item in the sorted list.
3. Get the second-leftmost element and make that the second item in the sorted list.
4. Get the second-rightmost element and make it the next-to-last item in the sorted list.
5. Repeat until you reach the middle item.
|
|
|
|
|
An interesting idea. I might try that.
|
|
|
|
|
I guess one place that technique might fall down would be if you had this:
....[A].......[B]..[C].....
..[..........D..........]..
Which when distributed should probably look like this:
.....[A]....[B]....[C].....
..[..........D..........]..
In this case D is both the left-most and right-most element!
|
|
|
|
|
That's a consequence of treating a partial order like a total order.
If you want to try to sort these elements, D must either appear at the left or the right. The algorithm you design should reflect your goals, and if your goals are unclear it makes finding a solution many times harder.
|
|
|
|
|
I'm not sure what it is you want. Is this a two-dimensional problem? or are these objects grouped into N rows, so it becomes N 1-dimensional problems? I suggest you clarify by providing one or two examples with initial situation and probable solution. Using PRE tags (hence non-proportional font) should work fine.
AAA...BB
AAA...BB
......BB
CC......
CC..DDDD
|
|
|
|
|
It appears to be a two-dimensional problem, where each dimension can be treated independently, so it becomes two one-dimensional problems.
|
|
|
|
|
I'm trying to implement functionality very similar to what PowerPoint does.
Example:
- Open PowerPoint
- On a blank slide, throw a bunch of boxes on the slide.
- Select several boxes.
- (In PowerPoint 2003, probably different in newer versions)Click Draw on the toolbar at the bottom, select "Align or Distribute" -> "Distribute Horizontally"
So, if you start with this (collapsing everything to one dimension for clarity):
....[A].....[B].....[C]..[D]...
You end up with this:
....[A]....[B]....[C]....[D]...
This is fairly trivial if all the boxes are the same size, but when they are different sizes, it gets a bit trickier (adding a second dimension only to make overlaps clearer - it's still a 1D problem):
.......[...B...]............[D]...
....[.A.]............[..C..]......
Should give:
..........[...B...].........[D]...
....[.A.]...........[..C..].......
|
|
|
|
|
if it is really one-dimensional, then it is trivial: the spaces should equal
( available_width - sum_of_widths_of_objects_in_row ) / ( number_of_objects_in_row - 1 )
it becomes interesting when it is actually a 2D problem, i.e. some blocks have multiple neighbours on one side, not all of the same width, as in:
AAAA......DD.....GGG
AAAA.............GGG
........CCCCCCC..GGG
BBBBBB..CCCCCCC..GGG
........CCCCCCC.....
EE..F...CCCCCCC...HH
....F.............HH
KKK.F....LLLL.....HH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
