@Christopher2222 Note that the hues appearing at the "bottom" (back) of your 3D plot get obscured by those on "top" (front).

Compare your original orientation=[0,0] with the scene you get viewing at orientation=[180,-180]. Viewed from the front then the purples are hidden. And so on, for most any angle. I don't know whether this effect is related to `symbolsize`.

Viewing instead the flat image from the H-layer replacement gets quite different behaviour in this regard.

ps. You likely ought not attempt style=patchnogrid unless the grid size is smaller.

@herclau So, you have a plot at the end. Is it your goal to place (or "draw") a red circular arc on the original image, and show that?

@Alejandro Jakubi I wonder whether the auto-simplification of  '(2^(1/2))^29.403243784' is an oversight, which I why I mention it in particular.

In contrast, I do expect the following result, where float-contagion leaves the 2^(1/2) alone,

'(2^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 2     

Even the example involving 4^(1/2) is a bit strange. I do expect this, though,

 '(4^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 4     

@Alejandro Jakubi I wonder whether the auto-simplification of  '(2^(1/2))^29.403243784' is an oversight, which I why I mention it in particular.

In contrast, I do expect the following result, where float-contagion leaves the 2^(1/2) alone,

'(2^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 2     

Even the example involving 4^(1/2) is a bit strange. I do expect this, though,

 '(4^(1/2))*29.403243784';

                                    (1/2)
                      29.403243784 4     

Are you thinking of implementing an application that does some sort of detection of circles in an image?

Do you intend an application which (somehow, more interactively in a mouse-pointer sense perhaps) implements something like this or this? If so, then would it be appropriate to first implement a Maple procedure which provides the functionality of Matlab's imfindcircles function? Once the programmatic functionality is available then one might develop an interactive application which connects optional parameters for sensitivity, etc, with embedded Sliders.

Sorry if I have guessed wrongly. Giving URL links showing what you intend would help at least as much as uploaded text documents here.

If you are trying to build an interactive application that ties together Slider embedded components with ImageTools images (Arrays) then you might consider using Label components. This has worked ok for me in the past, where fractal images on Labels were updated quite quickly for smaller sizes. On a fast machine updating  a 300x300 pixel image on a Label can be reasonably smooth in practice, even though it necessitates file system i/o. Two of Maple 17's Math Apps (link, link) act similarly.

acer

What platform are you using, for your Maple 15?

Is it 64bit Windows? If so, then see this note.

On 64bit Maple for MS-Windows, the functionality of the Finance package is quite incomplete in releases before Maple 17, which is mentioned in a note at the very bottom of the ?Finance help-page (note capitalization of "Finance"). A warning should also be emitted, when loading that package using `with`.

acer

@tiradentes Did you mean k*(1-m_r) as a product?

It looks as if you have input just a function application, but perhaps you intended a multiplication?

Notice,

0.5(1-2.2);

                              0.5

0.5*(1-2.2);

                             -0.60

@tiradentes Did you mean k*(1-m_r) as a product?

It looks as if you have input just a function application, but perhaps you intended a multiplication?

Notice,

0.5(1-2.2);

                              0.5

0.5*(1-2.2);

                             -0.60

Here are the integrals, which succeed symbolically under assumptions that match the plotting ranges.

You could thus plot these instead (using the approriate ranges, for the scaled or unscaled version). That would very likely be the fastest way to produce the plot of the particular integral.

You might also want to consider raising the working precision, if you believe that you are still encountering numeric roundoff error.

I did these symbolic integrals using your original floating-point coefficients. You may wish to try it with exact rational coefficients instead.

Download dropsymbolic.mw

I might hazard a guess that the (successful) symbolic value of the rescaled integral Rnew might have better numerical evaluation behaviour under its plotting ranges than does the (successful) symbolic value of the integral R under its plotting ranges.

acer

Here are the integrals, which succeed symbolically under assumptions that match the plotting ranges.

You could thus plot these instead (using the approriate ranges, for the scaled or unscaled version). That would very likely be the fastest way to produce the plot of the particular integral.

You might also want to consider raising the working precision, if you believe that you are still encountering numeric roundoff error.

I did these symbolic integrals using your original floating-point coefficients. You may wish to try it with exact rational coefficients instead.

Download dropsymbolic.mw

