Re: [eigen] sse asin implementation

[Rohit Garg <rpg.314@xxxxxxxxx>]

I looked at the pow functions. Even the vector raised to a scalar
power would be tricky to implement if we follow the cephes library. A
simple exp(pow*log(base)) seems a better approach as sse does not
support masking. Or may be for the critical path (which must be
otherwise scalar) we could simply scalarize it. May be benching would
help. Any way the denormals would have to be ignored. I am not too hot
on implementing functions which are de facto outside eigen.

Cheers,

On Tue, Apr 14, 2009 at 6:50 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Finally, I committed your work. Sorry for the long delay, been busy
> with KDE 4.3 stuff.
>
> I couldn't apply directly your patch, as instead it was to be
> committed as the start of a new unsupported module, MoreVectorization.
>
> So look in unsupported/Eigen/src/MoreVectorization/ and see if you
> like it. I ran your test on it, it works.
>
> Hope that now it will be much easier to add more unsupported
> vectorized functions, now that the infrastructure is in place.
>
> What would be nice would be to take your test code (from your second
> attachment) and make it a new unittest in unsupported/test/ in Eigen's
> unit test format.
>
> As for adding more vectorized functions: now that we have this
> unsupported module, it sure doesn't hurt to add more. You decide for
> yourself if a given function is worth your time coding!
>
> Cheers,
> Benoit
>
> 2009/3/30 Rohit Garg <rpg.314@xxxxxxxxx>:
>> This file has the patch for sse implementation of asin. I have written
>> it along the lines of the cephes library. I have dropped one branch
>> which cephes takes that for x<1e-4 asin(x) is the same as x. Also I
>> don't know how to handle out of range inputs, so I dropped the error
>> checking. Perhaps, the user should be more careful before calling this
>> function. I dunno if it will return NaN for out of range inputs. I
>> wrote this in the MathFunctions.h file using as much of eigen's
>> abstraction so someone porting it to Altivec won't curse me too much.
>> :)
>>
>> Also I noted that Gael while committing my input had to write a fair
>> amount of top level code since I was writing pure intrinsic functions.
>> So I cut some slack here and decided to write it as close to eigen's
>> final implementation as I could. Unfortunately, it means that since I
>> am not sure of what else do I need to patch, I couldn't test it. :(
>> But it is a very simple one, so perhaps no errors made it through. :)
>>
>> On a related note, perhaps we should have an ei_psel function since it
>> is going to be used a lot (in transcendental functions atleast) so
>> would help with porting to altivec.
>>
>> --
>> Rohit Garg
>>
>> http://rpg-314.blogspot.com/
>>
>> Senior Undergraduate
>> Department of Physics
>> Indian Institute of Technology
>> Bombay
>>
>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay