I'm trying to create a CSV file of one of my customer's serial numbers. We print them as barcodes for them to use, and normally I'd use our barcode software to generate the numbers. However, we're using a different method of printing, and it requires a CSV/Excel file of all the numbers to be printed. The barcode is as follows:
MC100VGVA.
The last digit is a check digit created from the rest of the string.
Now, my problem comes with the "VGVA" bit. Column A is the prefix (MC), Column B is the number (100), Column C is the incrementing 4 characters (VGVA), and Column D is the check digit.
I need for the VGVA bit to increment alphanumerically. So, when it gets to VGVZ, I need it to go to VGW0. Then when it gets to VGZZ, it needs to go to VH00 and so on until they reach ZZZZ, in which the next digit would increase Column B to 101, and Column C would become 0000.
I've attempted to use the CHAR formula, as well as CONCATENATE, and MID. But, because I'm not well versed in these formulas, my attempts at editing them to work with 4 digits have been failing me.
I'm not opposed to using VBA if needed, but it's not something I've ever worked with, so you'll have to forgive any ignorance on my part.
Please let me know if you need more information. Thanks!
It looks like you are trying to create a new base, the one based on 27 digits (0 and all letter from 'A' to 'Z'). So I'd advise you to create a conversion from and to 27-digit system.
Let me first explain you what I mean in octal numbering (8 digits, from 0 to 7): in that system we start from (just some examples):
a=0011
b=1237
c=1277
The meaning of those numbers is:
a equals 0*8^3 + 0*8^2 + 1*8^1 + 1*8^0 = 9, so:
a+1 equals 10, and converting this to octal numbering yields:
0012
b equals 1*8^3+2*8^2+3*8^1+7*8^0 = 671, so:
b+1 equals 672, and converting this to octal numbering yields:
1240
c equals 1*8^3 + 2*8^2 + 7*8^1 + 7*8^0 = 703, so:
c+1 equals 704, and converting this to octal numbering yields:
1300
I propose to do exactly the same for your 27-digit system, with following example:
VGZZ equals 22*27^3 + 7*27^2 + 26*27^1 + 26 = 438857
VGZZ+1 equals 438858, and converting this to 27-digit numbering yields:
VH00
You can do this, using a VBA function you need to develop yourself. The converting from the string to the normal number is obvious, and in the other way around, you use =MOD(...,27^3) and other similar functions.
I believe I've found a non-VBA answer to this question, thanks to someone on another forum.
Here's what they suggested and it seems to be working perfectly:
B2
=B1+(C2="0000")
C2
=RIGHT(BASE(DECIMAL(C1,36)+1,36,4),4)
and maybe try this at D1
=MID("0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ-. $/+%",MOD(SUMPRODUCT(SEARCH(MID((A1&B1&C1),ROW($1:$99),1),
"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ-. $/+%") )-99,43)+1,1)
In trying to systematically enumerate the possibilities when rolling four identical but loaded four-sided dice, I came across some unusual excel behavior. Hoping someone can shed some light on what's going on under the hood.
The following table illustrates the possible rolls of a die:
1000 A
0100 B
0010 C
0001 D
each row is a possibility with a distinct probability. In excel, this information can be made to occupy a 4x4 cell area--that is, the letter labels above are merely for convenience.
In trying to display all possible combinations of four rolls of such a die-- where the fist combination might be A + A + A + A or 4000, the second might be B + A + A + A or 3100, and so on for each of the 4^4=256 possibilities--I decided that I wanted to systematically offset A by 0,1,2, or 3 rows for each of four rolls then sum the results. In other words, each possible group of 4 roles can be thought of as 4 copies of row A, each of which offset by some number of rows between 0 and 3, for example {0;0;0;0} or {1;0;0;0} in the first and second case enumerated directly above.
Oddly, though, I get the following. (all formulas are array formulas keyed in with shift+ctrl+enter).
=TRANSPOSE( SUM( OFFSET( A, 4x1ArrayOfRowOffsets, 0)))
displays the correct sum when entered into a 1x4 range. Likewise if =TRANSPOSE(...) is replaced by =INDEX(...,1,1). I take it because both functions natively support array arguments. However,
=SUM( OFFSET( A, 4x1ArrayOfRowOffsets, 0))
does not work--it seems that here the summation is conducted along the 4 rows returned by offset, each of which has value 1--it incorrectly displays only the value 1, even when evaluated in a multicell range as an array formula. Oddly,
=SUM( TRANSPOSE( OFFSET( A, 4x1ArrayOfRowOffsets, 0)))
does not work either--the transpose makes it so the summation is properly conducted along the columns returned by offset, but seems to throw out all but the first column.
Please note that, although the problem statement does not involve VBA, the lack of transparent array formula auditing in Excel proper (intermediate steps return #VALUE errors even when the final answer computes) likely means that, in order to investigate this problem, someone will have to write a bit of VBA that calls worksheet functions and manually outputs the intermediate calculations. This is why I posed a version of this question, here.
Interweaving INDEX calls anywhere but the outside/first function call does not fix the problem.
To try and see what is going on, I investigated further.
=INDEX( OFFSET( A, {w;x;y;z}, 0), 1, {1,2,3,4})
correctly displays the four rolls when entered into a 4x4 range. As before w, x, y, and z are integers between 0 and 3 indicating row offsets from "A" in the table, above. Furthermore,
=COLUMNS( OFFSET( A, {w;x;y;z}, 0))
returns the following when entered into a 5x5 range:
4 4 4 4 4
4 4 4 4 4
4 4 4 4 4
4 4 4 4 4
n/a n/a n/a n/a
All that is to say, calling SUM(OFFSET(---)) with array arguments seems to produce varied output depending on what is doing the calling--specifically, whether or not the caller is a function which natively accepts proper array arguments. Why is this? What is actually going on, here?
I encountered one weird application of the "FIND" function which I don't quite know how it work. Could someone enlighten me?
This formula results in "19"
=MEDIAN(FIND({1,2,3,4,5,6,7,8,9},"2 notch lower0123456789"))
This formula results in "23"
=MAX(FIND({1,2,3,4,5,6,7,8,9},"2 notch lower0123456789"))
This formula results in "1"
=MIN(FIND({1,2,3,4,5,6,7,8,9},"2 notch lower0123456789"))
This formula results in "15"
=FIND({1,2,3,4,5,6,7,8,9},"2 notch lower0123456789")
The results obviously tie with the number of characters. But how exactly does this syxtax of FIND work?
Thanks,
First, because of the matrix argument, FIND() runs in a loop, for the values 1, 2, ...9 (as specified inside the {}).
FIND returns then the position of the first match inside the string "2 notch lower0123456789", for each number (as a character), so the 1 is found at position 15, the 2 at position 1, the 3 at position 17, the 4 at position 18, etc, until the 9 is found at position 23.
The result of this matrix operation will be the list {15,1,17,18,19,20,21,22,23}.
Now apply the functions to that:
MEDIAN({15,1,17,18,19,20,21,22,23}) -> the middle value is 19!
MAX({15,1,17,18,19,20,21,22,23}) -> obviously 23
MIN({15,1,17,18,19,20,21,22,23}) -> obviously 1
{15,1,17,18,19,20,21,22,23} -> if you don't apply anything to it, a matrix gets reduced to the first element, so 15.
Definitely weird usage, I agree.
I'm looking to create a formula with 3 conditions. It is currently only working with 2 conditions. Here's what I'm looking for:
E9 has a number
If the number is 21+ then I want it to show Text 1
If the number is between 5 and 21, then I want it to show Text 2
If the number is below 5, then I want it to show Text 3
This is what I currently have:
=IF(E9>21,"Text 1",IF(E9<21,E9>5,"Text 2")
When I try and add the final condition, it gives me an error that I've entered too many arguments for this function. When the number is below 5 it shows False.
I would prefer a solution that does not use VLOOKUP.
I'm not understanding why it's saying this is not allowed, I have another IF function with 5 nested formulas that works just fine.
You can do it this way:
=IF(E9>21,"Text 1",IF(AND(E9>=5,E9<=21),"Test 2","Text 3"))
Note I assume you meant >= and <= here since your description skipped the values 5 and 21, but you can adjust these inequalities as needed.
Or you can do it this way:
=IF(E9>21,"Text 1",IF(E9<5,"Text 3","Text 2"))
Using INDEX and MATCH for binning. Easier to maintain if we have more bins.
=INDEX({"Text 1","Text 2","Text 3"},MATCH(A2,{0,5,21,100}))
=if([Logical Test 1],[Action 1],if([Logical Test 2],[Action 1],if([Logical Test 3],[Action 3],[Value if all logical tests return false])))
Replace the components in the square brackets as necessary.
You can simplify the 5 through 21 part:
=IF(E9>21,"Text1",IF(E9>4,"Text2","Text3"))
I'm reading Learn You A Haskell for Great Good. His examples [2,2..20] and [3, 6..20] work fine but I got three weird results:
Count by 17's from one to 171: [17, 1..171] yields the null list.
Count by 17's from seventeen to 1711111: [17, 17..171111] repeats the number 17 until I interrupt GHCi.
There is a weird difference between take 54 [171, 234..] and take 54 [171, 244..]:
ghci> take 54 [171, 234..]
[171,234,297,360,423,486,549,612,675,738,801,864,927,990,1053,1116,1179,1242,1305,1368,1431,1494,1557,1620,1683,1746,1809,1872,1935,1998,2061,2124,2187,2250,2313,2376,2439,2502,2565,2628,2691,2754,2817,2880,2943,3006,3069,3132,3195,3258,3321,3384,3447,3510]
ghci> take 54 [171, 244..]
[171,244,317,390,463,536,609,682,755,828,901,974,1047,1120,1193,1266,1339,1412,1485,1558,1631,1704,1777,1850,1923,1996,2069,2142,2215,2288,2361,2434,2507,2580,2653,2726,2799,2872,2945,3018,3091,3164,3237,3310,3383,3456,3529,3602,3675,3748,3821,3894,3967,4040]
Why?
You have the meaning of ranges slightly off. The Haskell range syntax is one of four things: [first..], [first,second..], [first..last], [first,second..last]. The examples from Learn You A Haskell are
ghci> [2,4..20]
[2,4,6,8,10,12,14,16,18,20]
ghci> [3,6..20]
[3,6,9,12,15,18]
Note that in the first case, the list counts by twos, and in the second case, the list counts by threes. That's because the difference between the first and second items is two and three, respectively. In your syntax, you're trying to write [first,step..last] to get the list [first,first+step,first+2*step,...,last]; however, the step size of a range like that is actually the difference between the first two numbers. Without a second element, the step size is always one; and without a final element, the list goes on forever (or until the maximum/minimum element of the type is reached).
Thus, let's look at your three examples:
[17,1..171] == []. Since you specify 17,1, Haskell sees that the first two elements of your list ought to be seventeen and one, so you must be counting by -16. In that case, Haskell wants to stop as soon as the elements are smaller than the last element---but they start that way, and so no elements are produced. To count up by one, you want [17,18..171] (the first two elements of your list are 17 and 18), or simply [17..171].
[17, 17..171111] == repeat 17. This one's fun. Since the first two elements of your list are both 17, Haskell determines that you must be counting up by zero—and it will happily keep counting up until the result exceeds 171111. Of course, when counting by zero, this will never happen, and so you get an infinite list of seventeens. To count up by seventeen, you want [17,34..171111], or [17,17+17..171111] if you think that's clearer.
take 54 [171,234..] vs. take 54 [171,244..]. I'm not sure what behavior you were expecting here, but what they're each doing is the same as above: the first returns a list of fifty-four integers, starting at 171 and counting by 234 - 171 = 63; the second returns a list of fifty-four integers, starting at 171 and counting by 244 - 171 = 73. Each list goes on infinitely far (or at least until maxBound, if the lists are of finite Ints and not arbitrarily-large Integers), and so you just request the first fifty-four elements.
For some of the more nitty-gritty details on what range syntax means (it's translated into functions in the Enum type class), including slightly surprising behavior on ranges of floating-point numbers, hammar has a good answer to another question.
Well, the semantics of those operations are a little bit different than you expect. The construct [a,b..c] is actually just syntactical sugar for enumFromThenTo a b c, which behaves a little bit like this:
Calculate d = b - a. The output of [a,b..c] is [a,a+d,a+d+d,a+d+d+d,...]. This is repeated, till a+n*d > c, if d and c - a have different signs (In this case, the list would be infinite, so there is no output instead), or till maxBound or minBound is reached, then the output ends. (Of course, this is implemented differently, since we are using arbitrary instances of Enum here).
So [1,3..10] becomes [1,3,5,7,9] and since 17 - 17 = 0, [17, 17..171111] yields [17,17+0,17+0+0...]. And by that slightly complicated rule, [17, 1..171] yields the empty list.
To your addition: [x,y..] is implemented using the function enumFromThen x y, that behaves just like enumFromThenTo, except that there is no boundary condition, so if your Enum is infinite, so will be the resulting list.
I, too, was a bit surprised by this behavior, so I wrote a range function that feels more natural to me (and maybe to you as well):
range step start end = takeWhile (<=end) $ iterate (+step) start
Citing your examples:
Count by 17's from one to 171
is done by range 17 1 171, producing [1,18,35,52,69,86,103,120,137,154,171]
Count by 17's from seventeen to 1711111
is done by range 17 17 1711111, producing [17,34,51,68,85, ...
I was also confused by this tutorial: The tutorial uses the word step, which isn't explained, and in my view isn't what I think of as a step. It then shows the example which can easily be misinterpreted. since [2,4..20] looks like it means with a step 2 starting at 4.
The clue is in the output though:
ghci> [2,4..20]
[2,4,6,8,10,12,14,16,18,20]
if you look carefully (which I didn't). It means start at 2, the next being 4, with implicit step thenceforth of (4 - 2), carry on to output numbers in steps of 2 up to at most 20.
"ghci>" [1,6..20]
[1,6,11,16]
Note 20 is not output as 16 + 5 is greater than 20