Carl Love

Carl Love

28035 Reputation

25 Badges

12 years, 326 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are replies submitted by Carl Love

Please post the questions on the list so that the questions and the answers become searchable by all users until the end of time. Also, please start a new thread for the questions.

That being said, I have a few comments on your worksheet:

  1. What do you think evala does? Can you check whether it is actually doing something in those places where you use it? As far I know, there's no reason to think that it would do anything for your expressions.
  2. About the thing with assuming h > 0: Yes I do think it's a bug, but I'm not sure. I've tried to make a simple case where the same thing happens, but I haven't been able to do it yet.
  3. You should take out all uses of assuming h > 0 and assuming t[i] > 0. Use assume(t[i] > 0) instead, and let the original assumption on h handle the h. I've tested this on your code, and I get much better simplifications this way.
  4. Regarding your main question about extracting the coefficients for the system of equations: I'm sure that there's an easier way, but I don't yet know exactly what that way is. I'll need to look at it more. If you post that question in a new thread, it is much more likely that someone else will read it and answer it. It seems like it's just you and me in this current thread now.

Please post the questions on the list so that the questions and the answers become searchable by all users until the end of time. Also, please start a new thread for the questions.

That being said, I have a few comments on your worksheet:

  1. What do you think evala does? Can you check whether it is actually doing something in those places where you use it? As far I know, there's no reason to think that it would do anything for your expressions.
  2. About the thing with assuming h > 0: Yes I do think it's a bug, but I'm not sure. I've tried to make a simple case where the same thing happens, but I haven't been able to do it yet.
  3. You should take out all uses of assuming h > 0 and assuming t[i] > 0. Use assume(t[i] > 0) instead, and let the original assumption on h handle the h. I've tested this on your code, and I get much better simplifications this way.
  4. Regarding your main question about extracting the coefficients for the system of equations: I'm sure that there's an easier way, but I don't yet know exactly what that way is. I'll need to look at it more. If you post that question in a new thread, it is much more likely that someone else will read it and answer it. It seems like it's just you and me in this current thread now.

Wow, that's a tour-de-force.

We were working on essentially the same thing at the same time. I at first considered using an Array of Records, but settled on a listlist to reduce the overkill factor (see my procedure below).

An aside, not related to the Asker's problem: I've noticed that you code a lot of ModuleApplys. Is there any benefit to making a procedure into a module whose only export is the ModuleApply? or is it just habit and style at this point? When do module locals get garbage collected?

Wow, that's a tour-de-force.

We were working on essentially the same thing at the same time. I at first considered using an Array of Records, but settled on a listlist to reduce the overkill factor (see my procedure below).

An aside, not related to the Asker's problem: I've noticed that you code a lot of ModuleApplys. Is there any benefit to making a procedure into a module whose only export is the ModuleApply? or is it just habit and style at this point? When do module locals get garbage collected?

Please rewrite your question. Perhaps there are some missing characters that were dropped by the editor? You can use the Preview option (next to Submit) in the editor to check how the post will look after it's posted.

Your last three equations are

phi[i]:= piecewise(...);

and likewise for phi[i+1/2] and phi[i+1]. I think that those should be

phi[j]:= r-> piecewise(...);

and likewise for phi[j+1/2] and phi[j+1]. Is that right? If I do that, then all the integrals in eq10 are evaluated. The resulting expression is large, but I can apply simplify(%) and it simplifies nicely all at once. The final expression fits on one screen. How much free memory do you have?

Your last three equations are

phi[i]:= piecewise(...);

and likewise for phi[i+1/2] and phi[i+1]. I think that those should be

phi[j]:= r-> piecewise(...);

and likewise for phi[j+1/2] and phi[j+1]. Is that right? If I do that, then all the integrals in eq10 are evaluated. The resulting expression is large, but I can apply simplify(%) and it simplifies nicely all at once. The final expression fits on one screen. How much free memory do you have?

Are you saying that you want to take the tickmark positions that are chosen by default and make their labels shorter? Or are you saying that you want to choose both the positions of the tickmarks (as in your prior question) and the way their labels are printed? The latter is easier than the former.

Are you saying that you want to take the tickmark positions that are chosen by default and make their labels shorter? Or are you saying that you want to choose both the positions of the tickmarks (as in your prior question) and the way their labels are printed? The latter is easier than the former.

@sakhan I think that I may have missed part of the computation; maybe I got i's and j's mixed up. For whatever reason, my eq10 is only a half screen in size---not that complicated. Please upload the worksheet with all computations starting from the restart. Yes, I am sure that I can find a way to simplify each integral as it is done.

@sakhan I think that I may have missed part of the computation; maybe I got i's and j's mixed up. For whatever reason, my eq10 is only a half screen in size---not that complicated. Please upload the worksheet with all computations starting from the restart. Yes, I am sure that I can find a way to simplify each integral as it is done.

@Christopher2222 Ah, I guess by "caps" you meant what are called "whiskers" in a box-and-whiskers plot, the central vertical lines? Those are what I thought you meant by "tips". And I thought that by "caps" you meant what appears as horizontal lines in my plot.

So now I am guessing that you want the violin to have a cusp at the top and bottom, as in your original plot, with the top cusp at the highest data point and the bottom cusp at the lowest data point. Is that right? I believe we can achieve this with plottools:-homothety. And I guess that you want the scale of the vertical axis to stay the same. Is that correct?

@Christopher2222 Ah, I guess by "caps" you meant what are called "whiskers" in a box-and-whiskers plot, the central vertical lines? Those are what I thought you meant by "tips". And I thought that by "caps" you meant what appears as horizontal lines in my plot.

So now I am guessing that you want the violin to have a cusp at the top and bottom, as in your original plot, with the top cusp at the highest data point and the bottom cusp at the lowest data point. Is that right? I believe we can achieve this with plottools:-homothety. And I guess that you want the scale of the vertical axis to stay the same. Is that correct?

@Christopher2222 I totally agree that Maple should implement angled tickmark labels: It seems like a standard feature of plotting software (mostly for histograms). As a stopgap measure until something like that is implemented, would it be useful to you to have a Pareto plot with one- or two-letter tickmark labels along the horizontal axis and a legend that matches the short labels to the actual labels?

I just want to clarify for less-experienced readers that the "labels" to which you refer are tickmark labels. Usually, the unqualified word "labels" in the context of Maple plots means axes labels, which can indeed be written horizontally or vertically.

First 687 688 689 690 691 692 693 Last Page 689 of 708