> has found fairly large changes in the numerical results from this Riemann > mapping code.
With a very small mesh. > The fact is, nobody knows what's the correct result. There are comments on While it may be true that no one knows what the *exact* correct result is, anyone who has had a basic graduate course in complex analysis better know the general type of results to expect. The numerical values for all the examples given conform to what to expect, and improve with respect to that when N in increased. The spiderweb-color plot combination is particularly effective, and I encourage everyone to take a look at them - and use them the next time you teach complex variables! I wish it had been available when I did. > 1) "I am not sure. I don't understand the code very well in Riemann map." > 2) "I don't understand the riemann code very well either" Yeah, no kidding; there is some significant numerical integration and other methods there, which is more than anyone should ask of reviewing for an upgrade in an spkg. Luckily, that was already reviewed, and no one has found errors. > 4) "Hoo boy, testing it out definitely shows some serious numerical > instability > even for many more plot points." > > The fact is, nobody knows what the correct values are, but there are tests > which > check if the results are the exepcted values or not. When a different version > of > Numpy is used, so the results change significantly. Depends on what you mean by 'significant'. The errors from 'expected' which were already documented in the code already show we expect fairly serious differences from theoretical values; the changes involved were all on the order of 10^-5 or less, which I would say is not bad for something pretty brand-new, and clearly not aimed at precision scientific computation. In fact, getting this to work at all within a few seconds is pretty impressive. But yes, it's pretty unstable near the boundaries! > To be fair to Ethan, the documentation does say "Note that all the methods are > Numeric rather than analytic; for unsusual regions or insufficient collocation > points may give very inaccurate results." > > Now people on the Numpy ticket are suggesting perhaps the Reimann algorithm > has > poor numerical stability. Well, duh! The documentation already says that near the boundary points this is the case. Which I (as one reviewer) even put specific examples of on the ticket. > I then asked whether there were some cases where the results are known > analytically. Apparently there are, which would be useful tests in my opinion. Yes, and that is now on a different ticket. Also, the error tests already existing are quite useful. > Better than tests where nobody know what the result is anyway. Not knowing the precise value does not mean it is wrong. Basically, this is yet another case where Sage is different from other open source projects. Much of the material is literally available nowhere else. I am pretty that's the case here, though perhaps that's not true. And it requires significant mathematical expertise to review it - again, unfortunate for this topic, but true. What Dave is saying is great in general, and there are indeed times where we could improve this. But it's unfair to pick on a specific ticket and say it's horribly wrong when it was never supposed to be so amazingly accurate in the first place. We should be encouraging innovation that is mathematically correct - and this one is as close to that as is advertised by itself, just like float matrices in Excel get crazy pretty quickly if you rely on more than a few decimal places, but are fine for that use case in general. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
