Comments and Ratings

Now improved with accompanying source files, this contribution will be a great reference for users who are beginning to experiment with basic animated plots or guis.
Well done Husam.

Hi Darren,
I thought it would be better if new users wrote the codes themself. All they have to do is rewrite the examples found in the slides in their own editor menu. That way their fingers will get used to writing code and the information will stick.

Thank you for your suggestion; I will include the example m files in the next update.

I think that this submission is just slightly lacking. The slides are reasonably informative, but while I was reading them I couldn't help but think that it would be good for a new Matlab user to be able to try out the examples. Unfortunately the corresponding files are not included. I hope Husam can include the files to help beginners get started straight away.
Darren.

I see some changes have been made. These extra comments really help the person reading the code. My thanks there.

Personally, I'd still hope that beginning PE solvers try the problem first, before looking at this. Only afterwards should you read through this submission to compare this code to yours. But this is a reasonable approach to the problem.

I'll still abstain on an actual rating, but if I were to give this a numeric rating, my rating would be a decent one.

You're right, this is due to the new MUPAD engine. On MATLAB versions earlier than the MuPad era the code should work fine. I will try to fix this problem as soon as possible.

at STRB2 function is probably infinite while loop problem

Very well done.

haha, this is a good and a funny one, good job husam, keep on..

This looks like it would be nice, though I do not have the symbolic TB to put it through its paces, so I will not offer a rating. It is an alternative to my own polyfitn, with output directly into a sym form.

A couple of comments. (Surely you would not expect me to have nothing to say.) Good help. I like to see verbose help, even when some others have been known to say my help is too verbose. I want all of the questions answered in my help, and this help made an effort. I like the examples. Error checks, and an H1 line. All good.

The code itself looks like it was carefully written, but as I said, I could not test it. I had a couple of style points though. I'd rarely recommend the use of variable names like "kkksdgsdg". When you need to debug the code, reading it will be more difficult in a year or so because of a randomly chosen string of characters. I know, sometimes it is difficult to come up with a mnemonic name, but you can try harder than that.

Also, use internal comments. This code has virtually none, except for a credit to Roger Stafford. (Well done there. It is always good to give credit where it is due.) Those internal comments make your code readable. they allow a reader to follow your code and your thoughts as you wrote it. Those comments take less time than you think to write, but they are worth their weight in gold when you need to read even your own code next year.

Finally, I'm not sure I like this style of error message:

error('MSG:ID3','lengths of martices x and y need to be the same')

If you will use a message identifier, why not provide a descriptive name instead of MSG:ID3? This reminds me of the old days writing IBM Fortran code, where each programmer learned the meaning of cryptic error messages, identified only by a few characters and a 3 digit number. We then had a manual that offered an even more cryptic explanation of that error code, if you wanted to dig for it.

The model on my computer has everything you mentioned plus more (two elevator shafts, tabulated results), but there's no need to submit it here because the working principle is the same.

Putting the basic program here would make it easier to learn (less comments and lines of code to read,plus it's basically simpler). If you were joking, then you'd edit the rating, no? ;)

It's a simple model that can be built upon. The purpose is pure educational (read: comments).

Like the honeybee, I find it difficult to believe this would actually fly.

The appropriate review would just be this.

8-)

One solution to the dependence on the Image Processing Toolbox... you could plot a square surface object, then texture map the smiley-face image onto it. Then you can simply rotate the surface object yourself, without a need for the IPT.

Looks very nice. I was disappointed that no mention was made of the requirements for use. NO image processing toolbox, no go.

??? Undefined function or method 'imrotate' for input arguments of type 'uint8'.

Error in ==> bb2>go at 282
   iii=image(imrotate(uint8(flipud(am)),ll,'bilinear','crop'),'xdata',[ccc2-r/2,ccc2+r/2],'ydata',[ccc-r/2
         ccc+r/2]);

??? Error while evaluating uicontrol Callback

Now is clearer!! what a long discussion did it cause!!!!!

I give this 4 star, one is missing beacuse I thing is a little to simple model. But overall it is nice submission like so many comments testify.

In the end I thing this is the MEX purpose, to create discussion and improve each other.

 Thanks to the Author and all commenters !!

The program didn't specify which Universe its physics laws adhered to.

Maybe you have an old version of MATLAB or something, because a ball with initial Y velocity of 0 and gravity of 9.8 will go down.

