> 87,160 formulas and 10,828 graphics about mathematical functions > But is there 5 times as much as in, say, Abramowitz > and Stegun? No way. 5 times as much data, perhaps, but data > is not information. Well, i just compared a single charpter of HMF: 23. Bernoulli and Euler Polynomials - Riemann Zeta Function I downloaded the three notebooks 'BernoulliB', 'EulerE' and 'Zeta'. They sum up to very well 5 times the information given in the HMF on these subjects. But I did not like to use the information online. I spend most of the time going up and down the 'information-tree', thus loading tons of 'HTML' just to find a little formula. WR claims: ...with new searching capabilities. Actually the search facility did not know 'zeta', 'euler polynomials', 'bernoulli polynomials' and was totally useless in these cases. I think the site is an important knowledge base for mathematical functions, but best used in connection with notebooks and MathReader (or Mathematica). ==== we are planing to start with a project refering imaging software for pattern recognition. In a first step we are looking for some good books in this area e.g. math-background, standard algorithms. You aren't specific about what it is that you want the computer to recognize, but here are a few good references: Applied Pattern Recognition, by Paulus and Hornegger (includes material specific to images) Both of these title are heavier on the image processing side of things: Algorithms for Image Processing and Computer Vision, by Parker Digital Image Processing, by Gonzalez and Woods You might consider machine learning, which can be used to develop pattern recognizers. If so, consider: Computer Systems That Learn, by Weiss and Kulikowski It might help if you were to provide more specific information about your problem. good luck, Will Dwinnell http://will.dwinnell.com <8cd70836.0312271457.1da6690b@posting.google.com> <8cd70836.0312272043.6e4441e@posting.google.com> <8cd70836.0312280217.55e9ad52@posting.google.com> ==== On Mon, 12 Jan 2004 01:17:07 +0100 > The point is, functional programming is inherently a layer of > complication on top of the imperative machine architecture. > > It's a step further away, but it's quite far from being a > complication! Functional languages have a far, far simpler semantics > than their imperative counterparts. (That's one of the reasons why > optimizing them is easier.) Just to add in the usual response: For wider definitions of machine, i.e. parallel, distributed, global computing, functional languages appear to be closer to the machine architecture. The typical obligatory reference in this case is Sisal. However, it is dormant if not dead, but someone else also pointed out Single Assignment C recently (www.sac-home.org). X-Received: (from approve@localhost) by support1.mathforum.org (8.11.6/8.11.6/The Math Forum, $Revision: 1.9 primary) id i0C1kJo05152; Sun, 11 Jan 2004 20:46:19 -0500 ==== An integer is a set of all whole #'s and their inverse. An Integer is infinate and it can have and infinate amount of digits. ==== >> Have you remembered to halve the t=0 input datum? > I`m sorry i don`t understand. why is this necessary? > > Think of the finite fft as an approximation to the integral fourier > transform. If you make a trapezoidal approximation to the integral, > the first and last points must have weight 0.5 relative to the > internal points. For a signal that decays to 0, the last point doesn't > matter, but the first one does. I don't think so; the periodic boundary conditions of the DFT nullify your argument about the trapezoidal rule, since they remove any specialness about the first and last sample points (except for the arbitrary choice of phase of the Fourier kernel, of course, which depends on what you call t=0). ==== > Have you remembered to halve the t=0 input datum? >> I`m sorry i don`t understand. why is this necessary? >> >> Think of the finite fft as an approximation to the integral fourier >> transform. If you make a trapezoidal approximation to the integral, >> the first and last points must have weight 0.5 relative to the >> internal points. For a signal that decays to 0, the last point doesn't >> matter, but the first one does. > > I don't think so; the periodic boundary conditions of the DFT nullify > your argument about the trapezoidal rule, since they remove any > specialness about the first and last sample points (except for the > arbitrary choice of phase of the Fourier kernel, of course, which > depends on what you call t=0). I don't think the OP is interested in a 'strict' dft - he wants a dft that approximates the integral ft - since he is expecting an exponential to transform to a lorentzian. This doesn't work right unless you halve the weight of the t=0 point. For a discussion in the context of 2d NMR, which may be the OP's real problem, see Wutrich et al. J. Mag. Res. 66, 187 (1986). ==== Is there a relationship known for the distance between the largest root of an orthogonal polynomial and the endpoint of the orthogonality interval? I would like to know how fast this distance shrinks as a function of the degree of the polynomial... gert ==== > > Is there a relationship known for the distance between the largest root of > an orthogonal polynomial and the endpoint of the orthogonality interval? I > would like to know how fast this distance shrinks as a function of the > degree of the polynomial... > I'm not an expert on this but glanced through Abramowitz & Stegun. There is no general formula for all orthogonal polynomials (well, unless if such has been found during last 30 years; you might want to search mathscinet http://www.ams.org/mathscinet . I can't do it from home), but let me pick two examples. Here x_n is the biggest root of the polynomial of order n: 1) Chebyshev 1st kind, orthogonal on [-1,1]: x_n = cos((2n-1)pi/2n) 2) Legendre, orthogonal on [-1,1]: x_n = 1-(j_n)^2/2 * 1/n^2 + O(1/n^3). Here j_n is the nth biggest positive zero of Bessel function J_0(x). All the best, Teijo ==== Does anyone have any algorithms for calculating an optimum blackjack betting strategy that will make me rich? I've had great success lowering my bet after winning. My thinking is that if you have a base bet of say $8 and you win, then betting only $5 the next hand, basically means that the house has to beat you 2 hands to get your original bet back. What I'm wondering is this: I understand that the odds of flipping a coin and getting heads is still 50:50 even if you got heads 10 times in a row. However, in theory, if you flipped the coin an infinite amount of times, then wouldn't it be safe to say that you could expect to get heads 50% of the time? So, if the house has 50:50 odds, because you are wisely counting cards, then won't my betting strategy work if I play for several hours on end? ==== here is pointer where you find some comparisons: E.F.F. Botta, K. Dekker, Y. Notay, A. van der Ploeg, C. Vuik, F.W. Wubs, P.M. de Zeeuw, How fast the Laplace equation was solved in 1995, J. Applied Numerical Mathematics 24 (1997) 439--455. It is available with me as: http://homepages.cwi.nl/~pauldz/journals/laplace9597.pdf Another pointer that might be relevant, because of the comparison of multigrid and Bi-CGSTAB, reads: Chapter 5, Application of Bi-CGSTAB to discretized coupled PDEs, in: Acceleration of Iterative Methods by Coarse Grid Corrections, (Ph.D. Thesis, University of Amsterdam, 1997). It is available with me as: http://ftp.cwi.nl/pauldz/Thesis_PDF/Chapter5.pdf Paul de Zeeuw http://homepages.cwi.nl/~pauldz/ ==== > > My fitted values, and approx. std. errors using a Fortran program are: > a = 0.000250(0.000070) > b = 6.95 (0.20) > c = 25.69 (0.49) > I see that someone else agrees with these values. Many thanks to those who have responded to my request. What sort of algorithm are you using in your Fortran program? Levenburg-Marquardt was mentioned by another poster, and I have code for that in _Numerical Recipes_, though I was hoping for a simpler method. I'm not sure how to port Fortran code into Labview (the programming is being contracted out), though I imagine there is a way to do it. -- Allen Windhorn (507) 345-2782 FAX (507) 345-2805 Kato Engineering (Though I do not speak for Kato) P.O. Box 8447, N. Mankato, MN 56002 Allen.Windhorn@LSUSA.com