Athar,

Carl pointed out what you need to do, but for understanding it may be helpful to be aware that, in essence, your original assignment just equates the pointers to the data structure.

For mutable objects, Maple stores the pointer to, or address of, the object in the variable. Assigning that to a new variable then simply makes the new variable point to the same data structure. This makes many things a lot more efficient and is the way to go unless you really need a duplicate of your structure, which is what copy() is for.

In general, I find that when I feel the need to copy such a structure I am up to no good and need to rethink what I am doing. At least with sizeable data structures it is usually more efficient to juggle the pointers around.

Mac Dude.

If you want to getrid of the higher-order terms in a mathematical sense, do a series expansion up to the order you wish. In case of epsilon; this would be

For the 1/c^3 you first will need to do something like subs(1/c=cinv,s2) and get the truncated series in cinv and then subs(1/cinv=c,s2a). You implicitly assume c not equal 0 here, of course.

Use convert(s2a,polynom) to convert the series object back to an expression.

I tried this with epsilon & it worked. Don't have time to mess with c but you should be able to get that to work also. You may want to expand & simplify along the way to keep your expressions manageable.

Mac Dude

@Markiyan Hirnyk Yes, that appears to be what I need. However; LinearAlgebra:-Norm does not seem to deal with the case of p=0, which is the geometric mean (see my reply to Carl above). For my immediate application that is likely not relevant, though.

Thanks,

M.D.

@Markiyan Hirnyk Yes, that appears to be what I need. However; LinearAlgebra:-Norm does not seem to deal with the case of p=0, which is the geometric mean (see my reply to Carl above). For my immediate application that is likely not relevant, though.

Thanks,

M.D.

@Carl Love yes, as long as we are on the real axis only and unless p is an integer. On the complex plane this is defined everywhere, but I have not verified that for the case of all x_n being the same the result is x_n, which is necessary for being able to call this a mean of sorts. There are more specialized cases, e.g. when p->0 Mean_0(n_x) = root(Prod(x_n,n=1..N),N), which is real as long as the overall product is >0. But then we have branches and other nasties to deal with.

M.D.

@Alejandro Jakubi 

It really depends on usage. In many cases I believe Maple is being used as an interactive system, and the user is specifically interacting with the Maple UI, not some kind of program. This the case also for my application. I am, however, impatient and do not necessarily trust things to go well so I want to always be assured the work is progressing; therefore the wish for the progress-bar thingy (which I now have). For such an application the embedded controls are a valid approach, I'd argue, and the need to drag them in as opposed to creating them in code does not seem to be a super-big deal. Certainly there are other "features" of Maple that are more of a hindrance (e.g. the many "quirks" and what I would consider bugs in plotting and my pet peeve: not being able to save a worksheet that is being evaluated so risk losing it if it causes an infinite loop & needs an abort).

It is a different case if/when one creates a program with its own interface (e.g. building Maplets). There ideally one wants all the features one can get so one can build an interface as one desires, incl. creating and showing certain elements at certain times. Having said that; many IDEs now have drag & drop of interface elements and that seems these days the generally accepted way of designing a GUI (and you then turn the elements visible/invisible as desired). Of course, these IDEs generate code (if ugly) that can be saved, inspected and modified with an external editor, but who really does that?. If Maple workbooks get corrupted, >that< is not acceptable and worthy a lot of pressure on Maplesoft to fix. I have not personally had such an experience recently (working with Maple 15 & newer on Mac OS X) so I cannot complain yet... (lots of wood-knocking).

So I am not convinced this (programmatically building embedded components) should be a high-priority issue. I do think Maplesoft could be more responsive, one or two minor updates per Release is too few given the number of issues we see and that get discussed here.

My $0.02,

M.D.

PD: edited after initial posting

@Alejandro Jakubi 

It really depends on usage. In many cases I believe Maple is being used as an interactive system, and the user is specifically interacting with the Maple UI, not some kind of program. This the case also for my application. I am, however, impatient and do not necessarily trust things to go well so I want to always be assured the work is progressing; therefore the wish for the progress-bar thingy (which I now have). For such an application the embedded controls are a valid approach, I'd argue, and the need to drag them in as opposed to creating them in code does not seem to be a super-big deal. Certainly there are other "features" of Maple that are more of a hindrance (e.g. the many "quirks" and what I would consider bugs in plotting and my pet peeve: not being able to save a worksheet that is being evaluated so risk losing it if it causes an infinite loop & needs an abort).

It is a different case if/when one creates a program with its own interface (e.g. building Maplets). There ideally one wants all the features one can get so one can build an interface as one desires, incl. creating and showing certain elements at certain times. Having said that; many IDEs now have drag & drop of interface elements and that seems these days the generally accepted way of designing a GUI (and you then turn the elements visible/invisible as desired). Of course, these IDEs generate code (if ugly) that can be saved, inspected and modified with an external editor, but who really does that?. If Maple workbooks get corrupted, >that< is not acceptable and worthy a lot of pressure on Maplesoft to fix. I have not personally had such an experience recently (working with Maple 15 & newer on Mac OS X) so I cannot complain yet... (lots of wood-knocking).

So I am not convinced this (programmatically building embedded components) should be a high-priority issue. I do think Maplesoft could be more responsive, one or two minor updates per Release is too few given the number of issues we see and that get discussed here.

My $0.02,

M.D.

PD: edited after initial posting

acer, this is pretty much exactly what I want. I did readup on components; however, it wasn't clear to me how I could get them to update while the loop is running. Your example makes this clear.

Thanks much,

M.D.

