Displaying 4 results from an estimated 4 matches for "xshw".
Did you mean:
lshw
2001 Aug 21
4
looking for a smarter way
...ch local.name in each cluster. The code does what I want, but
I have other examples where I have hundreds of clusters and I would prefer
not to have to type in a line for each cluster. Again, there must be a way
and I would appreciate any suggestions:
xtab<-table(x$LOCAL.NAME,xclu$clustering)
xshw1<--sum((xtab[,1]+0.000001)/sum(xtab[,1])*(log((xtab[,1]+0.000001)/sum(x
tab[,1]))))
xshw2<--sum((xtab[,2]+0.000001)/sum(xtab[,2])*(log((xtab[,2]+0.000001)/sum(x
tab[,2]))))
xshw3<--sum((xtab[,3]+0.000001)/sum(xtab[,3])*(log((xtab[,3]+0.000001)/sum(x
tab[,3]))))
xshw4<--sum((xtab[,4]+0.0...
2011 Jan 31
0
[LLVMdev] Possible CellSPU Bug?
David Greene wrote:
> class XSHWVecInst<ValueType in_vectype, ValueType out_vectype>:
> def v4i32: XSHWVecInst<v4i32, v8i16>;
> Is this pattern as intended, or did I find a real problem?
Looks like a bug to me. xshw (extend signed half-word(16bits) to
word(32bits)) takes a v8i16 and produces a v4i32. This ha...
2011 Jan 31
1
[LLVMdev] Possible CellSPU Bug?
Kalle Raiskila <kalle.raiskila at nokia.com> writes:
> Looks like a bug to me. xshw (extend signed half-word(16bits) to
> word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone
> unnoticed as there is only one type of vector register class (i.e.
> VECREG) that is used for all vectors.
>
> Nice catch :) Are there more of these?
I don't know. I s...
2011 Jan 29
3
[LLVMdev] Possible CellSPU Bug?
I'm working on enhancing TableGen's type checking and it triggered with
a problem in CellSPU's specification:
XSHWv4i32: (set VECREG:v8i16:$rDest, (sext:v8i16 VECREG:v4i32:$rSrc))
It's complaining that v4i32 is not smaller than v8i16, which is true in
the sense of vector bit size, and true in the sense of vector element
size. To me, a sign extension from i32 to i16 makes no sense.
>From the .td file,...