TC7rc5 - Multi-Rename Tool: Counter with letters

[StatusQuo]

The counter in MRT acts strange when using it with letters:

• mark some files and open Multi-Rename Tool
• enter "[Ca]" as the Rename mask: file name
  You will see the following order:
  
  a b c ... x y z ba bb bc ...

After "z" I would expect "aa ab ac".

• alternatively enter "[Cx]" as the Rename mask: file name
  You will see the following order:
  
  x y z a b c ... u v w bx by bz ba ...

After "z" I would expect "aa ab ac".

• alternatively enter "[CX]" as the Rename mask: file name
  You will see the following order:
  
  X Y Z A B C D E F a b c ... o p q BX BY BZ BA ... BF ba bb bc ... bq CX CY CZ CA ... CF ca cb cc ...

Hm, well... ::

[ghisler(Author)]

Actually this isn't a bug, it's by design. 'a' is treated like 0: Leading '0's and 'a's are left out. If you want leading 'a's, you need to define the number of 'digits' you want to see.

[StatusQuo]

OK, this explains the first counting order.

But what about the other two:

• [Cx] => x y z a b c ... u v w bx by bz ba ...
  Starting with "x": "z" is followed by "a".."w" and then "bx"
  This seems to me like the order 7 8 9 0 1 2 3 4 5 6 10 11 12 ...

• [CX] => X Y Z A B C D E F a b c ... o p q BX BY BZ BA ... BF ba bb bc ... bq CX CY CZ CA ... CF ca cb cc ...
  Starting with "X", running over "A" to "F", followed by "a".."q" - with alternating big and small letters...

How can I understand these?

Still ::

[Edit] P.S.: I found your answer, that currently only starting with a is supported in
http://ghisler.ch/board/viewtopic.php?p=123820#123820 [/Edit]

[ghisler(Author)]

But what about the other two:

This is indeed a bug - starting the letter counter at anything else than 'a' is currently not supported, because the overflow isn't taken into account. This has already been changed for the final release, and the private beta testers have already confirmed that it works now.

[white]

The counter in MRT acts strange when using it with letters:

• mark some files and open Multi-Rename Tool
• enter "[Ca]" as the Rename mask: file name
  You will see the following order:
  
  a b c ... x y z ba bb bc ...

After "z" I would expect "aa ab ac".

Actually this isn't a bug, it's by design. 'a' is treated like 0: Leading '0's and 'a's are left out. If you want leading 'a's, you need to define the number of 'digits' you want to see.

There is a bug in the current implementation of the counter.
Suppose you start the counter at 'aa' with "digits" set to 1. The counter should start at 'a' (one leading 'a' removed). Instead it starts at 'aa'. Compare with leading '0's.

I don't think you should treat 'a' like a 0 (zero). Letters are not numbers. Note that 1 = 01 = 001, whereas "B" does not equal "AB", "AAB" and "AAB".

With the current implementation of the counter, the value 'a' is considered to be equal to the value 'aa' and the value 'aaa'. Why is this any different from 'b', 'bb' and 'bbb'?

I think a counter should be like this:
A counter should produce a sequence of consecutive unique values.
Example:

Code: Select all

A
B
C
.
.
X
Y
Z
AA
AB
AC
.
.
ZX
ZY
ZZ
AAA
AAB
AAC

I think this is what most users expect.

Now, for numbers:

Code: Select all

0
1
2
3
4
5
6
7
8
9
(00)
(01)
(02)
(03)
(04)
(05)
(06)
(07)
(08)
(09)
10
11
12
13

For a numerical counter the values between brackets are not unique and have to be left out.


About the leading '0's and 'a's.

Adding leading characters to a counter should not change any of the consecutive values.
Adding leading zero's for a numerical counter does not change any of the consecutive values. Adding leading 'a's does change the values. Starting the counter at 3 is the same as starting the counter at 03, whereas starting the counter at 'a' is NOT the same as starting the counter at 'aa'. The value 'a' is the first value in the sequence and the value 'aa' is the 27th value of the sequence. If you would use blanks (spaces) as leading characters, it would not change the values of the sequence.

