Redundant edges removed, but no edge table column created - cytoscape

When removing redundant edges from a network, selecting "Create an edge table column with number of duplicated edges", the duplicate edges are removed, but no edge table column is created. This is a new behavior in 3.8.0. Possibly related is the automatic sequential numbering of edges when importing a network from GML with duplicate edges. Any ideas what is going on? Is there a workaround?

Short (and perhaps not very helpful) answer is that it appears to be a bug. Can you do a Help->Report a Bug and report it?
Thanks!
-- scooter

Related

Erase / Filter rows with info from the ones in blank

I have this data in a Google Sheet, basically is a dynamic table that will have more information or could change in a future with more or less rows, in the same image at the right you will see what I need, I was thinking about use BLANK but is giving me some errors, also I tried with transposeFilter but same problem. Some help or recommendations please! (The only information not dynamic is the blue rows)
try for horizontal erase:
=FILTER(A:D; TRIM(FLATTEN(QUERY(TRANSPOSE(A:D);;9^9)))<>"")
or vertical erase:
=FILTER(A:D; TRIM(QUERY(A:D;;9^9))<>"")

Google Sheets Formula Sometimes does not work with Merged Cells

So I have created an invoice spreadsheet in Google Sheets and have used merged cells extensively in order to create a cleaner look for the invoice.
Here is the problem that I am having: sometimes, my simple subtraction formula does not give me a correct result. The formula is supposed to subtract the Unsold balance (cell V27) from the Beginning Balance (cell R27).
Again, there is nothing wrong with the formula itself, as it works correctly 99% of the time, but every now and then, it just gives me an answer matching the Beginning Balance.
Also here is a link to a copy of the spreadsheet for anyone willing to take a look. https://docs.google.com/spreadsheets/d/1bf_QE-u36mo4AKyqg7Dk11gwoR0p5g0qveIazR83Xbk/edit?usp=sharing
Has anyone else ever had this situation happen to them? What could possibly be causing it, and more importantly, how can it be fixed to be more reliable?
Those of us who work professionally developing Sheets solutions have a few basic rules that we follow and encourage others not to break. Among them is "Never merge cells anywhere that calculations or comparisons will be (or ever might be) performed or assessed."
While what you're seeing might seem to be a glitch, I wouldn't call it that. Merged cells don't really get rid of the cells you don't see. For instance, your cell R27 doesn't "get rid of" cells S27, T27 and U27. It just holds them in memory, presumably empty. But remember that, inside Sheets' "memory," it doesn't "see" a grid. It's just 1's and 0's. When a grid is new and no cells are merged, Sheets "finds" each cell (using the best analogy I can give) counting over and down by 1's and 0's that are very small and tightly packed. Hold that thought...
Also note that many people are surprised when they have multiple complex calculations going on and get a returned answer that is off from what they expect in a cell further down the calculation chain. This is because Sheets uses floating decimal points. For instance, "one divided by three" is about 0.333. But in reality, that extends very far out: 0.33333333333333333333. But that can't go on forever or Sheets wouldn't be able to run. So at some point it gets truncated. Eventually, those extra decimal-extras will start to add up and bump numbers up (or down) by small degrees. All of this is handled by the same 1's and 0's that run everything else.
Back to merged cells. Finding and accurately "reading" merged cells gets less accurate the more of them you merge, because the process is relative to other cell locations in memory. After a while, the "floating decimal point" nature of Sheets starts to lose track, especially (I've observed) if you've got merged cells using the same sort of relative formula reference that you're using (e.g., a lot of your stacked merged cells are referencing yet another merged cell: BB2. So (again by analogy), Sheets is trying to "guess where it is by using clues." Perhaps it found something correctly in merged cells Z-AA-AB-AC23 that referenced merged cells BB2-BB3-BC2-BC3; but that time, you asked it to add merged cells R-S-T-U23 and V-W-X-Y23 and subtract merged cells V-W-X-Y24 ... where in the following set of merged cells, Z-AA-AB-AC24, you still asked for the BB2-BB3-BC2-BC3 reference but not the V-W-X-Y24 subtraction. And so on...
To add to this, you've got row heights changed all over the place. Some are set to specific heights, while others are fit to data.
You get the picture.
If Sheets is trying to find things by moving over and down from cell A1, but there is no regularity, sometimes, it just throws it's hands up and says, "Where the h-double-hockey-sticks am I anymore?" When you then reload the sheet or delete and replace the formula, it starts out at A1 again and plays Chutes and Ladders on the broken board and might shift one "floating" teeny-weeny 1 or 0 a different way from last time... and find what you wanted it to find again.
You also-also wind up with a sheet that is 56 columns across, when you probably only needed it to be 12 or 15. Likewise, you've extended the number of rows beyond what it needed to be. So you're slowing down your processing by a lot.
THE SHORT VERSION:
As nice as merged cells might look, they are a computing nightmare. I've been working with spreadsheets since they were invented, and I've literally never had a need for merged cells (though I've occasionally used them in areas that are purely aesthetic).
THE SOLUTIONS:
1.) Remake the sheet without merged cells.
-or-
2.) Try encompassing all of the merged-but-hidden cells in your calculations. This at least gives Sheets a wider net to cast. For instance, in your example above, you reference this formula:
=IF($BB$2<>"Rental","",R27-V27)
Try (where possible) to include the whole range you merged:
=IF($BB$2<>"Rental", "", SUM(R27:U27) - SUM(V27:Y27) )
Technically, you could also include all cells in the BB2-BB3-BC2-BC3 merge:
=IF(AND($BB$2<>"Rental", $BB$3<>"Rental", $BC$2<>"Rental", $BC$3<>"Rental"), "", SUM(R27:U27) - SUM(V27:Y27) )
However, try the shorter route with just the SUMmed merged ranges and see if it holds up. If so, stick with that. If not, go with referencing every cell in ranges you merged.
You've clearly put a lot of work into setting up this sheet. So I'm sure this isn't the easy answer you were hoping to hear. But I hope it does give you some direction for next steps.
For me, the simplest solution is to lock-reference the uppermost cell of the merged cells.
Instead of referencing in the top formula as B2, reference as $B$2. This way, your formulas in other cells will reference the same value as required.
USE LOCK-REFERENCING:
$B$2