I might hazard a guess that the (successful) symbolic value of the rescaled integral Rnew might have better numerical evaluation behaviour under its plotting ranges than does the (successful) symbolic value of the integral R under its plotting ranges.

acer

I don't have better code at the moment, but I can make a few comments.

The way that Matlab used to compute the Rank (and perhaps it still does) is to look at the ratio of the singular values to the largest singular value. The rank then being the number of sing. values for which the ratio satisfies a condition involving a (working- or double- precision) machine constant.

Maple also does the above, by first reducing to bidiagonal form (clapack dgebrd or nag f08kef), and then computing all singular values (clapack dbdsqr or nag f08mef), and then testing the ratios.

How could it be improved? For the both stages, it might be possible to  use a faster implementation of those named routines, from, say MKL. That is not something that could be tried with recompiling part of Maple, as the bundled MKL does not include the static .lib's as per usual Intel licensing of that product. Another possibility is the Eigen package, which is a quite separate implementation of floating-point linear algebra routines.

Another possibility might be to use a so-called rank-revealing QR computation.

Or, if not using MKL then the "optimal" blocksize as returned by (clapack) ilaenv (or nag equivalent) for the bidiagonal form reduction stage's performance could be checked and possibly tweaked.

Or, for the second stage it might be possible to use another routine, or another approach altogether. There are some notes which suggest that the newer divide and conquer routines are faster in the case that singular vectors are computed, but that otherwise those drivers use the same `dqds` algorithm as before. Are there other ways? At the expense of memory copies is there a possibility to compute only "selected" singular values for the bidiagonal form, so that the second stage might be be run in parallel (by splitting that second task in half, etc)? I don't know.

I have in fact been investigating this very topic, as I had noticed the timings posted at the URL you cited and have long wanted to look at the newer routines for computing singular vectors. (I might have seen it on usenet a short while back.) If I come up with an improvement on the Rank timing then I'll let you know.

I have a recollection that at one time in the recent past the URL you cited showed that Matlab was by far the slowest of the three M's on the rank calculation. Either I remember it wrongly, or they have improved their approach in the near past. It is very interesting (and likely no coincidence I suspect) how closely the Mma and Matlab timings you've cited now match each other across problem size. Also interesting is the performance ratio as compared to Maple 17, as the problem size gets large.

On a related note, I do have a simple proc that does wrapperless external call to the faster divide & conquer (and slower but more accurate jacobi method) drivers for the more expensive job of computing either all or only min(m,n) singular vectors. Perhaps I can find time for a post soon-ish.

acer

@marc005 That restriction on the Matrix brower appears to be present in 17. But it's not difficult to write custom procedures which do similar things.

For examination of the entries by value, you could just use a Data (table) Component. If the Matrix already is assigned to a name in the session, then inserting such an embedded component from the Components palette will very nicely prompt whether you wish to use it.

The attached worksheet took just a few moments to write. A little longer and it could be spiffier still.

quandlfun.mw

@marc005 The message "Unable to display structured data" arises from the Matrix browser (also available via right-click context-menu), when either dimension exceeds a certain value. It's not a consequence of that `GetCSV` procedure, per se.

The limiting value for either dimension appears to be 10001.

The Matrix browser has a few quirks. For example, the `image` view does not seem to work when either row or column dimension is just 1.

@Carl Love Yes, I get agreement (except on that one mentioned subexample). When an assumption is placed, including as additional qualification, a new assumed local is generated and assigned to the global name. It's always been problematic (a FAQ of sorts) that people get into trouble if they make assignments using some intermediate stage assumptions and then combine expressions involving the mix of assumed names. I don't know whether the word "intended" connotes to everyone, but that is the longstanding implementation and, presumably, the early design.

I find it less error prone (and easier to keep straight) to use `assuming` rather than `assume`, and this kind of thing is one reason.

@Carl Love Yes, I get agreement (except on that one mentioned subexample). When an assumption is placed, including as additional qualification, a new assumed local is generated and assigned to the global name. It's always been problematic (a FAQ of sorts) that people get into trouble if they make assignments using some intermediate stage assumptions and then combine expressions involving the mix of assumed names. I don't know whether the word "intended" connotes to everyone, but that is the longstanding implementation and, presumably, the early design.

I find it less error prone (and easier to keep straight) to use `assuming` rather than `assume`, and this kind of thing is one reason.