Wow, somebody with a real need to run real floating-point apps on ARM... You have my sympathies!
ARM floating point is all done in emulation, and as I've recently learned with a funny format: the two words of a double are ordered big-endian, but each word is little-endian, as is everything else on the platform. This can mess up some apps, others may be hitting obscure bugs in the kernel or glibc. The fact that lapack and atlas always fail checks is symptomatic of the problem; it seems R is failing checks too. There's no short answer I'm afraid. If you want to help, you can roll your sleves up and get down and dirty to see how for example lapack's checks are failing (bug 217966), then let us know when you have some specifics. It took me about 10 hours of banging on mozilla to isolate one of its problems, then some helpful people on the list suggested a one-line patch which worked right away; now I'm chasing down another moz bug (212569) and need help even isolating that one... Ah, the joys of free software on a minority platform. :-) On Thu, 2003-11-06 at 21:13, Simon Rex wrote: > I have a small handheld pc having ARM process as a CPU > (http://www.the-gadgeteer.com/sharp-zaurus-c760-review.html). I installed > debian and installed R using apt-get command. Everything worked great > except for drawing even simple graphs > > x <- 1:10 > plot(x) > > I got error messages > > 1: Nonfinite axis limits [GScale(nan,nan,1, .); log=0] > 2: relative range of values = 9.0072e+15 * EPS, is small > (axis 1). > 3: Nonfinite axis limits [GScale(-inf,inf,2, .); log=0] > 4: relative range of values = 9.0072e+15 * EPS, is small > (axis 2). > > I searched R-help Archives hoping answers to this problem and ran > into this message > > ***************** > > Debian tries to build its packages on a variety of platforms. The arm > platform compiled 0.90.1 (the last Debian release before the Debian > package > required an Atlas library, something we no longer require) failed in > 'make > check'. The log snippet follows; I traced this to the example(Bessel) > code. > > matplot(nu, t(outer(xx,nu, besselI)), type = 'l', ylim = > c(-50,200), > + main = expression(paste("Bessel ",I[nu](x)," for fixed ", x, > + ", as ",f(nu))), > + xlab = expression(nu)) > Error in title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) > : > Metric information not yet available for this device > In addition: Warning messages: > 1: Nonfinite axis limits [GScale(nan,nan,1, .); log=0] > 2: relative range of values = 9.0072e+15 * EPS, is small > (axis 1). > 3: Nonfinite axis limits [GScale(-inf,inf,2, .); log=0] > 4: relative range of values = 9.0072e+15 * EPS, is small > (axis 2). > Execution halted > > Casual inspection suggests that GScale(nan,nan,1, .) is probably > incorrect. Now, src/nmath/bessel* provide the Bessel functions but > does this > reflect a potential libc bug in IEEE handling? > > I have also asked on the debian-arm mailing list, but no result so > far. I > have some access to an arm box and could compile small test cases if > that > helped. > > Dirk > **************** > > Is there any way I can fix this problem ? I checked Debain FTP sites > to find Atlas but there is no Atlas lib for arm. > > I really appreciate any help. > > Thank you > > ReX > > > --------------------------------- > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
