Matrix Solved Problems

[Marguerite Gilbeau]

SayI have a whole lot of independent small matrix problems (posed as regression problems below). Each individual problem is too small for effective CUDA deployment, yet I am wondering if there is an opportunity for substantial performance gains by executing these operations collectively on the gpu. See below for an example.

To be fair, you should probably time also the transfer of the data to the GPU, in my experience, it can take a while. If the data is already on the GPU for some other reason, you can of course skip this.

So funny thing here: Even the fixed CUBLAS.gels_batched! is slower than the threaded CPU baseline. However, I was able to stitch together code snippets of other batched solution methods to get a nice performance bump. Note that the arrays above are of heterogeneous height, so I had to write a routine to pad each array with zeros.

[quote]Okey Dokey, we have done some more testing,

serving the file from the media folder without any pemission restrictions works in IE

serving the file from the media folder with pemission restrictions does not work in IE

so it appears to be related to permissions on the zip file (other files such as .doc are served without problems!)[/quote]

There is an option that might be related:

Send no-cache header for File assets No

If enabled, the "no-cache" Cache-Control option will be sent when serving File asset types. This option can be used to resolve inline file display issues in Internet Explorer.

I have never had to turn this on, but it might be worth giving this a go.

Otherwise there may be something in the Microsoft KB. Which version of IE?

[quote]Dang this setting was already set to yes, setting it to no made no difference!

Tested IE 7 and 6 - Same issue.

Microsoft KB acknowleges the issues but their work arounds don't work.

If if makes any difference we are currently using Matrix Version 3.16.6 and are planning to upgrade soon.[/quote]

Have you got the KB references?

I am not sure if there have been any fixes since 3.16.6 about this issue, it is possible.

Maybe this might help:

Apparently there is an issue with IE and SSL and headers.

We have found that you can use mod-headers in apache to provide a valid workaround for this issue. With mod-headers, you use it to unset the Pragma header.

This is not a bug with matrix but with IE, we have found, Matrix adheres to the RFC spec while IE does not seem to follow it.

[quote]Maybe this might help:

Apparently there is an issue with IE and SSL and headers.

We have found that you can use mod-headers in apache to provide a valid workaround for this issue. With mod-headers, you use it to unset the Pragma header.

This is not a bug with matrix but with IE, we have found, Matrix adheres to the RFC spec while IE does not seem to follow it.[/quote]

That issue does not say it applies to IE7 though. All very odd.

Hello everyone.

I am doing a project with matrix leds 16x32 rgb and I have seen two problems that I can not solve.

This is the situation:

PROBLEMS: The matrix only shows the top half and the LEDs that should show the message are off and all the others are red.

The tests I made with the libraries of "Adafruit" and "rgbmatrixpanel"

It is not a personalized code, only the examples of the "rgbmatrixpanel" library.

I have reviewed the connections a thousand times and I can not find the solution.

The scheme that I have is the following:

1271765 387 KB

I don't know where this led matrix has been purchased. I have not been in charge of making the purchase of this matrix (I thought it was an adafruit matrix). Could it be possible that having two input sockets (each with 16 pins) should work with the two active sockets?

But, I can't think of another solution.

