erik10

I have a degree in Mathematics and Physics from the Danish University Aarhus, comparable to a masters degree with thesis - majoring in Mathematics. In 1991-92 I was a visting scholar at UCLA, Los Angeles, following graduate courses in Applied Mathematics. Since 1992 I have been a teacher in a high school (gymnasium) in Denmark. Special interests: Applied mathematics, graphics and popularizing Mathematics.

MaplePrimes Activity


These are replies submitted by erik10

Thanks Preben

It works as you describe. I have another problem in connection to the same thing: I want a ball to follow a certain curve parametriced by (4,f(t)). The first coordinate is fixed to the value 4, whereas the second coordinate is a function of one variable, t. The commands works well if f(t) is a simple expression, say sin(t). My function is however defined using a simple procedure. The animate command fails, as you can see below. I don't know why - I even remembered unevaluation quotes. I hope someone can tell me how to make it work.

> restart;
> with(plots);
> f := proc(t) if 5 < t then sin(t) else 0 end if end proc;
> ball := proc (x, y) plots[pointplot]([[x, y]], color = blue, symbol = solidcircle, symbolsize = 40) end proc;
> animate(ball, [4, 'f'(t)], t = 0 .. 10, frames = 200);
Error, (in plots/animate) incorrect specification of points data

Erik

Thanks Preben

It works as you describe. I have another problem in connection to the same thing: I want a ball to follow a certain curve parametriced by (4,f(t)). The first coordinate is fixed to the value 4, whereas the second coordinate is a function of one variable, t. The commands works well if f(t) is a simple expression, say sin(t). My function is however defined using a simple procedure. The animate command fails, as you can see below. I don't know why - I even remembered unevaluation quotes. I hope someone can tell me how to make it work.

> restart;
> with(plots);
> f := proc(t) if 5 < t then sin(t) else 0 end if end proc;
> ball := proc (x, y) plots[pointplot]([[x, y]], color = blue, symbol = solidcircle, symbolsize = 40) end proc;
> animate(ball, [4, 'f'(t)], t = 0 .. 10, frames = 200);
Error, (in plots/animate) incorrect specification of points data

Erik

Often people get confused about the expression "printing to a pdf", but that is in fact what happens. In principle everything which can be printed on paper can be printed to a pdf file. The original Adobe Acrobat is the most advanced to my knowledge. It has many settings, but is quite expensive. Several free programs creating pdf files do a nice job in many circumstances. Another option is

PrimoPDF

I have been using that one myself on my laptop to cut expenses, whereas I am using Adobe Acrobat on my stationary computer. PrimoPDF has some nice settings: You can choose quality settings for Web, for Print and more. The better quality the bigger file, so it is a matter of choosing the appropriate for ones purpose. If pdf files are to be printed on paper, it requires higher quality to look good compared to when the pdf files are just made for wieving on the computerscreen ... 

Pagan, I agree with you that it was enough for you to split the expression into two parts to display the problem. Splitting into more parts will only make it worse. I remember reading some numerical mathematics many years ago, but I don't have the energy to get deeper into the subject of floating point arithmetic again. And I would also need to study how Maple are doing things. I did however save the document you linked to for eventually later study. Thanks.

I am using Maple in my physics class in high school, so things should not get too complicated. Now I need to warn my students to use the evalf command. I am even wondering what happens when my students are rightclicking on Maple output and choose Approximate > 5 (a very basic action). Do they really get the result to five digits of precision or are the answer "downgraded" to maybe 3 or 4 digits, meaning one might only count on 3 or 4 digits or so? Maybe I should advice my students to go for 10 digits to feel more safe? I am a little shaken ;) 

Erik  

I think we can summarize that the evalf[n](...) is a rather sophisticated command and I agree with Axel Vogt that Maple help is not delivering sufficient or proper documentation for it. When reading the help menu for evalf one get the impression it is a very simple command, although somewhat down the details page, there is an example "When not to use evalf", but it is rather special. I hope Maplesoft will clarify how really evalf works in the Help menu. 

I understand the problem now: Maple is rounding off to two digits of the individual factors, then make the computation and is rounding off again. This is kind of disappointing. I had expected Maple to calculate the parentheses with full precision and only round off to two digits in the end. As it seem to be now, the evalf command is of limited value to me. Now I can't save command lines: I need to calculate first and then add a new command line in the end to force Maple to do it the way I want. 

Why has Maple implemented the evalf command in this way? I don't see any value in that choice? Probably there is a reason, though :)

pagan: Shouldn't you divide your evalf computation in even more parts? I mean 4*(1391000/2)^2 could be divided as well.

Thank you for all your replies. I appreciate it!

Erik 

OK, thank you! This makes it work indeed. But then it was a bad suggestion Maple posed in the dialog: kg/m^3. It should have been kg/'m'^3. But maybe it is too much to ask for that Maple should keep track of the variables already defined? I had hoped though that Units and variables did not interfere. I mean units are put in double brackets and should not be mistaken with variables. But obviously that is not the case!

Erik  

Thanks Robert! I searched Maple help but could not find anything. I am grateful for your link. I will try it out and ask again if I get into problems ...

Regards, Erik

Thanks Robert! I searched Maple help but could not find anything. I am grateful for your link. I will try it out and ask again if I get into problems ...

Regards, Erik

Your intention of separating general discussions about Maple from specific questions which have a solution might be fruitful, but I don't find the word "Posts" a good choice. Actually I was very confused myself when I entered the updated MaplePrimes today. Until I found this thread I did not know where to ask about my Maple problem. The word "Posts" is very often used for what is here called "Questions". Eventually try writing "Post a question" or "Posts in Forum" or the like in Google and watch how much stuff is coming up.

I don't think the word "Discussion" will do it either. And "Topic" probably neither. I suggest you try searching for another word, which do not get confused with "Questions". If you cannot find any appropriate word, then maybe this whole idea of making this distinction is not necessary ...

Regards, Erik

 

Nice! This makes map even more attractive!

Erik V.

Nice! This makes map even more attractive!

Erik V.

Thank you so much. I appreciate both solutions. The first one doesn't need the little strange ~, whereas the latter doesn't need a call for the LinearAlgebra package. Pretty nice solutions both!

Regards, Erik V.

Thank you so much. I appreciate both solutions. The first one doesn't need the little strange ~, whereas the latter doesn't need a call for the LinearAlgebra package. Pretty nice solutions both!

Regards, Erik V.

Thanks a lot. That made the trick!!

Erik V.

First 12 13 14 15 16 17 Page 14 of 17