From: Prof. R. J. L. <rob...@uw...> - 2006-08-16 01:27:59
|
Burkhard, For feeling is that..... In a number of cases the first and last may be integers for example in IR when you scan from 4400 - 400 cm-1 or in Vis spec when you scan from 950 - 350 nm or GC traces when time is 0 - 1000 seconds etc. For NMR the scan may be integer in ppm but since data is stored in Hz then they will never be integer but depend on the frequency of the instrument. So first and last may suffer less from truncation errors than deltaX which is why I am suggesting not enforcing deltax but rather first and last. This sound reasonable? Thanks Robert on 15/08/2006 07:02 PM Burkhard Schaefer said the following: > Robert, >=20 > that's a tricky issue. The only bullet-proof way to get this right is=20 > *not* to use floating point arithmetics when calculating the=20 > auto-incremented values. >=20 > The problem is that in IEEE floating point, the neither of the followin= g=20 > equations hold: >=20 > (x_max - x_min ) / (endOffset-startOffset) =3D D x >=20 > So no matter if we give x_min , x_max or x_min and _ D x, we'll have=20 > rounding problems. Consider this: >=20 > S _i=3DstartOffset...endOffset D x =3D (endOffset-startOffset) =B7 D x >=20 > Even this does not hold in floating point arithmetics. However, to=20 > calculate a value x_i , it's more precise to use multiplication (like i= n=20 > the right hand part of the equation) rather than adding things up in a=20 > for loop. It avoids adding up the rounding errors. That's why I opted=20 > for storing the D x value. >=20 > The best practice when implementing it would of course be not to use=20 > floating point arithmetics. Most programming languages offer a concept=20 > of precise arithmetics. In Java, there's the BigDecimal class to do thi= s. >=20 > Of course, it's important that applications write these values into the= =20 > AniML document without truncating them. If they truncate, there's very=20 > little we can do. >=20 > Best regards, > Burkhard >=20 >=20 > Prof. Robert J. Lancashire wrote: >> Hi, >> >> I have been working through some coding for reading and writing CML >> documents and noticed that like JCAMP-DX they have followed the >> arrangement that for auto-generated X values the approach is >> provide the firstX, lastX and the number of points. >> From this deltaX is calculated. >> >> With AnIML, firstx and deltax is provided and I wonder whether this >> introduces a problem with respect to rounding errors. >> When packages give deltax in an output routine they may truncate >> to a set number of figures which would then lead to innaccuracies. >> >> I suggest it would be better to give first last and number of points >> so that deltaX is not truncated. >> >> In the case of JCAMP-DX though, I must admit to having seen numerous >> files where the ##FIRSTX=3D and ##LASTX=3D values were significantly >> trunacted by comparison to the actual values listed in the data sectio= n >> so there may be still be an issue with rounding that affects the >> calculation of delta. >> >> Any thoughts. >> Excuse me if this was covered long ago!! >> >> Robert >> >> >> ----------------------------------------------------------------------= --- >> Using Tomcat but need to do more? Need to support web services, securi= ty? >> Get stuff done quickly with pre-integrated technology to make your job= easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache Gero= nimo >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&da= t=3D121642 <http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D= 263057&dat=3D121642> >> _______________________________________________ >> Animl-develop mailing list >> Ani...@li... <mailto:Ani...@li...urce= forge.net> >> https://lists.sourceforge.net/lists/listinfo/animl-develop >> =20 |