Regarding the matrix, it is of Chinese origin (I don't know which page but my suspicions are of "sparkfun") and I have supposedly been told that the library that operates this matrix is the adafruit of 16x32.

I have already found the solution.

Thanks to your "suspicions" I have found the right library.

I was trying as you say to use the library of an RGB matrix in mine which is just RG (Red and green).

You have been very helpful, thank you!

wavewolf:

I have already found the solution.

Thanks to your "suspicions" I have found the right library.

I was trying as you say to use the library of an RGB matrix in mine which is just RG (Red and green).

You have been very helpful, thank you!

Part of the problem is that we are trying to store an orientation as a series of 3 accumulated axial rotations. Orientations are orientations, not rotations. And orientations are certainly not a series of rotations. So we need to treat the orientation of the ship as an orientation, as a specific quantity.

I guess this is the first spot I start to get confused, the reason is because I don't see the dramatic difference between orientations and rotations. I also don't understand why an orientation cannot be represented by a series of rotations...

The first thought towards this end would be to keep the orientation as a matrix. When the time comes to modify the orientation, we simply apply a transformation to this matrix, storing the result as the new current orientation.

This means that every yaw, pitch, and roll applied to the current orientation will be relative to that current orientation. Which is precisely what we need. If the user applies a positive yaw, you want that yaw to rotate them relative to where they are current pointing, not relative to some fixed coordinate system.

To my understanding, isn't what he is doing (modifying a matrix on a stack) considered accumulating matrices, since the author combined all the individual rotation transformations into one matrix which is being stored on the top of the stack.

My understanding of a matrix is that they are used to take a point which is relative to an origin (let's say... the model), and make it relative to another origin (the camera). I'm pretty sure this is a safe definition, however I feel like there is something missing which is blocking me from understanding this gimbal lock problem.

One thing that doesn't make sense to me is: If a matrix determines the difference relative between two "spaces," how come a rotation around the Y axis for, let's say, roll, doesn't put the point in "roll space" which can then be transformed once again in relation to this roll... In other words shouldn't any further transformations to this point be in relation to this new "roll space" and therefore not have the rotation be relative to the previous "model space" which is causing the gimbal lock.

A rotation and an orientation are different because the former describes a transformation, and the latter describes a state. A rotation is how an object gets into an orientation, and an orientation is the local rotated space of the object. This can be directly related to how the two are represented mathematically: a matrix stores transformations from one coordinate space to another (you did have that correct), and a quaternion directly describes an orientation. The matrix, therefore, can only describe how the object gets into an orientation, through a series of rotations. The problem with this, though, is Gimbal Lock.

In the left image above, the blue and orange axes make the same rotation! This is a problem, because this means one of the three degrees of freedom has been lost, and additional rotations from this point may produce unexpected results. Using quaternions solves this because apply a quaternion to transform the orientation of an object will directly put the object in a new orientation (that's the best way I can say it), rather than breaking the transformation down into roll, pitch, and yaw operations.

Now, I am actually skeptical about accumulating matrices being a complete solution to this, because accumlating matrices (therefore accumulating rotations) are exactly what can cause the Gimbal Lock problem in the first place. The proper way to handle transformation by a quaternion is to either perform quaternion multiplcation on a point:

A plain matrix rotation (such as a 45 degree yaw) will always be defined in global space. If you want to apply the transformation in local space, you would have to transform your transformation into that objects local space. It sounds strange, so I will elaborate. This is where the importance of the order of rotations comes in. I recommend grabbing a book here so that you can follow along with the transformations.

Start with the book flat, its cover facing up at the ceiling, oriented as if you were about to open it and start reading. Now tilt the front of the book up 45 degrees (the front cover should roughly be facing you):

Now, let's say you wanted to adjust the yaw of the book 45 degrees (I think I'm assuming a right-handed coordinate system, so this will be changing heading to the left), and you want this to apply to the book's local coordinate space, so that the cover of the book will still face you:

The problem is, this rotation occurs in the global coordinate space, so the book's cover will end facing over your right shoulder. In order to have this change in heading occur in local coordinate space, you should have applied it first!

Try it out! Start the book facing up at the ceiling again. Change its yaw 45 degrees, and then pitch it 45 degrees along the global X axis (running from your left to right). This the orientation you expected with a pitch of 45 and yaw of 45 in the book's local space.

What does this mean? All it really comes down to is that the order of the operations matters. Transformations done first become local transformations in the context of transformations done afterwards. It becomes a lot to wrap your head around, and this is how quaternions save a lot of trouble. The skip all the order-dependent stuff.

3a8082e126