how to select all edges between two selected nodes in cytoscape using the GUI

Does anyone know how to select all edges between two selected nodes in cytoscape using the GUI?
This would be easy to do manually if it were a small network but in my case there are over 10k nodes.
Ideally I want to select all edges that are between a list of 70 nodes.
Thanks.
Well, much to my surprise, the answer is "no", I don't know of an easy way to select edges connecting two nodes. I have a "hacky" way to do it that would work, though:
Select all of the nodes you want
Do File->New Network->From Selected Nodes, All Edges. This will give you a new network with only the selected nodes and the edges that connect them. Now, change the "shared interaction" column for all of those edges to something unique (e.g. Select). This column is shared between the subnetwork you created and the original network.
Now, back in the original network, use can use the Filter panel to create a column filter looking for all edges with a shared interaction of "Select". They will then be selected.
Probably much more complex than you might want, but it will do the job. I would also recommend adding a feature request (Help->Report a Bug) for selecting edges connecting selected nodes.

Not calculating correct number or refreshing

I am using Google Sheets and have just noticed a very worrying issue.
I have a situation where I have a number (for example 4.99) in the left column and the right column through a series of formulae may come out as 30% or so. I changed the number in the left to 5 and the number is the right column jumped to 50% or so (highly unexpected to see such a large jump for such a small increase, so I decided to investigate). When I typed 4.99 back into the left box, the result in the right was just slightly lower than the 50% or so.
I then checked several other numbers in the left column. It turns out that this was the same for all of them. I.e. the number in the right column was not calculating properly until I changed the number in the left column and pressed enter. How is this possible? I have never had this problem with Excel and I don't know what to do other than to migrate back to Excel as I am now doubting the reliability of all the spreadsheets I have on Google Sheets.
Has anybody else come across this problem?
I managed to figure it out moments after posting this.
In the column for some reason some of the cells were considered numbers and some text. I performed an if statement (<10), which came out FALSE for all cells considered text.
Quite dangerous - surely the cell on the right should show an error and not assume FALSE?

LaTeX - wrong figure and table numbering in * environment

I have a question related to * environment in LaTeX used for spanning figure/table across two columns. It is well known that in this such figure/table is placed on the top of the page. The problem is that the Fig/Tab numbering is not taken into account so for example the two column figure has caption "Fig.4..." and right below it is one column figure with caption "Fig.3" ... which is the wrong order and in this case the figs and tabs should be automatically renumbered right?problem illutration
I am not sure that I understood the problem, but I would try to put the code for the figure spanning two columns (fig 4 in your image) before the code for the figure that it is called fig 3 in your image. That should fix it.

Resources