As for Alejandro's remark: I am not sure this is fully correct: i did once write a wrapper around a read-in procedure to ask me for the directory; that dialog I brought up programmatically (no use of any of the pallettes or such; just plain 1-d input) & the code gets the string handed back. I >did< do this as a Maplet and the main sheet stall during the dialog's being open. The main part I could not see was how I can get a component to update while a loop is running.

Scratch that. Embedded components of course behave differently than Maplets do. Alejandro is correct, can't programmatically create embedded components.

As for Alejandro's 2nd remark: Merci beaucoup, mais non! I have spent way too many hour on terminals and line input; or editing files and then running them. Notebook GUI's, even somewhat sluggish ones (as most are) are great progress & I would not want to go back. Any routine of a more general nature goes into a library, sooner or later, and is there when I need it so my Notebooks are actually not that long. I even stopped my old practice of saving programs as text files to be read-in, in favour of making proper modules or packages. I like this approach in Maple very much, esp. as it can be used in a nearly object-oriented way.

acer, this is pretty much exactly what I want. I did readup on components; however, it wasn't clear to me how I could get them to update while the loop is running. Your example makes this clear.

Thanks much,

M.D.

As for Alejandro's remark: I am not sure this is fully correct: i did once write a wrapper around a read-in procedure to ask me for the directory; that dialog I brought up programmatically (no use of any of the pallettes or such; just plain 1-d input) & the code gets the string handed back. I >did< do this as a Maplet and the main sheet stall during the dialog's being open. The main part I could not see was how I can get a component to update while a loop is running.

Scratch that. Embedded components of course behave differently than Maplets do. Alejandro is correct, can't programmatically create embedded components.

As for Alejandro's 2nd remark: Merci beaucoup, mais non! I have spent way too many hour on terminals and line input; or editing files and then running them. Notebook GUI's, even somewhat sluggish ones (as most are) are great progress & I would not want to go back. Any routine of a more general nature goes into a library, sooner or later, and is there when I need it so my Notebooks are actually not that long. I even stopped my old practice of saving programs as text files to be read-in, in favour of making proper modules or packages. I like this approach in Maple very much, esp. as it can be used in a nearly object-oriented way.

Very interesting post; in fact it confirms my long-standing belief that stop signs are usually a bad thing :-)

But I do have some comments:

In your equation E := 2*(1/2*mass*speed^1); purportedly showing the energy wasted due to the stop there is the obvious error of the exponent being 1 instead of 2; I assume this is just a transcription error. More significant, however: You are counting the energy twice, which I believe to be wrong. You are putting 1/2mv^2 of energy from the tank into the car when you accelerate form 0 to v. However, when you brake, that same energy goes into the brake pads, you do not need gas for that. IOW, when you brake for the stop you do not directly pay; you are simply wasting what you paid for before. You then do pay with gas when you accelerate again. So the enery cost is only one times 1/2mv^2.

You further down talk about the Corolla's average mileage of 26 mpg and state that it increases during acceleration. Well, this belies your Canadian heritage: It is the consumption (liters/100km) that increases, the mpg (miles/gallon) actually decrease. I did not go through your sheet but I hope it is right in there.

Finally; I did not find any efficiency used for the engine. I have no hard data, but I believe thermodynamically you do not get a gasoline engine to do much better than 30...35%, which would have to be factored in when converting the energy in the fuel to kinetic energy of the car (unless the fuel number has that efficiency already built in).

Mac Dude

I really doubt it is a question of age of the style file. Looking at your output it appears there is some Maple input and the some "MapleLaTeX", presumably output. It does appear that Maple is doing something ugly here: rather than using LaTeX syntax it uses special commands (presumably defined in Maple2e.sty) and then puts out graphical elements (??). If you can identify what of this gibberish stands for what part of the equation (assuming that you are putting out an equation or expression) you can try deploying strategically placed line breaks (\\). You may have to break up the \mapleinline command for that (or whichver command actually does the inserting). Also note there seems to be a \maplemultiline{} command. If you are familiar with LaTeX styles you could go into the style file & see what is actually happening (but then you might not have posted here...).

Other than that; you could try to break up your expression in Maple (e.g. using op()) and put out the pieces. In LaTeX you may need to do some fiddling to have it come out right.

I have not tried LaTeX output from Maple myself yet, but looking at the gibberish in your post I think I'd just bite the bullet & retype the whole thing in proper LaTeX syntax. If you print out the Maple 1-d form (i.e. the input form) of the output then the transcription should not be too difficult. (In fact, I can see a small Perl routine doing the translation).

Mac Dude.

Great thanks much. Right now, of course the problem does not show up; but at least I am able to get rid of the garish red-blue color scheme:-). If the disappearing-symbols problem is a font issue (which I strongly suspect) then this should do the trick.

M.D.

Great thanks much. Right now, of course the problem does not show up; but at least I am able to get rid of the garish red-blue color scheme:-). If the disappearing-symbols problem is a font issue (which I strongly suspect) then this should do the trick.

M.D.

Alejandro and itsme, you are correct. I messed around even more with "use..." and it just does not appear to do what I want (or what MMa's With[] does either). It seems that the bindings in the first part of "use" are not even local in any sense; at least in a piece of code i have now used it in the bindings are all global.

Now wondering what "use...in...end use" is even good for... but that's more for philosophy class.

Oh well, Modules and Procedures, here I come...

Thanks all,

M.D.

Alejandro and itsme, you are correct. I messed around even more with "use..." and it just does not appear to do what I want (or what MMa's With[] does either). It seems that the bindings in the first part of "use" are not even local in any sense; at least in a piece of code i have now used it in the bindings are all global.

Now wondering what "use...in...end use" is even good for... but that's more for philosophy class.

Oh well, Modules and Procedures, here I come...

Thanks all,

M.D.