Prev: ASF bug (?)
Next: use of EQUIVALENCE for a dynamical assignment of data
From: Victor Eijkhout on 2 May 2010 15:54
I have two long ints, both too long to convert to float, but their ratio
is something reasonable. How can I compute that? The obvious "(1.*x)/y"
does not work.

Victor.

--
Victor Eijkhout -- eijkhout at tacc utexas edu
From: Gordon Sande on 2 May 2010 16:25
On 2010-05-02 16:54:25 -0300, see(a)sig.for.address (Victor Eijkhout) said:

> I have two long ints, both too long to convert to float, but their ratio
> is something reasonable. How can I compute that? The obvious "(1.*x)/y"
> does not work.
>
> Victor.

Try 1.0d0*x/y or maybe (1.0d0*x)/(1.0d0*y) or dble(x)/dble(y) or
real(x,kind=dp)/real(y,kind=dp) for suitable value of dp=kind(1.0d0).

This is conversion to double precision. The problem is you needed 1.0d0
as the magic constant to get double precision.

But just what was the trouble as 2^60 ~= 10^20 which is well within the
range of the usual single precision real which goes to ~10^38? I assume
a long int is a C-ism for an 8 byte integer and float is a 4 byte real.

I have used double precision to hold integer values when I was getting
integer overflow at ~10^10. It was good for another 10^7 with almost no
fuss. Integer values in single precision run out of steam awfully fast
as they only go to about ~10^6.

I would guess that your "problem" is that reasonable values for your ratio
were above 10^6 and you are loosing too much precision.



From: Ron Shepard on 2 May 2010 17:41
In article <1jhvdbp.mpongj1n0eviuN%see(a)sig.for.address>,
see(a)sig.for.address (Victor Eijkhout) wrote:

> I have two long ints, both too long to convert to float, but their ratio
> is something reasonable. How can I compute that? The obvious "(1.*x)/y"
> does not work.

Could you give some values for the integers x and y that you think
"does not work"? That's not exactly the way I would compute the
real ratio, but what I have in mind is mathematically equivalent, so
I'm curious what exactly is the problem you have with that
expression.

Is it simply that the precision of the expression does not match the
precision of the real variable into which it is stored? If so,
there are easy fixes posted by others that should solve the problem.

$.02 -Ron Shepard
From: glen herrmannsfeldt on 2 May 2010 20:11
Victor Eijkhout <see(a)sig.for.address> wrote:

> I have two long ints, both too long to convert to float,
> but their ratio is something reasonable.
> How can I compute that? The obvious "(1.*x)/y" does not work.

If you mean 32 bit integers, and the system has a 64 bit floating
point type, then doing the division in 64 bit floats should work.

If the integers are 64 bits, then that might not be enough.

I have had programs where I wanted to multiply an integer times
the ratio of two integers and generate the appropriately truncated
quotient. That is, I*X/Y where I, X, and Y are 32 bit integers,
but I*X won't fit in 32 bits. Many systems now have a 64 bit
integer type, and some compilers can even figure out how to do
that with the normal multiply and divide instructions.

If you need the rounded quotient to full precision, then there
are algorithms to do that. One reference is Knuth's "The Art of
Computer Programming," vol. 2. For a rounded result, it isn't
hard to do the reduced precision quotient, and then a correction
to that. It is a little harder to get the appropriate truncated
quotient.

-- glen
From: robin on 3 May 2010 00:16
"Victor Eijkhout" <see(a)sig.for.address> wrote in message news:1jhvdbp.mpongj1n0eviuN%see(a)sig.for.address...
|I have two long ints, both too long to convert to float, but their ratio
| is something reasonable. How can I compute that? The obvious "(1.*x)/y"
| does not work.

Nor will it ever!
You need to convert to double precision, or longer, if that's available!


 | 
Pages: 1
Prev: ASF bug (?)
Next: use of EQUIVALENCE for a dynamical assignment of data