I am not totally against adding leading 'a's when "digits" greater than 1 is entered. However this will change the starting point in the sequence, so do not expect the sequence to be the same as the sequence without the leading 'a's. That would be false reasoning.

[Yuta]

I second White

[StatusQuo]

Starting the counter at 3 is the same as starting the counter at 03, whereas starting the counter at 'a' is NOT the same as starting the counter at 'aa'. The value 'a' is the first value in the sequence and the value 'aa' is the 27th value of the sequence.

No, now the 27th value is 'ba', not 'aa'.
This value is not changed if the counter starts at 'aa' instead of 'a'.

If started with 'aaa' (and more letters) instead, more leading a's are added.
Indeed this is different from a counter with numbers, and should IMHO be controlled by the field "digits", while leading a's (zeros) should be ignored in the "start at" field.

If you would use blanks (spaces) as leading characters, it would not change the values of the sequence.

But these should not be added to the files in the list, because that would lead to problems where spaces in names are unwanted.
I.e. in (some) mail programs you can write the path to a file, which is only treated correctly if no spaces are included.

[white]

Starting the counter at 3 is the same as starting the counter at 03, whereas starting the counter at 'a' is NOT the same as starting the counter at 'aa'. The value 'a' is the first value in the sequence and the value 'aa' is the 27th value of the sequence.

No, now the 27th value is 'ba', not 'aa'.
This value is not changed if the counter starts at 'aa' instead of 'a'.

It should be obvious that I know exactly how the current implementation works.
First I mentioned a bug. Then I explained 'a's can not be treated as 0 (zero). After that I showed what a counter should be like (a counter should produce a sequence of consecutive unique values) and discussed padding of this counter. So I was not talking about the current implementation of the counter.

This is the right order when designing a counter (first define the counter, then define padding). Designing a padded counter first and then to remove the padding characters to leave a counter which produces a sequence of nonconsecutive values, is wrong.

Of course if you considered from the beginning, the string "aaaaa" to be equal to "a" and the string "aaaab" to be equal to "b", whereas "bbbbb" is different from "b" and "baaaa" is different from "b", then it all makes sense. Please anybody raise your hand if he thinks that is logical in the first place.

If you would use blanks (spaces) as leading characters, it would not change the values of the sequence.

But these should not be added to the files in the list, because that would lead to problems where spaces in names are unwanted.
I.e. in (some) mail programs you can write the path to a file, which is only treated correctly if no spaces are included.

1) In that case you could start at a value later in the sequence so you would not need padding. For example, starting at "aaa" is good for up to 17576 files without needing padding.
2) As I said before: I am not against using 'a's for padding as long as this only changes the starting point in the sequence and does not define the sequence without padding.
3) Using blanks (spaces) for padding was just an example. Any nonalphabetical character will do. Perhaps the underscore character (_) is a good choice. It could of course also be configurable.

[ghisler(Author)]

There is a bug in the current implementation of the counter.
Suppose you start the counter at 'aa' with "digits" set to 1. The counter should start at 'a' (one leading 'a' removed). Instead it starts at 'aa'. Compare with leading '0's.

Actually this is by design too: For the text counter, you can define the width by writing multiple 'a's. In TC7 final, you will even be able to start e.g. at "abc" instead of "aaa".

[StatusQuo]

Of course if you considered from the beginning, the string "aaaaa" to be equal to "a" and the string "aaaab" to be equal to "b", whereas "bbbbb" is different from "b" and "baaaa" is different from "b", then it all makes sense. Please anybody raise your hand if he thinks that is logical in the first place.

I (now) think it is, if you consider this:

'a' is treated like 0:

[StatusQuo]

Fixed in TC7 final.

As a bonus one can set upper/lower case for each column separately: Starting value
- aAz is followed by aBa,
- aaZ is followed by abA.