Hey hey,
2013/7/31 Karl Rupp <r...@iue.tuwien.ac.at>
> Hey,
>
> >> I started going through the code, and you're right, the change isn't
> >> very large. But it makes sense to split it up as you describe, to keep
> >> the different semantics different, and same semantics shared (ie, to
> >> make sure the concepts are as clear as possible). I also have another
> >> motivation for splitting it up: it would make mapping NumPy/Python
> >> scalar types to ViennaCL types much more natural, and I could avoid a
> >> lot of duplication.
> >
> > I had a go at patching ViennaCL as I described, and pushed up the two
> > revisions to my pyviennacl repo on github. A patch, excluding the bits
> > touching pyvienacl and the CMake stuff for my system, is attached
> > below. I didn't add any extra types or enums, so there's nothing
> > grouping SYMBOLIC_VECTOR_TYPE_FAMILY with VECTOR_TYPE_FAMILY; it didn't
> > seem necessary to clear up the code in that way. Of course, everything
> > compiles as before; but I wasn't sure how to run the tests (despite
> > figuring it out before), so I haven't checked those for runtime errors..
> >
> > Oddly, when I fixed up my wrapper to deal with the changes, I noticed a
> > slight decrease in overhead (~10-20us)..
> >
> > Anyway, do tell me your thoughts.
>
> Thanks, I applied this already. Tests still pass. You can easily test
> this yourself by 'make'ing inside build/tests/ and then calling the
> respective executables. The scheduler tests are
> scheduler_vector-test-cpu
> scheduler_vector-test-opencl
> scheduler_vector-test-cuda
> scheduler_matrix-test-cpu
> scheduler_matrix-test-opencl
> scheduler_matrix-test-cuda
> with CUDA and OpenCL tests only available with the actual backend
> enabled. For the scheduler it should suffice to test only one of the
> backends, though...
>
> @Philippe: Please pull the changes into your generator code. I'm still
> interested in your opinion on the SYMBOLIC_VECTOR and whether you need a
> separate enum value for this.
>
>
Yes, this is pulled, everything's alright ! :)
Well, all I need is to have the sufficient information to cast into
symbolic_vector_base<> instead of vector_base<>, since they have completely
different semantics.
Best regards,
> Karli
>
>
Best regards,
Philippe
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> ViennaCL-devel mailing list
> ViennaCL-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/viennacl-devel
>
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
