Conference rusure::math

    Digital Extended Math Library.  Mostly applied math and computer stuff.
    
    Eugene

        I'm sure this has been asked before.  The closest to what
        you want that I found seems to be 1209; here's a list
        culled from dir/title=... (alternatively: math, dec, dig,
        wh).  You may also wish to take a look at these.
        
        Dan
        
   124  SILVER::TURANO       10-AUG-1984     2  Does anyone in DEC still publish
   781  CHEAPR::NORTON        5-NOV-1987     1  PERSONNEL RELATED MATH QUESTIONS
  1113    VINO::HDAVIS       16-AUG-1989     1  Job opening for Mathematician
  1193  TROA01::COCHRANE     15-FEB-1990     1  Math tools for Actuaries
  1209   FIVER::DAVE          8-MAR-1990     7  math in industry
  1297   SMAUG::ABBASI       18-SEP-1990     6  HOT areas in maths
        

    re. -1, -2
    
    Thank you both, I will probably have more question as I gather more
    information.
    
    -harvey

I'm in Sales Support now. Curiously, I'm doing more math in this job than 
in most of my previous jobs at DEC: demoing Mathematica and MAPLE, 
estimating programs, finding solutions and tools for customers, performance 
analysis, whatever. None of it REALLY serious, but fun!

    	[Owing to altitude sickness and jetlag,] I stumbled over the only bit
    of math I've encountered in work for ages.   RdbExpert establishes a
    ranking for various requests, and the formula is:
    
    	exp(log( a + exp(log(b)) ))
    
    Peculiar, huh?   Well, the logs are base 10, but I was slow and thought
    that the effect of exp(log(.)) was multiplication.   Of course, it's
    exponentiation by log(e):  something between a square root and a cube
    root.   Nevertheless, log(e) seems a bizarre constant to hardwire into
    the system like that...
    
    Any comments?
    
    Regards,
    Andrew.

    iam not a mathematician, but i'd like to be one, does this count?

    ref .5 (andrew)
    with log to base e, the epression is  a+b
    I tried to simpify it with log base 10, but could not get to far.
    what the simplifcation for that expression when it is to base 10?
    thanks,
    /naser
    

	I am not a mathmetician, but I added lots of math to my last job.
	I wrote software packages in statistics to analyze measurements
	of prop delays on fast logic chips, and packages for linear algebra
	and ReGIS to plot 3D stereo perspective wireframe obstensibly to
	see if correlation data made sense that way, and a complex arithmetic
	package to plot Smith charts for transmission line environments,
	and deconvolution (that's DEconvolution, the solution of one of
	the functions under the integral) to calculate unit impulse responses
	for sampling heads on oscilloscopes and transmission lines.
	A result of that was using Convolution on a Gaussian desnity
	distribution of prop dealy measurements to find the cumulative
	probability, which gave the probability vs. real prop delay that
	a part would fail prop delay limits in the DEC purchase spec on
	a production tester.  That was worth while.  I guess.
	I don't do that any more, I changed from h/w eng to s/w eng and
	don't need math much anymore, although real-time systems loading
	, if I"m asked to calculate it, would.
Tom

                     <<< Note 1415.5 by COOKIE::BUCHANAN >>>
           -< Oh, and I forgot frostbite and pollen-count excuses! >-
    
>>    	exp(log( a + exp(log(b)) ))
    
>>    Peculiar, huh?   Well, the logs are base 10 ...

On that assumption, we can simplify the expression to

	(a + b ** L1E) ** L1E

where ** stands for exponentiation (yes, I *was* brought up on Fortran) and L1E
stands for log10(e).  (Of course, if the logs are base e, the above simplifies
to

	a + b

as noted in a previous reply.)

My (somewhat cynical) view is that somebody wanted an impressive-looking
formula.

On a serious note, it'd be very interesting to see the empirical basis for this
formula.

    	re -.1, PBERGH.   Yes, your thoughts parallel mine.   I wondered if
    exp and log are particularly efficient to calculate (VAX C) compared
    to sqrt.
    
    	The idea is that one has a list of "requests", and one wants to rank
    them in some order, depending on two factors, "importance" and
    "frequency".   Frequency has a huge range, and so the exponentiation
    business is used to bring down the frequency to a reasonable spread,
    before adding the smaller but more important importance.   It's not
    an exact problem that is trying to be solved here, and maybe the
    experimenters found that sqrt and "cbrt" did not give the right
    degree of compression empirically.   There are "exp" and "log" all
    over the place in the rules of this system apparently, but it would be
    wrong to criticize the system if it gives the right kinds of result.
    
    Regards,
    Andrew.

                    <<< Note 1415.10 by COOKIE::BUCHANAN >>>
                                    -< yup >-

>>    	re -.1, PBERGH.   Yes, your thoughts parallel mine.   I wondered if
>>    exp and log are particularly efficient to calculate (VAX C) compared
>>    to sqrt.

From what I understand, exp and log are more difficult to calculate numerically
than sqrt.  To (considerably) oversimplify, sqrt is a couple of Newton-Raphson
iterations and with exp and log you have to do argument reduction to near 1 and
all sorts of clever things.

>>    	The idea is that one has a list of "requests", and one wants to rank
>>    them in some order, depending on two factors, "importance" and
>>    "frequency".   Frequency has a huge range, and so the exponentiation
>>    business is used to bring down the frequency to a reasonable spread,
>>    before adding the smaller but more important importance.   It's not
>>    an exact problem that is trying to be solved here, and maybe the
>>    experimenters found that sqrt and "cbrt" did not give the right
>>    degree of compression empirically.   There are "exp" and "log" all
>>    over the place in the rules of this system apparently, but it would be
>>    wrong to criticize the system if it gives the right kinds of result.

Note that exponentiation to 1/log10(e) is fairly close to a square root
(1/log10(e) == .43429...), so it's not clear to me what one buys by using exp
instead of the square root.

If one wants range compression, the time-honored methods of straight division
by a (large) constant or table lookup are normally far better (and faster).

I don't agree with your closing remark:  just because the system happens to
give approximately correct results for the tested cases, one can not conclude
that the system uses the right methods or even will give the right results on
the next case.

To illustrate my point, let me quote one of my favorite stories:

	An engineer had the hypothesis that all odd numbers are prime.
	He tested it:
	    1	OK (with a bit of stretch)
	    3	OK
	    5	OK
	    7	OK
	    9	error
	    11	OK
	    13	OK
	Obviously, the discrepancy with the hypothesis for 9 must have been an
	experimental error, so he concluded that all odd numbers are prime.

PS.  I enjoyed meeting you in real life.

    
    > Note that exponentiation to 1/log10(e) is fairly close to a square root
    > (1/log10(e) == .43429...), so it's not clear to me what one buys by
    > using exp instead of the square root.
    
    I think you meant to say log10(e) == .43429.
    1/log10(e) == ln(10) and is greater than two.
    
    Jon