Since you have supplied fsolve with no restricted range on t then why is one root (amongst infinitely many roots to your equation) more acceptable to you than another?

Why should fsolve prefer Pi/4 over -Pi/4 (or any other valid root)?

Do you feel that fsolve should always find the root closest to the supplied starting point? What about when the starting point is midway between two valid roots?

acer

Can you show us an example, even if it is pared down with your private code removed?

acer

@Carl Love I was able to improve the original's performance using Int and evalf (with a coarse tolerance) in the definition of g2 (along with some simplification steps of the ensuing results from diff). As you've noted elsewhere, sometimes it works better to deal with an exact result, while sometimes the purely numeric approach can do better. It's not clear to me which is  better here, as it seems both cases are moderated by simplification or code optimization.

But I did notice that using the method=ftocms option on the exact int call in the defintion of g2 yielded a symbolic result involving erf rather than Fresnel. It may be that this helps, in this approach of doing that inner integral exactly (including code optimization).

@goli Why wouldn't you bother to include that extra known information when posing your question?

@Yiannis Galidakis 

Note that it's not strictly necessary to pare down list F inside the plotting loop, using select. I did that to reduce the plot data and memory requirements. The key to getting your zooming look is, rather, the use of plottools:-transform. to make sure all frames get the exact same view, after rescaling.

In my previous attachment I changed the code to build PP (or P) using a table, which is converted into a list after the loop finishes. It is quite inefficient to construct large lists by appending.

In the following attachment I also made a related to change to the construction of list F, using seq instead of repeatedly appending to the list F in a loop. That runs faster when processing the L made from farey(100) say.

You should really try not to create lists in a loop, by appending. It makes such code as this much slower than it has to be. It can make time and memory resources be O(n^2) rather than O(n), say, and so make your code scale up much less well.

I also added dynanic (faked) x-tickmarks, to show more clearly that it is zooming in. You can of course remove that bit.

A nice next step might be to dynamically construct F depending upon the loop index k (and thus also upon w). The bookkeeping for that is a bit trickier, though, and may involve changing how you build L as well. The idea is to produce the same total number of values for F for each frame, using each k and w value, but to construct them with a repeatedly changing value range. It would mean that the central portion of the plots would remain filled with lines, as it zooms. That would be cheaper to produce, and leaner, than simply bumping up the value passed to farey() to produce a single, re-used, and very large F.

FareySeq_modif2b.mw

@Winkel That error message is telling you that the save command expects additional arguments.

Look at the help-page for save. That command expects the assigned names you want to save to the file.

Eg,

    save name1, name2,...,namek, fileName;

You have merely,

    save fileName;

and so the error message is "must specify names to save".

So, what are the names (whose values have been computed in your worksheet) that you want to save?

@Yiannis Galidakis Is this more like what you want?

Download FareySeq_modif2.mw

What does the Maple command kernelopts(homedir) return? 

(Presumably your OSX user name is not "Name"...)

acer

@Markiyan Hirnyk Yes, Robert's Answer itself contained `&lang;` and `&rang;` rather than < and >. I've corrected it.

@Carl Love It works for me in Maple 2015.1.

Markiyan's worksheet contains ⟨u,v,w⟩ which is,

`⟨u`,v,`w⟩`

That's the unicode U+27E8 and not the usual left bracket. You can also get it in Maple using the plaintext Maple Notation input,

`⟨`

Or maybe it's U+2329... What's also critical is that Markiyan's sheet has that bracket symbol concatenated with the `u`. Similarly for the `w` and the right bracket.

So the second argument to the Plane command is not a Vector, in his uploaded sheet. It's no wonder he has difficulty in getting the example to work.

@mapleq2013 I think I see what you mean now. I'll try and figure it out. I may not be around for a few days, though.

@mapleq2013 Since I don't see C=(-A3^(-1)).(B+A4) getting close to B when g gets close to zero, and since you state that it ought to, then I would hazard that A3 and A4 are not as you intended.

@mapleq2013 You have g appearing in A1,A2,A3, and A4 but not in your construction of B.

You assign (-A3^(-1)).(B+A4) to Bm but then you don't use Bm in constructing C! You just use B in constructing C.

My guess it that you just made an oversight during your revising, to not utilize Bm the Matrix that depended upon g. Is that possible?

Also, I don't see that C is very close to (-A3^(-1)).(B+A4) when g=0, although I do see a difference in Bm between say g=1/10 and g=1/1000.

Much (if not most) file i/o is disabled in the MaplePlayer.

acer

@mapleq2013 I was hunting for a simplification of the Matrix you were assigning to C (which was not just B). I wanted this because it would (at least) reduce the time spent evaluating at each numeric x-y pair. It's quite possible that the simplifier I was using on Matrix C before did not have any effect. I'd have likely left it in the code anyway, in case I found something better later. And I believe that I have, now.

I don't have the same Intel i7 machine available right now. But on an AMD FX-8320 (4 physical cores?) running 64bit Maple 12.02 for MS-Windows I see a meaningful reduction in computation time if I use the variant simplifier when constructing Matrix C,

 u -> simplify(expand(u), size) 

Here is that variant, used in my modification to Carl's fsolve method to efficiently uses all 6 roots found for each x-y pair.

example_modif1b.mw

I included some calls to show the length of the entries in 6x6 Matrix C, both with and without that simplifier.

All 6 surface plots get generated in about 15 seconds using that code and machine, while it takes about 45 seconds using the earlier one I had. Using that alternate simplifer to preprocess C gets me about a 2-fold speedup when using the alternate Eigenvalues approach.

Well, you can experiment this simplification stuff and its effect on timings.

Interestingly, I see it all run about 4-5 times faster using the 64bit Linux version of Maple 12.02 on a quad-core Intel i5 than on the 64bit MS-Windows version of Maple 12.02 on that AMD FX-8320. I guess that's Maple 12 archaeology.

Simplification of multivariate trig terms is a bit of a dark art. I kept all initial constants as exact rationals, to aid in simplification. It's interesting to me, that while the counterintuitive inner expand step helped simplify C, I was able to subsequently grind down the symbolic characteristic polynomial (not shown in my sheets) more using an inner combine step. ...not that I got any joy from solve on it.