Background:
I asked this question yesterday:
How to modify the orientation of a <ul> spanning multiple columns?
asking how to convert a list like this:
a b c
d e f
g h i
j k l
into a list like this:
a e i
b f j
c g k
d h l
and I got this awesome response by beeflavor: http://jsfiddle.net/H4FPw/12/
Problem:
Unfortunately I didn't specify that there could be any number of list items, so his response is hard-coded to 4 rows, and uses a tricky matrices algorithm (read: black magic) that I can't wrap my head around.
I'm poking and prodding at this, trying to add variability but unfortunately it's not coming together for me and today's the deadline for this stuff.
This is an updated example of the problem I'm having: http://jsfiddle.net/H4FPw/13/
Is there anyone out there with a better head for this stuff who can give me a steer in the right direction?
I know it's not as "elegant" as your accepted answer in that question, but the code I linked to in my answer yesterday does work perfectly for you:
http://jsfiddle.net/AcdcD/
If you don't need to handle resizing, it can be simplified slightly:
http://jsfiddle.net/AcdcD/1/
Maybe you can use this if you run out of time?
jQuery plugin .transpose()
Exactly what you want it to do. I needed the same thing so I've written a general jQuery plugin that transposes any floated or inline-blocked elements that seem to be in columns but their order goes in rows.
Check out my detailed blog post with an example for transposing US states, and then head over to GitHub where the plugin is maintained and you can get a minified version (915 bytes as of version 1.2) of it as well.
All you need to do is:
$("yourSelector").transpose();
In your case that would be
$("li").transpose();
The good thing is that plugin checks how many columns are there originally (before transposition) and transposes to the same amount of columns afterwards. It doesn't add any additional HTML elements into DOM (like floated column wrappers or similar) it just rearranges existing elements. This is very good when it comes to CSS settings of the page because it doesn't interfere with them in any way shape or form.
And it also distinguishes between different lists of elements (items that are contained within different containers) as if you'd have two UL elements that need transposition. You don't have to call .transpose() on each because plugin will do that for you. You'd still just use the same selector as previously written.
What about this code:
jsfiddle
// I add a number of new elements to the <ul>, in this case, 'm', 'n', 'o' &'p'
var rowcount = 6; // I increase rowcount from 4 to 6 to accommodate the new elements
var colcount = 3;
var ichild=$('.directory-result-list-bottom').children();
var wf= "<li class='directory-result-text'>";
var wb= "</li>"
var k="";
var u;
var v;
var carryover=0;
$('.directory-result-list-bottom').empty();
for(var i = 0; i<rowcount; i++){
carryover=0;
for(var j=0; j<colcount; j ++){
k=k+wf+(ichild[(j*rowcount)+i].innerHTML)+wb;
}
}
document.getElementById('place').innerHTML=k;
I believe empty LI's are needed to fill the empty space.
This should work:
for(var i = 0; i<rowcount; i++){
for(var j=0; j<colcount; j ++){
var n = (j*rowcount)+i;
if (ichild[n])
k=k+wf+(ichild[n].innerHTML)+wb;
else
k = k + wf + wb
}
}
I think it's simpler to represent the items as a 1-D list (a,b,c...) and think about how to 1) get that from the original array and 2) transform it into the output array.
Step 1 is easy, because the 1-D list is the same order as the <li> elements in the HTML source.
So, suppose we have n elements and we want to put them into R rows and C columns but filling columns first. The element that goes in position (r,c) (0 based) is just element #R*c + r. And, as stated before, the order in the source file is the row-first order, or (0,0), (0,1), (0,2), ...
If the # of elements doesn't fill the RxC grid exactly, then you have to add checks that the computed element number doesn't exceed n (easiest way is to pad the list with empty elements beforehand).
Depending on the design requirements, you can also adapt this to minimize the number of blank elements given a fixed number of rows or columns.
Related
A small application that I have written allows a user to add various items to two arrays. Some logic calculates a figure from the contents of each array.
Any items in array x can be placed into array y, and back again. Items belonging in array y can never be moved (unless they were moved from array x).
The user can move these items around in two lists using a simple javascript ui. To make things simpler, I originally made a naive script which:
Moved an item from a to y.
Performed some logic using this 'possibility'
If the result was less than before, leave x in y.
If not, then x remains in x.
Move on to next item in x and repeat.
I knew that this was ineffective. I have read around and have been told do this using bitwise math to remember the possibilities or 'permutations' but I am struggling to get my head around this particular problem at this stage.
If anyone would be able to explain (pseudo code is fine) what would be the best way to achieve the following I would be very grateful.
array x = [100,200,300,400,500]
array y = [50,150,350,900]
With these two arrays, for each value from x, push every combination of that value and all the other values from x into array y. For each one I will perform some logic (i.e. test result and store this 'permutation' in an array (an object of two arrays representing x and y). I foresee this as being quite expensive with large arrays, likely to repeat a lot of combinations. I feel like I'm almost there, but lost at this last stage.
Sorry for the long explanation, and thanks in advance!
Use this for creating the power set of x:
function power(x, y) {
var r = [y || []], // an empty set/array as fallback
l = 1;
for (var i=0; i<x.length; l=1<<++i) // OK, l is just r[i].length, but this looks nicer :)
for (var j=0; j<l; j++) {
r.push(r[j].slice(0)); // copy
r[j].push(x[i]);
}
return r;
}
Usage:
> power([0,2], [5,6])
[[5,6,0,2], [5,6,2], [5,6,0], [5,6]]
I have been told do this using bitwise math to remember the possibilities or 'permutations' but I am struggling to get my head around this particular problem at this stage.
It would be iterating to 2n (for an array of length n), using single bits to determine whether an item should be included in the subset. Example for an array [a,b]:
i binary included in set
-----------------------------
0 00 { }
1 01 { b }
2 10 { a }
3 11 { a, b }
We can use bitwise operators in JS for arrays with up to 31 items (which should be enough).
function power(x, y) {
var l = Math.pow(2, x.length),
r = new Array(l);
for (var i=0; i<l; i++) {
var sub = y ? y.slice(0) : [];
for (var j=0; j<x.length; j++)
// if the jth bit from the right is set in i
if (i & Math.pow(2,j)) // Math.pow(2,j) === 1<<j
sub.push(x[j]);
r[i] = sub;
}
return r;
}
I wonder if it is possible (in javascript or jquery but without any plugins) to get all elements (for example table rows tr) in current viewport without looping through each of them? I found a lot of examples how to check if specified element is in current viewport, but what I need is a function returns a list of all elements in current viewport. I need this for virtualization because this table should have an infinite capacity and looping through each row from two millions rows is quite inefficient :)
Is there any reasonable way to do this?
Assuming you're not doing anything fancy with positioning, table rows in the viewport can be found with a binary search. For example, for 200000 rows, about 18 lookups are required to locate the first row on the page (jsfiddle, warning: slow to load). This can be extended to find the last element as well, or you could just loop through the elements starting from the first until you find one that is no longer visible.
var rows = table.children().children();
var start = 0;
var end = rows.length;
var count = 0;
while(start != end) {
var mid = start + Math.floor((end - start) / 2);
if($(rows[mid]).offset().top < document.documentElement.scrollTop)
start = mid + 1;
else
end = mid;
}
Obviously this does not work well if anything is floated, absolutely positioned, etc. In short: The nodes being searched must be in order such that rows[N-1].top <= rows[N].top. For something such as a table, this should be true if no styling is applied and no multi-row cells exist.
I really need an master of algorithm here! So the thing is I got for example an array like this:
[
[870, 23]
[970, 78]
[110, 50]
]
and I want to split it up, so that it looks like this:
// first array
[
[970, 78]
]
// second array
[
[870, 23]
[110, 50]
]
so now, why do I want it too look like this?
Because I want to keep the sum of sub values as equal as possible. So 970 is about 870 + 110 and 78 is about 23 + 50.
So in this case it's very easy because if you would just split them and only look at the first sub-value it will already be correct but I want to check both and keep them as equal as possible, so that it'll also work with an array which got 100 sub-arrays! So if anyone can tell me the algorithm with which I can program this it would be really great!
Scales:
~1000 elements (sublists) in the array
Elements are integers up to 10^9
I am looking for a "close enough solution" - it does not have to be the exact optimal solution.
First, as already established - the problem is NP-Hard, with a reduction form Partition Problem.
Reduction:
Given an instance of partition problem, create lists of size 1 each. The result will be this problem exactly.
Conclusion from the above:
This problem is NP-Hard, and there is no known polynomial solution.
Second, Any exponential and pseudo polynomial solutions will take just too long to work, due to the scale of the problem.
Third, It leaves us with heuristics and approximation algorithms.
I suggest the following approach:
Normalize the scales of the sublists, so all the elements will be in the same scale (say, all will be normalzied to range [-1,1] or all will be normalized to standard normal distribution).
Create a new list, in which, each element will be the sum of the matching sublist in the normalized list.
Use some approximation or heuristical solution that was developed for the subset-sum / partition problem.
The result will not be optimal, but optimal is really unattanable here.
From what I gather from the discussion under the original post, you're not searching for a single splitting point, but rather you want to distribute all pairs among two sets, such that the sums in each of the two sets are approximately equal.
Since a close enough solution is acceptable, maybe you could try an approach based on simulated annealing?
(see http://en.wikipedia.org/wiki/Simulated_annealing)
In short, the idea is that you start out by randomly assigning each pair to either the Left or the Right set.
Next, you generate a new state by either
a) moving a randomly selected pair from the Left to the Right set,
b) moving a randomly selected pair
from the Right to the Left set, or
c) doing both.
Next, determine if this new state is better or worse than the current state. If it is better, use it.
If it is worse, take it only if it is accepted by the acceptance probability function, which is a function
that initially allows worse states to be used, but favours them less and less as time moves on (or the "temperature decreases", in SA terms).
After a large number of iterations (say 100.000), you should have a pretty good result.
Optionally, rerun this algorithm multiple times because it may get stuck in local optima (although the acceptance probability function attempts to counter this).
Advantages of this approach are that it's simple to implement, and you can decide for yourself how long
you want it to continue searching for a better solution.
I'm assuming that we're just looking for a place in the middle of the array to split it into its first and second part.
It seems like a linear algorithm could do this. Something like this in JavaScript.
arrayLength = 2;
tolerance = 10;
// Initialize the two sums.
firstSum = [];
secondSum = [];
for (j = 0; j < arrayLength; j++)
{
firstSum[j] = 0;
secondSum[j] = 0;
for (i = 0; i < arrays.length; i++)
{
secondSum += arrays[i][j];
}
}
// Try splitting at every place in "arrays".
// Try to get the sums as close as possible.
for (i = 0; i < arrays.length; i++)
{
goodEnough = true;
for (j = 0; j < arrayLength; j++)
{
if (Math.abs(firstSum[j] - secondSum[j]) > tolerance)
goodEnough = false;
}
if (goodEnough)
{
alert("split before index " + i);
break;
}
// Update the sums for the new position.
for (j = 0; j < arrayLength; j++)
{
firstSum[j] += arrays[i][j];
secondSum[j] -= arrays[i][j];
}
}
Thanks for all the answers, the bruteforce attack was a good idea and NP-Hard is related to this too, but it turns out that this is a multiple knapsack problem and can be solved using this pdf document.
I have build a grid of div's as playground for some visual experiments. In order to use that grid, i need to know the x and y coordinates of each div. That's why i want to create a table with the X and Y position of each div.
X:0 & Y:0 = div:eq(0), X:0 Y:1 = div:eq(1), X:0 Y:2 = div:eq(2), X:0 Y:3 = div:eq(3), X:1 Y:0 = div:eq(4) etc..
What is the best way to do a table like that? Creating a OBJECT like this:
{
00: 0,
01: 1,
02: 2,
etc..
}
or is it better to create a array?
position[0][0] = 0
the thing is i need to use the table in multiple way's.. for example the user clicked the div nb: 13 what are the coordinates of this div or what is the eq of the div x: 12 y: 5.
Thats how i do it right now:
var row = 0
var col = 0
var eq = 0
c.find('div').each(function(i){ // c = $('div#stage')
if (i !=0 && $(this).offset().top != $(this).prev().offset().top){
row++
col = 0
}
$(this).attr({'row': row, 'col': col })
col++
})
I think it would be faster to build a table with the coordinates, instead of adding them as attr or data to the DOM. but i cant figure out how to do this technically.
How would you solve this problem width JS / jQuery?
A few questions:
Will the grid stay the same size or will it grow / shrink?
Will the divs stay in the same position or will they move around?
Will the divs be reused or will they be dynamically added / removed?
If everything is static (fixed grid size, fixed div positions, no dynamic divs), I suggest building two indices to map divs to coordinates and coordinates to divs, something like (give each div an id according to its position, e.g. "x0y0", "x0y1"):
var gridwidth = 20, gridheight = 10,
cells = [], // coordinates -> div
pos = {}, // div -> coordinates
id, i, j; // temp variables
for (i = 0; i < gridwidth; i++) {
cells[i] = [];
for (j = 0; j < gridheight; j++) {
id = 'x' + i + 'y' + j;
cells[i][j] = $('#' + id);
pos[id] = { x: i, y: j };
}
}
Given a set of coordinates (x, y) you can get the corresponding div with:
cells[x][y] // jQuery object of the div at (x, y)
and given a div you can get its coordinates with:
pos[div.attr('id')] // an object with x and y properties
Unless you have very stringent performance requirements, simply using the "row" and "col" attributes will work just fine (although setting them through .data() will be faster). To find the div with the right row/col, just do a c.find("div[row=5][col=12]"). You don't really need the lookup.
Let me elaborate on that a little bit.
If you were to build a lookup table that would allow you to get the row/col for a given div node, you would have to specify that node somehow. Using direct node references is a very bad practice that usually leads to memory leaks, so you'd have to use a node Id or some attribute as a key. That is basically what jQuery.data() does - it uses a custom attribute on the DOM node as a key into its internal lookup table. No sense in copying that code really. If you go the jQuery.data() route, you can use one of the plugins that allows you to use that data as part of the selector query. One example I found is http://plugins.jquery.com/project/dataSelector.
Now that I know what it's for...
It might not seem efficient at first, but I think It would be the best to do something like this:
Generate the divs once (server side), give them ids like this: id="X_Y" (X and Y are obviously numbers), give them positions with CSS and never ever move them. (changing position takes a lot of time compared to eg. background change, and You would have to remake the array I describe below)
on dom ready just create a 2D array and store jquery objests pointing the divs there so that
gridfields[0][12] is a jQuery object like $('#0_12'). You make the array once and never use selectors any more, so it's fast. Moreover - select all those divs in a container and do .each() on them and put them to proper array fields splitting their id attributes.
To move elements You just swap their css attributes (or classes if You can - it's faster) or simply set them if You have data that has the information.
Another superfast thing (had that put to practice in my project some time ago) is that You just bind click event to the main container and check coordinates by spliting $(e.target).attr('id')
If You bind click to a grid 100x100 - a browser will probably die. Been there, did that ;)
It may not be intuitive (not changing the div's position, but swapping contents etc.), but from my experience it's the fastest it can get. (most stuff is done on dom ready)
Hope You use it ;) Good luck.
I'm not 100% sure that I understand what you want, but I'd suggest to avoid using a library such as jQuery if you are concerned about performance. While jQuery has become faster recently, it still does has more overhead than "pure" JS/DOM operations.
Secondly - depending on which browsers you want to support - it may even be better to consider using a canvas or SVG scripting.
JavaScript performance in Internet Explorer sucks. No news there. However there are some tips and tricks to speed it up. For example, there is this three part series. Still I find myself unable to squeeze decent performance out of it. Perhaps some of you have an idea what else to do so it was speedier?
What I want to do is create a medium-size table from scratch in Javascript. Say, 300 rows, 10 cells each. It takes at about 5-6 seconds on my computer to do this. OK, granted, it's a 5 year old rig, but that's still too much. Here's my dummy code:
<html>
<body>
<script type="text/javascript">
function MakeTable(parent)
{
var i, j;
var table = document.createElement('table');
var insertRow = table.insertRow;
for ( i = 0; i < 300; i++ )
{
var row = insertRow(-1);
for ( j = 0; j < 10; j++ )
{
var cell = row.insertCell(-1);
cell.innerHTML = i + ' - ' + j;
}
}
parent.appendChild(table);
}
</script>
<div onclick="MakeTable(this);">Click Me!</div>
</body>
</html>
Added: Hmm, apparently string-concatenation (with array.join) is the only way to go. Well, sad, of course. Was hoping to do it the "proper" DOM-way. :)
Here is an interesting link I found when looking for an answer on this:
The page uses five different scripts / methods to generate a table.
According to their tests, using strings is by far faster than using DOM / Table elements.
http://www.quirksmode.org/dom/innerhtml.html
One of the main reason's for IE's performance issues are DOM operations. You want to do your DOM operations as efficiently as possible. This can include, depending on your situation (benchmark!):
Offline creation of your DOM structure; keep the top level element out of the document (create, but not append) then appending it to the document when it's ready, instead of appending every element into the DOM as you create it
write innerHTML instead of DOM manipulation
You could try 'Duff's Device': Unwinding a loop by repeating the code a number of times:
for (var i = 0; i < count / 4; i++) {
doSomething();
doSomething();
doSomething();
doSomething();
}
Obviously this leaves the remainder when divided by 4, the original Duff's Device had a clever way of jumping to the middle of the loop using a switch statement mixed in with the loop. Javascript does not support this, but you could manually process the rest of your rows. Also the number 4 is random, the number itself can be derived by performance testing.
See also: http://www.websiteoptimization.com/speed/10/10-3.html