From mdowle at mdowle.plus.com  Wed Jul 20 11:10:16 2011
From: mdowle at mdowle.plus.com (Matthew Dowle)
Date: Wed, 20 Jul 2011 10:10:16 +0100
Subject: [Rd] Manipulating single-precision (float) arrays in
	.Callfunctions
References: <1311004330702-3675684.post@n4.nabble.com><4E245D01.1010407@gmail.com><1311027322959-3676667.post@n4.nabble.com><CC044BB2-F9EA-440F-8A64-5B4639B2A529@r-project.org><1311048424023-3677232.post@n4.nabble.com>	<alpine.LFD.2.02.1107190640280.28269@gannet.stats.ox.ac.uk><j03qto$hvm$1@dough.gmane.org>
	<4E259600.5070103@gmail.com>
Message-ID: <j0661r$8h4$1@dough.gmane.org>


"Duncan Murdoch" <murdoch.duncan at gmail.com> wrote in message 
news:4E259600.5070103 at gmail.com...
> On 11-07-19 7:48 AM, Matthew Dowle wrote:
>>
>> "Prof Brian Ripley"<ripley at stats.ox.ac.uk>  wrote in message
>> news:alpine.LFD.2.02.1107190640280.28269 at gannet.stats.ox.ac.uk...
>>> On Mon, 18 Jul 2011, Alireza Mahani wrote:
>>>
>>>> Simon,
>>>>
>>>> Thank you for elaborating on the limitations of R in handling float
>>>> types. I
>>>> think I'm pretty much there with you.
>>>>
>>>> As for the insufficiency of single-precision math (and hence 
>>>> limitations
>>>> of
>>>> GPU), my personal take so far has been that double-precision becomes
>>>> crucial
>>>> when some sort of error accumulation occurs. For example, in 
>>>> differential
>>>> equations where boundary values are integrated to arrive at interior
>>>> values,
>>>> etc. On the other hand, in my personal line of work (Hierarchical
>>>> Bayesian
>>>> models for quantitative marketing), we have so much inherent 
>>>> uncertainty
>>>> and
>>>> noise at so many levels in the problem (and no significant error
>>>> accumulation sources) that single vs double precision issue is often
>>>> inconsequential for us. So I think it really depends on the field as 
>>>> well
>>>> as
>>>> the nature of the problem.
>>>
>>> The main reason to use only double precision in R was that on modern 
>>> CPUs
>>> double precision calculations are as fast as single-precision ones, and
>>> with 64-bit CPUs they are a single access.
>>> So the extra precision comes more-or-less for free.
>>
>> But, isn't it much more of the 'less free' when large data sets are
>> considered? If a double matrix takes 3GB, it's 1.5GB in single.
>> That might alleviate the dreaded out-of-memory error for some
>> users in some circumstances. On 64bit, 50GB reduces to 25GB
>> and that might make the difference between getting
>> something done, or not. If single were appropriate, of course.
>> For GPU too, i/o often dominates iiuc.
>>
>> For space reasons, is there any possibility of R supporting single
>> precision (and single bit logical to reduce memory for logicals by
>> 32 times)? I guess there might be complaints from users using
>> single inappropriately (or worse, not realising we have an instable
>> result due to single).
>
> You can do any of this using external pointers now.  That will remind you 
> that every single function to operate on such objects needs to be 
> rewritten.
>
> It's a huge amount of work, benefiting very few people.  I don't think 
> anyone in R Core will do it.
>
> Duncan Murdoch

I've been informed off list about the 'bit' package, which seems
great and answers my parenthetic complaint (at least).

http://cran.r-project.org/web/packages/bit/index.html

Matthew



[Rd] Manipulating single-precision (float) arrays in .Callfunctions
Matthew Dowle