Re: Octave and Single Precision

[David Bateman]

Paul Kienzle wrote:
> 
> On Jul 20, 2006, at 3:07 PM, John W. Eaton wrote:
> 
>> On 10-Jul-2006, Matthew Marzilli wrote:
>>
>> | This is my first post to the Maintainters list.  My name is Matt 
>> Marzilli,
>> | I'm a researcher at Lincoln Labs working with Octave.
>> |
>> | I am exploring the Octave Native Interface.  Are there any plans
>> for  Octave
>> | to internally support single precision, float values?  As I 
>> understand it
>> | now the single(..) function simply returns its argument and all
>> data  is
>> | stored internally as doubles.  I have read posts from developers
>> and  Paul
>> | Kienzle offering some various ways to implement single precision 
>> within the
>> | octave code base.
>> |
>> | 
>> http://velveeta.che.wisc.edu/octave/lists/archive//help-octave.2003/
>> msg01338.html
>> |
>> | Has there been any development of a single precision matrix 
>> (sMatrix) octave
>> | value either in the Octave or Octave-Forge code?
>>
>> Not that I know of, but I'd like to have single precision support in
>> Octave.
>>
>> My (vague) ideas about how to make this work are
>>
>>   * Convert the current Matrix/NDArray classes (both real and complex)
>>     to use templates with specialization for the parts that call
>>     LAPACK functions.
>>
>>   * Work on the double version first, so we can have the current
>>     functionality but using templates instead.  The current classes
>>     can be replaced by typedefs.
>>
>>   * Write specializations for the single versions.  Since the only
>>     difference may end up being the names of some LAPACK functions,
>>     try to limit the amount of duplicated code using function 
>> pointers(?)
>>     or macros.
>>
>>   * Provide all the operations on single arrays -- all the mx-*
>>     and vx-* files that are generated in the liboctave directory and
>>     all the files in src/OPERATORS to define the operators for the
>>     scripting language.
>>
>>   * Do the same for sparse?  Do we need single precision sparse
>>     arrays?
> 
> 
> All the mapper functions, oct-files such as sort, load/save, etc.
> would also need to be changed for complete support for single.
> David Bateman already did something similar for the fixed point
> library.
> 
> - Paul
> 
> 

I was never happy with the changes for the mapper functions for the
sparse or fixed type, but chose the way I did for convenience. At the
moment the mapper functions are basically a large switch statement on
the class of the input value. Therefore adding types to this basically
means adding a new switch. This can't be done for user types external to
octave and so, the fixed type essentially implements all of the mapper
functions using dispatch.

If you look in liboctave you'll find the array classes have methods like
::map and ::apply that might be if hooked into to th mapper code
completely remove the need for the switch statement. However, at the
time that I did the sparse stuff the changes seemed too large for m to
bother and I took the simple path. If the single type was introduced I
hope the next person doesn't make the same choice, as if this was fixed
then the external user types would essentially then have access to all
of the functionality of the internal types..

Regards
David