First of all hi, this is my first question in stackoverflow :)
The hardware setup is 2 x nvidia gtx980 GPUs each connected to 3 monitors.
The videowall is arranged as one row of 6 monitors.
We are using the propietary nvidia drivers. The xserver version is 1.15.1 (7.7).
We create a uinput multitouch ABS (MT) device attached to a different master than the core pointer.
The max and min of ABS_X and ABS_MT_POSITION_X are set according to the size of both xscreens (0, 11520 - 1). This is checked using xinput list [device id].
As we are using two GPUs we are not able to create one large xscreen but we arrange 2 xscreens (one for each GPU) with three monitors aligned on each.
The problems lies on the second xscreen (xscreen1). When we emit touch events with x coordinate higher than 5760 (the size of the first xscreen) the points are reported by the xserver on a distant x coordinate (probably at the end of the second xscreen or farther away). We have checked this starting from xscreen0 and moving to the second. The y coordinate gets reported correctly (as both xscreens are y aligned).
The calibration matrix of the virtual multitouch device is the identity matrix.
If the uinput device is created as an ABS single point device (like a wacom tablet i guess) the x coordinate is reported correctly.
I'm thinking the problem might lay in evdev or inside the xserver (as i have read the new versions calibrate inside the server not in evdev). If this is the case any hint as to where this may happen would be great. If this is not the case any help is highly appreciated.
For anyone who may get this problem in the future, our team came up with a small patch a long time ago, here it goes in case it may be of use ...
---
dix/events.c | 21 +++++++++++++++++++--
mi/mieq.c | 26 ++++++++++++++++++++++++++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 8efdf18..5155ef5 100644
--- a/dix/events.c
+++ b/dix/events.c
## -2999,8 +2999,25 ## CheckMotion(DeviceEvent *ev, DeviceIntPtr pDev)
/* Motion events entering DIX get translated to Screen 0
coordinates. Replayed events have already been
translated since they've entered DIX before */
- ev->root_x += pSprite->screen->x - screenInfo.screens[0]->x;
- ev->root_y += pSprite->screen->y - screenInfo.screens[0]->y;
+
+ /*Now we take into account inputs comming from MT device that uses absolutes coordinates.*/
+ switch (ev->type) {
+ case ET_Motion:
+ case ET_KeyPress:
+ case ET_KeyRelease:
+ case ET_ButtonPress:
+ case ET_ButtonRelease:
+ ev->root_x += pSprite->screen->x - screenInfo.screens[0]->x;
+ ev->root_y += pSprite->screen->y - screenInfo.screens[0]->y;
+ break;
+ case ET_TouchBegin:
+ case ET_TouchUpdate:
+ case ET_TouchEnd:
+ ev->root_x -= screenInfo.screens[0]->x;
+ ev->root_y -= screenInfo.screens[0]->y;
+ break;
+
+ }
}
else
#endif
diff --git a/mi/mieq.c b/mi/mieq.c
index 05447d6..cc151f6 100644
--- a/mi/mieq.c
+++ b/mi/mieq.c
## -447,6 +447,32 ## mieqMoveToNewScreen(DeviceIntPtr dev, ScreenPtr screen, DeviceEvent *event)
DequeueScreen(dev) = screen;
x = event->root_x;
y = event->root_y;
+
+
+ /*Now we take into account inputs comming from MT device that uses absolutes coordinates.*/
+ switch (event->type) {
+ case ET_Motion:
+ case ET_KeyPress:
+ case ET_KeyRelease:
+ case ET_ButtonPress:
+ case ET_ButtonRelease:
+ // print
+ break;
+ case ET_TouchBegin:
+ case ET_TouchUpdate:
+ case ET_TouchEnd:
+ {
+ ScreenPtr screenPtr = dev->spriteInfo->sprite->pDequeueScreen;
+ x -= screenPtr->x;
+ y -= screenPtr->y;
+ NewCurrentScreen(dev, screenPtr, x, y);
+ return;
+ // break;
+ }
+ default:
+ break;
+ }
+
NewCurrentScreen(dev, DequeueScreen(dev), x, y);
}
}
Related
Having an infinite sequence s = 1234567891011...
Let's find the number at the n position (n <= 10^18)
EX: n = 12 => 1; n = 15 => 2
import Foundation
func findNumber(n: Int) -> Character {
var i = 1
var z = ""
while i < n + 1 {
z.append(String(i))
i += 1
}
print(z)
return z[z.index(z.startIndex, offsetBy: n-1)]
}
print(findNumber(n: 12))
That's my code but when I find the number at 100.000th position, it returns an error, I thought I appended too many i to z string.
Can anyone help me, in swift language?
The problem we have here looks fairly straight forward. Take a list of all the number 1-infinity and concatenate them into a string. Then find the nth digit. Straight forward problem to understand. The issue that you are seeing though is that we do not have an infinite amount of memory nor time to be able to do this reasonably in a computer program. So we must find an alternative way around this that does not just add the numbers onto a string and then find the nth digit.
The first thing we can say is that we know what the entire list is. It will always be the same. So can we use any properties of this list to help us?
Let's call the input number n. This is the position of the digit that we want to find. Let's call the output digit d.
Well, first off, let's look at some examples.
We know all the single digit numbers are just in the same position as the number itself.
So, for n<10 ... d = n
What about for two digit numbers?
Well, we know that 10 starts at position 10. (Because there are 9 single digit numbers before it). 9 + 1 = 10
11 starts at position 12. Again, 9 single digits + one 2 digit number before it. 9 + 2 + 1 = 12
So how about, say... 25? Well that has 9 single digit numbers and 15 two digit numbers before it. So 25 starts at 9*1 + 15*2 + 1 = 40 (+ 1 as the sum gets us to the end of 24 not the start of 25).
So... 99 starts at? 9*1 + 89*2 + 1 = 188.
The we do the same for the three digit numbers...
100... 9*1 + 90*2 + 1 = 190
300... 9*1 + 90*2 + 199*3 + 1 = 787
1000...? 9*1 + 90*2 + 900*3 + 1 = 2890
OK... so now I'm seeing a pattern here that seems to need to know the number of digits in each number. Well... I can get the number of digits in a number by rounding up the log(base 10) of that number.
rounding up log base 10 of 5 = 1
rounding up log base 10 of 23 = 2
rounding up log base 10 of 99 = 2
rounding up log base 10 of 627 = 3
OK... so I think I need something like...
// in pseudo code
let lengthOfNumber = getLengthOfNumber(n)
var result = 0
for each i from 0 to lengthOfNumber - 1 {
result += 9 * 10^i * (i + 1) // this give 9*1 + 90*2 + 900*3 + ...
}
let remainder = n - 10^(lengthOfNumber - 1) // these have not been added in the loop above
result += remainder * lengthOfNumber
So, in the above pseudo code you can give it any number and it will return the position in the list that that number starts on.
This isn't the exact same as the problem you are trying to solve. And I don't want to solve it for you.
This is just a leg up on how I would go about solving it. Hopefully, this will give you some guidance on how you can take this further and solve the problem that you are trying to solve.
If the octree level is 0, then I have 8 nodes. Now, if the octree level is 1, then I have 72 nodes. But if I have (for example) 500 nodes, how do I calculate what the level would be?
To calculate the max number of nodes at level n you would calculate:
8**1 + 8**2 + 8**3 ... 8**n
So at level 2, that's 8 + 64
This can be generalized as:
((8 ** (h + 1)) - 1)/7 - 1
In javascript you might write:
function maxNodes(h){
return ((8 ** (h + 1)) - 1)/7 - 1
}
for (let i = 1; i < 4; i++){
console.log(maxNodes(i))
}
To find the inverse you will need to use Log base 8 and some algebra and you'll arrive at a formula:
floor (log(base-8)(7 * n + 1))
In some languages like python you can calculate math.floor(math.log(7*n + 1, 8)), but javascript doesn't have logs to arbitrary bases so you need to depend on the identity:
Log(base-b)(n) == Log(n)/Log(b)
and calculate something like:
function height(n){
return Math.floor(Math.log(7 * n + 1)/Math.log(8))
}
console.log(height(8))
console.log(height(72)) // last on level 2
console.log(height(73)) // first on level 3
console.log(height(584)) // last on level 3
console.log(height(585)) // first on level 4
See the code and error. I have already tried Do, For,...and it is not working.
CODE + Error from Mathematica:
Import of survival probabilities _{k}p_x and _{k}p_y (calculated in excel)
px = Import["C:\Users\Eva\Desktop\kpx.xlsx"];
px = Flatten[Take[px, All], 1];
NOTE: The probability _{k}p_x can be found on the position px[[k+2, x -16]
i = 0.04;
v = 1/(1 + i);
JointLifeIndep[x_, y_, n_] = Sum[v^k*px[[k + 2, x - 16]]*py[[k + 2, y - 16]], {k , 0, n - 1}]
Part::pkspec1: The expression 2+k cannot be used as a part specification.
Part::pkspec1: The expression 2+k cannot be used as a part specification.
Part::pkspec1: The expression 2+k cannot be used as a part specification.
General::stop: Further output of Part::pkspec1 will be suppressed during this calculation.
Part of dataset (left corner of the dataset):
k\x 18 19 20
0 1 1 1
1 0.999478086278185 0.999363078716059 0.99927911905056
2 0.998841497412202 0.998642656911039 0.99858030519133
3 0.998121451605207 0.99794428814123 0.99788275311401
4 0.997423447323642 0.997247180349674 0.997174407432264
5 0.996726703362208 0.996539285828369 0.996437857252448
6 0.996019178300768 0.995803204773039 0.99563600297737
7 0.995283481416241 0.995001861216016 0.994823584922968
8 0.994482556091416 0.994189960607964 0.99405569519175
9 0.993671079225432 0.99342255996206 0.993339856748282
10 0.992904079096455 0.992707177451333 0.992611817294026
11 0.992189069953677 0.9919796017009 0.991832027835091
Without having the exact same data files to work with it is often easy for each of us to make mistakes that the other cannot reproduce or understand.
From your snapshot of your data set I used Export in Mathematica to try to reproduce your .xlsx file. Then I tried the following
px = Import["kpx.xlsx"];
px = Flatten[Take[px, All], 1];
py = px; (* fake some py data *)
i = 0.04;
v = 1/(1 + i);
JointLifeIndep[x_, y_, n_] := Sum[v^k*px[[k+2,x-16]]*py[[k+2,y-16]], {k,0,n-1}];
JointLifeIndep[17, 17, 12]
and it displays 362.402
Notice I used := instead of = in my definition of JointLifeIndep. := and = do different things in Mathematica. = will immediately evaluate the right hand side of that definition. This is possibly the reason that you are getting the error that you do.
You should also be careful with your subscript values and make sure that every subscript is between 1 and the number of rows (or columns) in your matrix.
So see if you can try this example with an Excel sheet containing only the snapshot of data that you showed and see if you get the same result that I do.
Hopefully that will be enough for you to make progress.
Isn't it true that if a bias is not present, a line passing through origin should be able to linearly separate the two data sets??
But the most popular answer in this -->> question says
y
^
| - + \\ +
| - +\\ + +
| - - \\ +
| - - + \\ +
---------------------> x
stuck like this
I am confused about it. Do you mean the origins in figure above are somewhere in middle of x-axis and y-axis? Can somebody please help me and clarify this?
Alright, so perhaps the original ASCII graph was not 100% accurate! Let me try to depict this again:
y y
^ ^
- + \\ | + -\\+ | +
- +\\ | + + - \\ + | + +
- - \\ | + - - \\ | +
- - + \\| + - - \\+ | +
------------------------> x ---------------------------> x
- - |\\ + - - \\ | +
- - + | \\ + - - \\ + | +
- - - | \\ + + - - -\\ | + +
-- - - | +\\ ++ -- - - \\ | + ++
stuck like this needs to get like this
y = ax y = ax + b
(w0*x + w1*y = 0) (w0*x + w1*y + w2*1 = 0)
I think your intuition is correct on this issue:
Do you mean the origins in figure above are somewhere in middle of x-axis and y-axis?
In my reading of the graph, yes.
I think the ASCII graph, as cool as it is, is a bit confusing here, because it shows a line that is not traveling through what would normally be considered as the origin. Normally one would think of the intersection of the x- and y-axis lines as the origin, but in this diagram the separating line is clearly not passing through said intersection. As you've noted, a perceptron without a bias term can only define a separating line that passes through the origin, so the ASCII graph must have some sort of odd origin that is floating out in space somewhere.
Also, note that a standard perceptron always defines a linear separator, but a linear separator is not guaranteed to be able to partition a given dataset correctly -- that depends completely on the dataset. There are also variants of the perceptron that use the "kernel trick" to define nonlinear separators, but that's a whole different story. :)
Hope that helps.
for Temp = 1000:10:6000
cp_CO2 = ((2e-18)*Temp.^5) - ((4e-14)*Temp.^4) + ((3e-10)*Temp.^3) - ((8e-07)*Temp.^2) + (0.0013*Temp) + 0.5126;
cp_CO = ((5e-12)*Temp.^3) - ((7e-08)*Temp.^2) + (0.0003*Temp) + 0.9657;
cp_H2O = ((7e-12)*Temp.^3) - ((1e-07)*Temp.^2) + (0.0008*Temp) + 1.6083;
cp_N2 = ((-1e-18)*Temp.^5) + ((2e-14)*Temp.^4) - ((8e-11)*Temp.^3) + ((1e-07)*Temp.^2) + (0.0001*Temp) + 0.9985;
D_H = (y(1)*cp_CO2*44*(25-Temp)) + (y(2)*cp_CO*28*(25-Temp)) + (y(3)*cp_H2O*18*(25-Temp)) + (percent_air*x_final(2)*3.76*28*(25-Temp));
DELTA_H = round(D_H);
if DELTA_H == delta_h
break
end
end
The 'for' loop in my code is above, the variables delta_h, y and percent_air have been defined and calculated/input earlier. If I work on the loop as a cell and manually increase Temp then the values of D_H etc. all change. But for some reason when I try and execute the loop the 'if' statement doesn't seem to come into effect and the final values where Temp = 6000 are displayed in the workspace instead of the value of Temp where it produces a DELTA_H equal to that of delta_h. It's the first time I've used MATLAB for about 2 years (I'm a 3rd Year Mech Eng student) so please forgive me if it's a simple error to fix.
If either of the variables are floating-point, doing an exact compare like that is problematic. A <= or >= comparison might work better.