Related
I'm trying to calculate the sum of best segments in a run. For example, each Km gives a list as such:
5:40 6:00 5:45 5:55 6:21 6 :30
I'm trying to gather the best segments of 2km/3km/4km etc and would like a simple code to do it. At the moment, I'm using the formula
=Min(If(B1=0,9:9:9,sum(A1:B1),If(C1=0,9:9:9,sum(B1:C1))
but this goes all the way to 50km, meaning a very long formulae that I then have to repeat slightly differently at 3km, then 4km, then 5km etc. Surely there must me a way of
generating an array of summed columns of every n column, then iterating over that to find the min while ignoring values of 0?
I can do it manually for now, but what if I want to go over 50km? I might want to incorporate bike rides/car drives in the future just for some data analysis so I figured it best finding an ideal formulae now.
It's frustrating as I could code it and I want to avoid VBA ideally and stick to formulae in Excel.
Here is a draft of the case where there aren't any zeroes just for groups of 2Km. I decided the simplest approach initially was to add a couple of helper rows containing the running total of times (and for later use counts) and use a formula like this to subtract them in pairs:
=MIN(INDEX(A2:J2,SEQUENCE(1,9,2))-IF(SEQUENCE(1,9,0)=0,0,INDEX(A2:J2,SEQUENCE(1,9,0))))
but if you have access to recent additions to Excel 365 like Scan you can do it without helper rows.
Here is a more realistic scenario with a couple of zeroes thrown in
=LET(runningSum,Y$4:AP$4,runningCount,Y$5:AP$5,cols,COLUMNS(runningSum),leg,X7,
seqEnd,SEQUENCE(1,cols-leg+1,leg),seqStart,SEQUENCE(1,cols-leg+1,0),
times,INDEX(runningSum,seqEnd)-IF(seqStart=0,0,INDEX(runningSum,seqStart)),
counts,INDEX(runningCount,seqEnd)-IF(seqStart=0,0,INDEX(runningCount,seqStart)),
MIN(IF(counts=leg,times)))
Note that there are no runs of more than seven consecutive legs that don't contain a zero so 8, 9, 10 etc. just work out to 0.
As mentioned you could dispense with the helper rows by using Scan, but not everyone has access to this so I will add it separately:
=LET(data,Y$3:AP$3,runningSum,SCAN(0,data,LAMBDA(a,b,a+b)),
runningCount,SCAN(0,data,LAMBDA(a,b,a+(b>0))),leg,X7,cols,COLUMNS(data),
seqEnd,SEQUENCE(1,cols-leg+1,leg),seqStart,SEQUENCE(1,cols-leg+1,0),
times,INDEX(runningSum,seqEnd)-IF(seqStart=0,0,INDEX(runningSum,seqStart)),
counts,INDEX(runningCount,seqEnd)-IF(seqStart=0,0,INDEX(runningCount,seqStart)),
MIN(IF(counts=leg,times)))
Tom that worked! I learnt a few things on the way too and using the indexing method alongside sequence and columns is something I had not thought of. I'd never heard of the LET command before and I can already see that this is going to really help with some of the bigger calculations in the future.
Thank you so much, I'd like to show you how it now looks. Row 3087 is my old formula, row 3088 is a copy of the same data using the new formula, as you can see I've gotten exactly the same results so it's clear that it works perfectly and it is can be easily duplicated.
Inlet -> front -> middle -> rear -> outlet
Those five properties have a value anything between 4 - 40. Now i want to calculate a specific match for each of those values that is either a full 10 or a 5 when a single property is summed from each pipe piece. There might be hundreds of different pipe pieces all with different properties.
So if i have all 5 pieces and when summed, their properties go like 54,51,23,71,37. That is not good and not what im looking.
Instead 55,50,25,70,40. That would be perfect.
My trouble is there are so many of the pieces that it would be insane to do the miss'matching manually, and new ones come up frequently.
I have manually inserted about 100 of these already into SQLite, but should be easy to convert into any excel or other database formats, so answer can be related to anything like mysql or googlesheets.
I need the calculation that takes every piece in account and results either in "no match" or tells me the id of each piece that is required for a match and if multiple matches are available, it separates them.
Edit: Even just the math needed to do this kind of calculation would be a lot of help here, not much of a math guy myself. I guess there should be a reference piece i need to use and then that gets checked against every possible scenario.
If the value you want to verify is in A1, use: =ROUND(A1/5,0)*5
If the pipes may not be shorter than the given values, use =CEILING(A1,5)
I'm trying to set up a formula in Google Sheets that does this...
=IF(IFERROR(INDEX(Matches!$L$2:$L,MATCH($A2&(B$1-14),Matches!$H$2:$H&Matches!$M$2:$M,0)))=1,
IFERROR(OFFSET($A$1,INDEX(Matches!$I$2:$I,MATCH($A2&(B$1-14),Matches!$H$2:$H&Matches!$M$2:$M,0)),COLUMN()-1)-(1/(2*($A2)^2))),
$A2)
That is to say, IF(match was won, take the current period's rank of your defeated opponent and do math to it, else show last period's rank).
But I want to set it into an ARRAYFORMULA so that it will expand automatically. What I have is this (and it doesn't work):
=ARRAYFORMULA(IF(IFERROR(VLOOKUP($A$2:$A&($B$1:$1-14),{Matches!$H$2:$H&Matches!$M$2:$M,Matches!$L$2:$L},2,0))=1,
OFFSET($A$1,VLOOKUP($A$2:$A&($B$1:$1-14),{Matches!$H$2:$H&Matches!$M$2:$M,Matches!$I$2:$I},2,0),SEQUENCE(1,COUNTA($B$1:$1),2,1))-(1/(2*($A$2:$A)^2)),
$A$2:$A))
What it should look like is this:
https://i.stack.imgur.com/Ui3nE.png
How it actually comes out is:
https://i.stack.imgur.com/tQOl7.png
All of those errors are the same message, which is that VLOOKUP couldn't find 143997, which is just the first value pair. I've tried using VLOOKUP/MATCH, but it produces a circular reference error.
Is this possible? I'm willing to believe it's not, but I thought I should ask. Thanks for any help you can offer.
You can't use that OFFSET formula within ARRAYFORMULA. When the VLOOKUP throws an error the OFFSET is not able to handle it. That's why it won't work. You should apply your math on the output of the VLOOKUP.
I am not quite used to writing very long SPs. And I found it become quickly hard to manage when working with those wide tables. Even a simple UPSERT will take very long line or tens of lines of code (I found the col/line style easier to read for me, but working with those very wide tables are really a pain for me). Gradualy I found myself start to use BEGIN/END to wrap those UPSERTs and others basic operations on the same table etc to group them into logical sections. So that in IDE they can be easily fold and unfold, to check and review with comments. Note: I am not wrting them for any control blocks. Just simple BEGIN/END to wrap them into a foldable section.
Will adding a few extra BEGIN/END to group and fold/unfold lenthy code lead to any side effect? Currently I am not seeing any yet...
If so what they could they be ? Are there any better way to orgnize those code in SP ?
Oh by folding I mean
CREATE PROCEDURE/MULT_STATEMENT_FUNCTION
...
BEGIN
-- UPSERT QC records
BEGIN
UPDATE QC_SECT1 <-- fold[]
SET COL1=...
COL2=
.....
IF ##ROWCOUNT.... <--fold[ click 1]
INSERT INTO ... <-Fold[click 2]
(
COL1
....
VALUES <-Fold[click 3]
(
...
END
-- calculate distribution
BEGIN
DECLARE #GRP1_.....
DECLARE #GRP2_....
WITH .....
....
) AS PRE_CAL1 <-- fold[click 1]
) AS PRE_CAL2 <-- fold[click 2]
) AS ... <-- fold[click 3]
END
END
I found it very inconvienint to inspect long scripts, Gradually I find myself start to use BEGIN/END. In VSCode it take so many clicks to fold a single CTE statement. BEGIN/END made it a lot easier. But I really want to make sure, I am doing sth wrong.
PS: The grouping columns by line ideas are very valid, I fully agree.
Regarding the col/line style. It's not that I am really fond of it. But I guess under my current situation many people probably will prefer it too. The wide tables in vendor db have long prefix to , I'd say ,group the columns. list them vertically helps to align them, so that they can be distingished easier... I guess mine currently is a special case.
Thanks.
You can do this. It's a good idea to structure code like that because it's integrated with the language and the IDE in a way that comments are not. In C languages I sometimes use {} blocks for that in case it is necessary to have larger methods.
I found the col/line style easier to read for me
If that's easier for you then it makes sense. But maybe it also makes sense to train your eyes to accept a style where many columns are in one line. This saves a tremendous amount of vertical space. More fits on the same screen and clarity increases.
No, absolutely not. There is no harm in wrapping blocks of code in BEGIN/END blocks. I have been doing it for 10+ years without consequence. The optimizer basically ignores it unless there is a reason to evaluate the BEGIN/END logic (e.g. for a loop or other "WHILE" condition.)
Using BEGIN/END code blocks in SSMS makes it possible to quickly collapse/expand large blocks of code. Below is some code I was just working on to collect some routine metadata. It's 110 lines of code yet easily readable.
A user has to complete ten steps to achieve a desired result. The ten steps can be completed in any order.
If there is a bug, the bug is dependent only on the steps that have been taken, not the order in which they were taken (i.e., the bug is path independent).
For example: If the user performs three steps in the order 10, 1, 2 and produces a bug the exact same bug will be produced if the user performs the same three steps in the order 1, 2, 10.
What is the maximum number of unique bugs this program can have?
You mean what is the number of distinct sets pickable from 10 elements? That's a powerset: 2**10.
Much later: some knowledgeable others have suggested that having no bugs should not be counted as a bug. Accordingly, I revise my count: 2**10 - 1.
hughdbrown's answer is correct, but there is another possible interpretation of the question. Suppose that a sequence of operations can never produce more than one bug (i.e. that it should just be counted as one bug). For example, if the operations (3,6,2) is a bug, then you shouldn't be allowed to count (3,6,2,5) as another bug. In that case, rather than finding the maximum possible number of subsets of {1,2,...,10}, you want to find the maximum number of possible subsets so that no one contains another. The answer to this version of the question is "10 choose 5"=252.
Edit: by the way, the result that says this is maximal is called Sperner's Theorem.
It depends entirely how many ways there are of doing each step. If you have a process that involves only one step, but there are multiple ways of doing that step, every step could have an associated bug.
There's also the misuse of functions, which you cant prevent against, which could be considered a bug. ie:
If a user was to think that
rm -rf /
was short for
remove media --really fast /
ie: eject all devices1
I would guess that would be a potential bug. Its user error really, but its still a singular thing that can occur that produces results other than that were wanted.
You could argue the above is a bit over the top, but ultimately, there is no limitation on the ways users can do things wrong.
When users are there, assume, anything that can go wrong, will.
The only problem with the above reasoning, is you have to prematurely delete powerful things so users don't hurt themselves, which leads to less effective tools for those who know how to use them. Like corks on forks sort of rationale.
The only way to solve this concern effectively is give newbs blunt objects to learn with, and then give them an option which takes away all the foam padding once they learn the ropes, so experienced users don't have to keep working with blunt tools, and don't have to deblunten every tool themself.
( If there are infinite numbers of possibly ways to do 1 step, I don't even want to begin to think of the numbers of ways to do 10 steps wrong )
1: If you don't know, this will erase lots of your hard drive and cause much pain. Don't do it.
One, a designer fault? :)