First, sorry for not making myself clear.  In the original question (at
the bottom of this post) I said that I expected a value of 0.  I guess I
wasn't precise enough for you sticklers -- I meant an extremely small
number (less than 1E-100), which is 0 for most practical purposes.  A
couple people suggested that I had nodata in my original grid, but that
wasn't the case.  Bill Huber suggested that underflows are represented as
nodata, and provided a way to work around that.  That was indeed the
problem.  It turns out, though, that if I used the Grid.Exp request
instead of Number.GetEuler, the whole underflow/nodata problem
disappeared.  Strange, but true.


-------------------------
From Bill Huber:

I take it you mean that [newGrid] contains some NoData values where you
were expecting zeros.  However, zero is not in the range of the
exponential
function.  The only valid results are positive numbers, overflows,
denormalized values, or underflows.  ArcView apparently interprets
underflows and overflows as NoData.  Where underflow occurs, because the
exponent is very negative, a good approximation to the answer is zero.  To

force the answer to zero, then, test for underflow, as in

         newGrid = ([oldGrid] < -709).Con(0.AsGrid, [oldGrid].Exp)

You can use thresholds other than -709 (= -(2^10 - 2)*ln(2): the limit for

normalized floating point values), depending on your needs, but anything
less than -744.44 (= -(2^10 - 2 + 52)*ln(2)) will not be effective.  Note
that grids support an "Exp" request: you don't need the ridiculous (and
inefficient) GetEuler construct.


-------------------------
Original Question:

Hi,

I'm attempting to do some grid calculations using e to the power of some
other grid, like this:

newGrid = Number.GetEuler.AsGrid ^ oldGrid

The problem is that I'm getting nodata in some cells that should be 0, and
I have no way of telling which cells are really nodata and which should
really be 0.

This is really messing up my results.  Anyone have any idea what's going
on or how to make it work correctly?

Thanks,
Chris