help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Single Precision Workarounds?


From: David Grohmann
Subject: Re: Single Precision Workarounds?
Date: Wed, 07 Feb 2007 17:35:54 -0600
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

John W. Eaton wrote:
On  5-Feb-2007, David Grohmann wrote:

| John W. Eaton wrote:
| > On  5-Feb-2007, David Grohmann wrote:
| >
| > | I understand that octave doesn't support single precision.
| > | 
| > | Are there any suggested workarounds for *.m code and MEX files that 
| > | depend on single precision input or output (not really worrying about 
| > | single/double precision math differences just there are times when a 
| > | certain type is assumed in a MEX file)?
| >
| > Maybe it would help if you posted a specific example.
| >
| > jwe
| >   
| oops didnt CC the list.
| 
| Well I believe the exact problem is
| 
| calling mxArray *mxCreateNumericMatrix(int m, int n, mxClassID class, 
| mxComplexity ComplexFlag);
| with class = mxSINGLE_CLASS,
| 
| obviously that can be changed to mxDOUBLE_CLASS but I was hoping there 
| might be a way to fool the MEX code into thinking it was working with 
| singles even though octave was using doubles under the hood.

Creating an object like this should work with the CVS Octave now, but
passing the value back to Octave will fail.  I checked in the
following change.  Is this enough for your purposes?  I think it
should be OK as long as you don't care that the object will actually
be a double-precision matrix when it is passed back to Octave.

jwe

  

src/ChangeLog: 2007-02-05 John W. Eaton <address@hidden> * mex.cc (mxArray_number::as_octave_value): Fake mxSINGLE_CLASS by returning double-precision values. (mxArray_sparse::as_octave_value): Clarify error message. =================================================================== RCS file: /cvs/octave/src/mex.cc,v retrieving revision 1.19 diff -u -u -r1.19 mex.cc --- src/mex.cc 4 Jan 2007 17:57:49 -0000 1.19 +++ src/mex.cc 6 Feb 2007 01:27:29 -0000 @@ -1249,7 +1249,36 @@ break; case mxSINGLE_CLASS: - error ("single precision data type not supported"); + { + int nel = get_number_of_elements (); + + float *ppr = static_cast<float *> (pr); + + if (pi) + { + ComplexNDArray val (dv); + + Complex *ptr = val.fortran_vec (); + + float *ppi = static_cast<float *> (pi); + + for (int i = 0; i < nel; i++) + ptr[i] = Complex (ppr[i], ppi[i]); + + retval = val; + } + else + { + NDArray val (dv); + + double *ptr = val.fortran_vec (); + + for (int i = 0; i < nel; i++) + ptr[i] = ppr[i]; + + retval = val; + } + } break; case mxDOUBLE_CLASS: @@ -1425,7 +1454,7 @@ break; case mxSINGLE_CLASS: - error ("single precision data type not supported"); + error ("single precision sparse data type not supported"); break; case mxDOUBLE_CLASS:
Sorry, once again hit reply instead of reply all.

I don't have access to apply this patch to our version of octave. But it looks like it will help with creating a matrix of singles. But perhaps you can answer this question as well. If I create a single and return it to octave, and then back to a MEX object and query its classID will it respond with mxSINGLE_CLASS?

Either way this is a step in the right direction to at least faking singles.

Thank you,
-- 
David Grohmann
Senior Student Associate
Applied Research Lab : UT Austin : ESL - S206
Office: 512-835-3237


reply via email to

[Prev in Thread] Current Thread [Next in Thread]