Prev: a simple overflow example
Next: Overload assignment operator for an user defined type array with ?vector scripts
From: robin on 10 Sep 2009 06:51 "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:h89mq0$884$1(a)naig.caltech.edu... | sumesh.pt <sumesh.pt(a)gmail.com> wrote: | | < In mixed mode operations, is it advisable to convert integers to | < double using the command dble() in the expressions or would it be | < better for the compiler to do this job? I am asking this NOT from the | < point of view of understanding the program easily, but in terms of | < speed and accuracy. ie | < real*8 :: x | < integer :: i=10 | < x = x/i or x=x/dble(i) which is faster and accurate. | | For the same conversion, the speed and accuracy should be | the same. There are some cases where you might want a different | conversion, in which case the functions are useful. | | < I am doing some kind of recursion calculations with x and hence error | < gets accumulated and I am not able to decide which is best. | | If, for example, you wanted to divide a default REAL (not double | precision) by an integer, but with the division done in double | precision, then you might need a conversion function. You WOULD need to use a conversion function (viz, DBLE or REAL with KIND), given that you want the operation done in double precision. | In Fortran 66 days DFLOAT was used to convert integer to | double precision. It seems that DBLE now will do that. | | There used to be questions about constant conversion at compile | time vs. run time. That is, x/2 vs. x/2.0. I believe by now | all compilers should do that at compile time, but it used to | be a big discussion topic. There's no requirement to do any conversion at compile time. x/2 can be done at execution time on certain computers not by division but by scaling (and at considerable saving in time). 2.0 can be treated as 2 for operations like x*2 and x/2, and those operations (* or div) are done at run time of course (the * being performed as x+x, again with considerable increase in speed).
From: robin on 10 Sep 2009 06:51 "Tim Prince" <tprince(a)nospamcomputer.org> wrote in message news:4AA85D3A.8020806(a)nospamcomputer.org... | I see no reason for this to make a difference. You could check the asm | code generated by your compiler, since you appear to be interested. If | you do this in a context where the compiler may have the option to | replace x/i by x*0.1d0, that replacement should increase performance, | with a possible slight reduction of accuracy. With certain well-known | compilers, if you choose compile flags which avoid this replacement, the | similar replacement of x/8 by x*.125d0 may also be suppressed, even | though that one doesn't affect accuracy, so would have been a clear gain. Operations involving multiplication and division by powers of 2 can be done as simple scaling (and even as additions in the case of multiplication).
From: robin on 10 Sep 2009 06:51 "e p chandler" <epc8(a)juno.com> wrote in message news:c3c27158-454a-4462-84df-03c77c25e760(a)l9g2000yqi.googlegroups.com... On Sep 9, 9:36 pm, "sumesh.pt" <sumesh...(a)gmail.com> wrote: >> In mixed mode operations, is it advisable to convert integers to >> double using the command dble() in the expressions or would it be >> better for the compiler to do this job? I am asking this NOT from the >> point of view of understanding the program easily, but in terms of >> speed and accuracy. ie >> real*8 :: x >> integer :: i=10 >> x = x/i or x=x/dble(i) which is faster and accurate. >In general for integer constants it should not make a difference. >However, do not expect a real constant to be promoted to a higher >precision because it is in a mixed mode expression or it is assigned >to a variable of higher precision. Instead specify, for example, >9.237543521d0 (or the appropriate kind _ suffix). In a mixed mode expression, the REAL will be converted to DOUBLE (or higher) precision if its co-operand is of double or higher precision (respectively). I think that what you meant to say was that it will be processed and used as single precision until it is required for some arithmetic; and thus, for example, the constant 0.1 will be treated as single precision. If, when required for arithmetic with a double precision operation, that single-precision value will be converted to double precision form WITHOUT gaining any additional accuracy. That is to say, it is still a single precision value held in double precision form. >> I am doing some kind of recursion calculations with x and hence error >> gets accumulated and I am not able to decide which is best. >That is a different story. Errors tend to accumulate in using >recurrence relations. Sometimes the recurrence is quite sensitive to >the direction in which it is calculated. A good text on numerical >analysis should cover this. >The short version is I suspect you have an algorithm problem rather >than a Fortran problem.
From: Gordon Sande on 10 Sep 2009 08:38 On 2009-09-09 22:36:31 -0300, "sumesh.pt" <sumesh.pt(a)gmail.com> said: > In mixed mode operations, is it advisable to convert integers to > double using the command dble() in the expressions or would it be > better for the compiler to do this job? I am asking this NOT from the > point of view of understanding the program easily, but in terms of > speed and accuracy. ie > real*8 :: x > integer :: i=10 > x = x/i or x=x/dble(i) which is faster and accurate. > > I am doing some kind of recursion calculations with x and hence error > gets accumulated and I am not able to decide which is best. > > Thanks, If both it matters and you care then it would make more sense to take the trouble to have a second variable, say "di", which had the double precision value of "i". That way there will only one conversion, which may well be the case anyway. It may also be the case that di = di + 1.0d0 is cheaper than di = dble ( i ) so the explicit conversion can be avoid by building it into the code with the same sequencing for both i and di. The conversion can be more expensive that regular arithmetic. You will need to do an awfull lot of computing to make up for the lost time for even a single mistake being redone. In other words, I am doubtful that it matters in the long run.
From: Dan Nagle on 10 Sep 2009 10:58
Hello, On 2009-09-10 06:51:39 -0400, "robin" <robin_v(a)bigpond.com> said: > There's no requirement to do any conversion at compile time. > x/2 can be done at execution time on certain computers > not by division but by scaling (and at considerable saving in time). Masking out the exponent, shifting, subtracting one, and merging the new exponent back into the original number may well take longer than one multiplication on modern hardware. > 2.0 can be treated as 2 for operations like x*2 and x/2, > and those operations (* or div) are done at run time of course > (the * being performed as x+x, again with considerable increase > in speed). On modern hardware, multiply is often (at least almost) as fast as addition. In any case, run your own tests on your own hardware before coming to a conclusion. -- Cheers! Dan Nagle |