I understand that table and cells are supported only in PDFClown version 2.0 but that is only a few months away. So, being stuck with version 1.2, how do I create a spreadsheet having 2 columns (& another spreadsheet having 3 columns)?
Anything with examples to point me in the right direction.
As you noticed, the layout engine supporting tables and lots of other high-level typographic elements is scheduled for 0.2.0 (its Java implementation will be pre-released for evaluation and beta-testing); in the meantime you can coarsely arrange a table this way:
define the table partition (columns) on the page and draw the corresponding rectangles through the PrimitiveComposer;
insert in each column area your contents through BlockComposer, keeping track of the maximum y occupied by your contents (this is calculated when you call BlockComposer.End(), after which you can retrieve the bounding box of your contents via BlockComposer.BoundBox);
when you complete the columns for the current table row, use the maximum y saved in step 2 to draw the bottom line which closes the row and iterate back to step 2 until you run out of rows;
if you run out of space while inserting contents, keep track of the positions returned by BlockComposer.ShowText() and BlockComposer.ShowXObject(): this way you can fill each column, then move to the next page and resume the insertion according to the tracked positions.
This should suffice to get the job done. ;-)
I am trying to apply a save method in a backing Java bean which will take the table rows that are selected and save them in the database. However, let's say the user changes his choices a little (changes 1 out of his 5 choices). I am wondering about the algorithm I am going to apply if it matters in efficiency in the long term or not....
here it goes :
every time the user clicks the button (save) I will delete all his previous choices and insert all the current choices to the database
once the button is clicked --- see which rows the user de-selected and delete their rows from the database and add the new ones???
is choice number 2 better or not than choice 1 .......or it doesn't really matter for number of choices that will not exceed 15 ??
Thanks
I would definitely go for option 2, try to figure out the minimum number of operations you need to perform.
It is, however, fairly normal to fall back to option 1 in times of deadlines etc. since it is a bit easier to implement.
There shouldn't, however, be that much harder to figure out what the changes are, since it doesn't seem to me that you're changing the rows themselves. Either you're deleting ones that had their checkmark cleared, or you insert ones that had their checkmark set.
Simply store a list of primary key values of whatever is in the database, then compare to that list when you iterate through the new list when the user wants to persist the changes.
A minimal work solution here would also mean you would be a bit more future-proof in terms of refactoring, changes, or additions. For instance, what if there in the future is data attached to any of those rows. You would need to keep that as well. Generally I'm a bit opposed to writing code just for the sake of "what if", but here I feel it's more like "why wouldn't you ..." than that.
So my advice is go for option 2. Not much more work.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
The community reviewed whether to reopen this question 10 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
In a sorted table, it's common to have an up or a down arrow indicating the sort style. However, I'm having some trouble determining which direction the arrow should point. In an ASC sort, characters are sorted 1-9A-Za-z. Should the arrow point up or down?
I've found implementations of both on the web, so that didn't help me much: Up and Down (you have to create the table first).
Is there a hard and fast rule for this? I find myself able to justify both implementations. Which method do you use? Which is more intuitive to you and why?
Edit: Some of you have suggested alternate implementations like rising bars or having letters with an arrow indicating sort direction. Great suggestions. I'm definitely open to other options. The less ambiguous, the better. It might be picky, but I'd really like there to be minimal or no confusion on the part of the user.
Edit: I ended up going with the rising and falling bars for now. It's not standard, but seems less ambiguous than the triangles. The current sort column shows three bars, small to large (left to right) for ASC, the opposite for DESC. Other sortable columns have no bars by default, but hovering over any sortable column heading (including the current) shows bars depicting how the table will be sorted if that column heading is clicked.
I don't think of them as arrows, but as a visual mnemonic of the current state. So, showing a triangle pointing down shows descending order. It is visually in line with the icon with the largest item (base of the triangle) at the top of the list and the smallest (point of the triangle) at the bottom.
I've always went with the following:
Ascending -- Arrow pointing up
Descending -- Arrow pointing down
In my opinion, the visual representation of the arrow pointing up/down most accurately explains the sort order.
I’ve done usability tests on this. There does not appear to be a consistent interpretation among users on what the arrows mean. I seem to recall that even each user was not consistent, thinking the arrow down meant ascending in one case and descending in another. I tried arrows to left and right (“forward” versus “backwards” sort), but they failed to be interpreted consistently too. I tried showing current state and showing the state that would result. Neither worked.
What did work was a schematic text depiction of the sort order: “A..Z” and “Z..A” for alpha, “1..9” and “9..1” for numeric, “1..12” and “12..1” for dates (the usability test used mm/dd/yy date format).
Show this text as read-only indicating the current state. Place a button beside the text to set or swap the sort order.
Didn’t try the rising/falling bar icon, but I expect it can run into difficulties where “bigger” is ambiguous. For example, is an older date in the past bigger (longer ago) or smaller (closer to Time 0) than a more recent date? Is Priority 1 bigger or smaller than Priority 2? Grade A bigger or smaller than Grade B? For that matter, who, other than geeks, thinks that “Zuschlag” is vastly bigger than “Abbott”? Not that I’m taking this personally, of course.
For some reason I feel is always backwards. For me the down pointing arrow/triangle should represent the way I usually read things (from top to bottom -> from a to z) and the up pointing arrow is backwards from the way I read things (from z to a). But that's just me, since most popular UIs (Mac, Windows, etc. etc.) use it the other way, they must know something :).
In any case consistency with what the user is used to is a good option.
My favorite is actually the way that e.g. Excel handles it -- don't use an arrow, but rather a custom icon with
A |
Z V
for ascending sort and
Z |
A V
for descending sort. Nobody will ever wonder which way you're sorting.
Now, if you can't use a custom icon but rather need a printable character, I'd say people are about as likely to be confused by either one. Windows uses the "small part of arrow corresponds to smaller value" for Explorer, which is to say that ascending sort points up. But plenty of other sources assume that the base of the arrow starts at the lowest value and points in the direction of the sort, which frankly makes as much sense as anything else. In other words, half your users will probably have to adjust either way.
Ascending : Arrow pointing up
Descending : Arrow pointing down
Tricks to remember:
Alphabets:
A scending i.e. A B C D
D escending i.e. D C B A
Numbers:
A=1,B=2...Z=26.
Ascending A B C D so 1 2 3 4 i.e. small to large
Descending D C B A so 4 3 2 1 i.e. large to small
Date:
Date is actually converts to a number, it increase on day base, so it works again a number system. today is bigger than yesterday, today is smaller than tomorrow.
I like:
arrow pointing down for ascending
order
arrow pointing up for
descending order
Why? Because it feels like I just sorted the page. I clicked on the heading and it was "Wow! Sorted top-to-bottom". Why "top-to-bottom" is called ascending, is because the numbers/letters get higher in value as the computer writes to the screen. The opposite for descending. However, the list is actually descending down the screen from the top to the bottom - a to z. When you order it the other way, the beginning of the list is at the bottom of the screen.
So to the physical human mental logic - the kind that means clockwise is close and counter-clockwise is open, it makes sense to ignore how the machine sorts and outputs the data, and think rather about how a human might sort data: start at the beginning (smallest values) and at the top of the paper, then advance through to the end (largest value) on down the paper.
The reason the beginning is smallest, is because 1 comes before 2, and the Roman alphabet starts with A and end with Z. So this is sort of default for us humans at this point in time. We write top to bottom and left to right. It has to do with handedness and the way we hold paper - I think. I'm not actually human interface specialist. I just thought about why it seems more natural. The KDE guys are human interface specialists. Take a look how Oxygen is done.
The other way I think is alright is a triangle that is actually showing that the data is smallest to largest. Again, this is rather technical and at first glance, the human might not "get it".
in the classic Finder, Apple didn't use arrows. instead, there were a small icon that looked like three (or four?) horizontal lines of increasing or decreasing length. at first sight, it was like a triangle; but when looking at it, it was clear if it was getting bigger or smaller.
other GUIs (KDE, for example) use triangles, but most people interpret them as arrows, making the message ambiguous.
An arrow pointing up usually means larger or getting larger, so that should be used for Ascending order.
An arrow pointing downwards usually means something is smaller or getting smaller and it should be used for Descending order.
I expect the arrows to show the current state (pointing up when the list is currently ascending). The is what Windows Explorer does in Details View.
The other thing that you need to consider is whether the arrow represents the current sort direction or the sort direction that will be applied if you click on the arrow. (Not always obvious from the contents of the table as there can be arrows on every column)
Sorry to add to the confusion, but you need to consider this.
Clarification on this front can be partially achieved by adding a suitably worded tooltip to the arrow.
"Is there a hard and fast rule for this?" - Apparently not, since you found examples of both.
For general consistency, I'd say that the arrow should point up for ascending, down for descending. This is consistent with Windows (click a column header in Explorer) and Office (filter/sort a column in Excel).
Best place to check, in my opinion.. would be large corporate websites like amazon, dabs etc. as these will be what users are most used to.
I think everybody agrees that the direction of the arrow requires the users to think about its meaning. What does a down arrow mean? A-Z or Z-A? What does it mean when sorting dates? It is clear only when the user looks at the actual sorted data.
For this reason, I find it best not to use any indication of direction. It is enough to indicate the fact that rows are sorted by a certain column. It is important to find out which way the users usually expect the rows to be sorted for the first click. The second click reverses the order, the third click turns sorting off.
I have implemented this several times and users have no problem sorting the rows by different columns the way they like.
This is a highly opinionated question. But here is a logical solution and the reason behind why I chose it :
Solution:
If using an arrow to display sort order in a Table Column, it will be better to use a Down arrow for ascending and vice versa.
Reasons:
If we are referring to a picture or a graph, where visual and value based traversal are both in the same direction, using "Ascending" or "Descending" will serve its purpose as intended. But when it comes to Tables, the main source of confusion is that, the values are traversed to higher values (upward, but only conceptually) but the direction of visual traversal is downward. And since an arrow is a visual clue (direction) it might be easier for someone to understand the directional traversal better with it.
For many people the concept of ascending and descending are understandable in terms of values. But in certain cases, the users of that table might not be aware of these concepts. For example, someone who has never been to school or a primary school kid or someone completely new to digital world. For them, directional concept will be easier to understand. As in a-z, upward or downward. As in 1-9 upward or downward. It is to be noted that educated or experienced users can understand it either way (the 4th reason).
Next reason is that whether we are masters in digital tables or not, we have always written lists and tables. And in almost all the cases, we write it in ascending order in downward directions. So, it is somewhat hardwired to our brain.
Finally, the confusion on this issue always existed and a universal method is always better. To this day, I always analyse how the values are sorted to see if it is in ascending or descending order. The directional arrows never served its purpose since it is not reliable. For educated or experienced users knowing the order immediately will not be a problem. When we create a universal standard though, we must see to it that every probable user would be 'able' to understand it...
How I use it:
I use a tailed arrow for numbers, alphabets or any other values increasing progressively while traversing in that direction.
Since the values are increasing (by default), user can call it Ascending if he wants to, but the arrow is downwards. This also helps me in sorting 'word sets' (for example, the status of a record in the table. It may not be sorted in alphanumeric order but in order of status progression).
Hope this helped.
Remember that descending is for down. So, I would use the down arrow for descending. But, I always get confused by this anyway. I recommend that you use letters instead, like A-Z and Z-A instead of the arrows. Or, use them in conjunction with the arrows.
There is no hard and fast rule, but the best approach is to reduce the apparent complexity for the user, using the best mapping of down and up arrows to the terminology "Ascending" and "Descending".
Note that most non-numeric concepts doesn't have a strong natural mapping to "up" or "down".
Do letters/words go "up" or "down" in the dictionary? How about dates and times? Where it is ambiguous, I believe there is no "right" answer - I recommend allowing "Descending" to represent the more useful sort order for consistency, as the user is likely to think about the table as being "down" as they move their eyes down. Leaving aside digital representations since the users of most applications do not know or care about the internal representation. Therefore alphabet sorting could be "Descending" for A-Z, and time could be Descending with most recent first. The good news is, as long as the first click gives the user the sorting behavior that they expect, and the second reverses it, they mostly won't care which of the two modes is used.
That challenge about the correct sort to do "first" (on showing the content, or sorting on a new column) is the more important implication of the question. The type AND intended usage of the information determines it should sort. Alphabetic should always default A-Z, "descending" by my above logic. Numbers vary much more by use: numbers that represent sequential identifiers, say, an employee ID would be ascending (1-10), while sorting on quantities or price would usually be descending, to bring the largest values to the top. Time also varies - most recent first ("Descending") usually works but in some contexts, the oldest should be listed first.
To experiment, I've (long ago) implemented Conway's Game of Life (and I'm aware of this related question!).
My implementation worked by keeping 2 arrays of booleans, representing the 'last state', and the 'state being updated' (the 2 arrays being swapped at each iteration). While this is reasonably fast, I've often wondered about how to optimize this.
One idea, for example, would be to precompute at iteration N the zones that could be modified at iteration (N+1) (so that if a cell does not belong to such a zone, it won't even be considered for modification at iteration (N+1)). I'm aware that this is very vague, and I never took time to go into the details...
Do you have any ideas (or experience!) of how to go about optimizing (for speed) Game of Life iterations?
I am going to quote my answer from the other question, because the chapters I mention have some very interesting and fine-tuned solutions. Some of the implementation details are in c and/or assembly, yes, but for the most part the algorithms can work in any language:
Chapters 17 and 18 of
Michael Abrash's Graphics
Programmer's Black Book are one of
the most interesting reads I have ever
had. It is a lesson in thinking
outside the box. The whole book is
great really, but the final optimized
solutions to the Game of Life are
incredible bits of programming.
There are some super-fast implementations that (from memory) represent cells of 8 or more adjacent squares as bit patterns and use that as an index into a large array of precalculated values to determine in a single machine instruction if a cell is live or dead.
Check out here:
http://dotat.at/prog/life/life.html
Also XLife:
http://linux.maruhn.com/sec/xlife.html
You should look into Hashlife, the ultimate optimization. It uses the quadtree approach that skinp mentioned.
As mentioned in Arbash's Black Book, one of the most simple and straight forward ways to get a huge speedup is to keep a change list.
Instead of iterating through the entire cell grid each time, keep a copy of all the cells that you change.
This will narrow down the work you have to do on each iteration.
The algorithm itself is inherently parallelizable. Using the same double-buffered method in an unoptimized CUDA kernel, I'm getting around 25ms per generation in a 4096x4096 wrapped world.
what is the most efficient algo mainly depends on the initial state.
if the majority of cells is dead, you could save a lot of CPU time by skipping empty parts and not calculating stuff cell by cell.
im my opinion it can make sense to check for completely dead spaces first, when your initial state is something like "random, but with chance for life lower than 5%."
i would just divide the matrix up into halves and start checking the bigger ones first.
so if you have a field of 10,000 * 10,000, you´d first accumulate the states of the upper left quarter of 5,000 * 5,000.
and if the sum of states is zero in the first quarter, you can ignore this first quarter completely now and check the upper right 5,000 * 5,000 for life next.
if its sum of states is >0, you will now divide up the second quarter into 4 pieces again - and repeat this check for life for each of these subspaces.
you could go down to subframes of 8*8 or 10*10 (not sure what makes the most sense here) now.
whenever you find life, you mark these subspaces as "has life".
only spaces which "have life" need to be divided into smaller subspaces - the empty ones can be skipped.
when you are finished assigning the "has life" attribute to all possible subspaces, you end up with a list of subspaces which you now simply extend by +1 to each direction - with empty cells - and perform the regular (or modified) game of life rules to them.
you might think that dividn up a 10,000*10,000 spae into subspaces of 8*8 is a lot os tasks - but accumulating their states values is in fact much, much less computing work than performing the GoL algo to each cell plus their 8 neighbours plus comparing the number and storing the new state for the net iteration somewhere...
but like i said above, for a random init state with 30% population this wont make much sense, as there will be not many completely dead 8*8 subspaces to find (leave alone dead 256*256 subpaces)
and of course, the way of perfect optimisation will last but not least depend on your language.
-110
Two ideas:
(1) Many configurations are mostly empty space. Keep a linked list (not necessarily in order, that would take more time) of the live cells, and during an update, only update around the live cells (this is similar to your vague suggestion, OysterD :)
(2) Keep an extra array which stores the # of live cells in each row of 3 positions (left-center-right). Now when you compute the new dead/live value of a cell, you need only 4 read operations (top/bottom rows and the center-side positions), and 4 write operations (update the 3 affected row summary values, and the dead/live value of the new cell). This is a slight improvement from 8 reads and 1 write, assuming writes are no slower than reads. I'm guessing you might be able to be more clever with such configurations and arrive at an even better improvement along these lines.
If you don't want anything too complex, then you can use a grid to slice it up, and if that part of the grid is empty, don't try to simulate it (please view Tyler's answer). However, you could do a few optimizations:
Set different grid sizes depending on the amount of live cells, so if there's not a lot of live cells, that likely means they are in a tiny place.
When you randomize it, don't use the grid code until the user changes the data: I've personally tested randomizing it, and even after a long amount of time, it still fills most of the board (unless for a sufficiently small grid, at which point it won't help that much anymore)
If you are showing it to the screen, don't use rectangles for pixel size 1 and 2: instead set the pixels of the output. Any higher pixel size and I find it's okay to use the native rectangle-filling code. Also, preset the background so you don't have to fill the rectangles for the dead cells (not live, because live cells disappear pretty quickly)
Don't exactly know how this can be done, but I remember some of my friends had to represent this game's grid with a Quadtree for a assignment. I'm guess it's real good for optimizing the space of the grid since you basically only represent the occupied cells. I don't know about execution speed though.
It's a two dimensional automaton, so you can probably look up optimization techniques. Your notion seems to be about compressing the number of cells you need to check at each step. Since you only ever need to check cells that are occupied or adjacent to an occupied cell, perhaps you could keep a buffer of all such cells, updating it at each step as you process each cell.
If your field is initially empty, this will be much faster. You probably can find some balance point at which maintaining the buffer is more costly than processing all the cells.
There are table-driven solutions for this that resolve multiple cells in each table lookup. A google query should give you some examples.
I implemented this in C#:
All cells have a location, a neighbor count, a state, and access to the rule.
Put all the live cells in array B in array A.
Have all the cells in array A add 1 to the neighbor count of their
neighbors.
Have all the cells in array A put themselves and their neighbors in array B.
All the cells in Array B Update according to the rule and their state.
All the cells in Array B set their neighbors to 0.
Pros:
Ignores cells that don't need to be updated
Cons:
4 arrays: a 2d array for the grid, an array for the live cells, and an array
for the active cells.
Can't process rule B0.
Processes cells one by one.
Cells aren't just booleans
Possible improvements:
Cells also have an "Updated" value, they are updated only if they haven't
updated in the current tick, removing the need of array B as mentioned above
Instead of array B being the ones with live neighbors, array B could be the
cells without, and those check for rule B0.