This is the last time I'm reposting this ;)

Luigi is correct to some extent, that rolling friction does not slow down the ball. Air resistance may be a larger factor, depending upon the velocity.

However, the point I was trying to make that a spinning ball will behave differently when it hits the ground than a ball that is not spinning, and that some of the energy of the ball can be converted from one form to another by its interactions with the ground. Also, friction with the ground is very much a factor in those interactions. A rapidly spinning ball with a high amount of rolling resistance will have a very interesting behavior.

I'll look forward to seeing a spinning, smiley, bouncy, deformable face.

Yes
 
Horizontal and Vertical Speed Conservation are the correct terms for what this GUI does.

Well I don't want to be annoying but I have readen something wrong in previsious comments. Friction of the ground doesn't slow down balls. Friction makes them pivot.
 Without friction the ball just slips. It may stops cubes but not balls.

What really stops in real life the ball after a while it pivots it is not the ground friction, it is the ball deformability.
 When it touches the ground, due the weight pressure it becomes no more a ball. The pressure distribution has resultant torque opposed to ball motion. This is called rolling resistance and it is about 1/100 1/1000 the ground friction.
This is the reason balls runs faster than cubes.

 See http://en.wikipedia.org/wiki/Rolling_resistance

Luigi is correct here. There is a problem in the model, but a minor one I think.

Friction should be a retarding force, and as friction increases, the ball should slow down. So for friction above 1, the ball could not speed up. "Elasticity" in the model is used as a coefficient of restitution. This is essentially the fraction of the kinetic energy that is conserved in a bounce. So for elasticity greater than 1, we expect the ball to bounce higher each time. This is acceptable in the vertical direction, if you wish to model an uber-rubber ball. I might also be tempted to rename "elasticity" to "restitution", which is arguably a more accurately descriptive name here.

If you want to model the horizontal physics in this way, "friction" should slow down the ball at each bounce, for any positive value of friction, and high friction should slow it faster. Were you to allow a negative frictional value, it could then arguably speed up after a bounce.

If you make some changes, here are a few other neat ideas. Make the ball squishable, so that when it does bounce, it deforms. The "elasticity" parameter would naturally inversely govern the extent of the deformation. One might also allow the ground to deform too, absorbing some of the energy of the ball at each bounce. Again, a negative term here might increase the energy after a bounce.

Introduce a secondary frictional retarding force, perhaps proportional to the square of the velocity in the air.

Allow the ball to start out spinning, with some rotational velocity, in either direction. Thus, when the ball hits the ground, the angular momentum in the spinning ball can be transformed into a horizontal component of momentum. The friction with the ground would govern the amount of momentum transferred. This would work in the opposite direction too. If the ball is not spinning to start with, when it hits the ground, that can start it to spin.

Add a smiley face to the ball. After a the first bounce, make it look surprised. If the ball is spinning, the smiley face could rotate too, which would be a good way to show the spin rate.

A really complete model might even include fluid effects due to the spin. Thus a high rate of spin would help the ball to fly a bit further, or slow it down, depending on the direction of spin. Think of a golf or tennis ball, and how it behaves. One might modulate this with a surface texture parameter, shown as a rough or smooth ball. The viscosity of the medium would then be factor. (Don't you love it when someone comes up with this many features to add to your code? Hey, I'm not the one who would do the work.)

Regardless, I do like the help. It seems rare to find help in a gui tool, and even more rare that the help is good and well written, so I was very pleasantly surprised here.

I'd rate this as less than 5 only because the friction is clearly incorrect physical behavior. But I'd change my rating to a 5 as soon as that is repaired. And, I'm not willing to decrease my rating below 4.50000001 anyway, so I'll just round it up to a 5. I'll still root for some of those other terms I've described to be added to the model though.

Nice GUI but there is something wrong in the mathematical model.

This not a bouncing ball, in the simplest model, the friction value, I think you mean the friction with the ground, should affect the way ball pivots not length after that the ball stops.

For zero friction the ball just stops why?
-It should instead bouncing without pivoting.

-With intermediate values should slides and pivots dependending on materials data.

-With high friction should pivots without sliding.

If you try to insert a friction value >1 the ball accelerates, and this isn't phisical.

I saw you study mecatronics, you can realize that with Working Model software, or simpler throwing a ball.

I thing it need to be fixed