Master equation etc. can clash with user-defined states/reactants

[jarmarshall]

For example, \phi is reserved within showMasterEquation but may also be used as a label in a user-defined model, causing a collision (see MuMoTlatexTest)

Possible solution, use variable names that cannot be input by user, e.g. \phi'?

[tbose1]

Yes, I think we should reserve some symbols, for example \Phi, and also V which is used as expansion parameter in vKE

[jarmarshall]

I think it is a bit unfriendly to reserve symbols - the user should be able to type in a model and have it work... can we think of some suitable symbols the user cannot use? \overline and variants might be suitable, if we allow ourselves some abuse of notation

[jarmarshall]

What shall we do about this? Reserve these when parsing the model and fail is used? @tbose1 what's the exhaustive list of reserved variable names?

[tbose1]

I have tested using \Phi as a variable, which is also used to denote concentrations. The program doesn't break. I think there could be very rare cases when this leads to confusion as the state variables will be indices of \Phi when \Phi describes a concentrations. Only when rates will be named \Phi_{stateVaribleName} then this will be confusing. However, I think the probability that this happens is very low.

So we could reserve \Phi (capital phi not small phi \phi). We also need to prevent users from using the following Greek letters which is due to checking strings for the presence of Greek letters to ensure proper latex rendering (see commit 806b2d64ad9614601ce9fd232486f8615e7d5b83):

eta: because eta is a substring of theta, zeta and beta

varrho: because rho is a substring of varrho

vartheta, varepsilon and varphi: same reasons as for varrho (theta, epsilon, phi also in the alphabet)

nu: this just does not work (I don't know why)

However, I don't think we need to reserve V, we could use VOL, V' or \overline(V) as suggested by @jarmarshall .

[tbose1]

We should probably implement a simple check if one of the not-allowed variables is used when the model is parsed and then print out a warning message with the request to redefine the model with the symbols allowed.

[tbose1]

In commit 517ea08fa63147c2ec8a44e4fc3a5336de2ed748 the display of the system size volume has been changed from V to \overline{V}.

Therefore, the list of variables which should not be used in the model definition reads: [\eta, \varrho, \vartheta, \varepsilon, \varphi, \nu] , and we might add \Phi, in which case the user could still use \phi

[jarmarshall]

Thanks @tbose1 - I'm happy to reserve some variables when the model is parsed. But I don't understand the substring problem - can you elaborate? I feel there must be a solution to this...

[tbose1]

When there were display problems, when Greek letters could not be displayed this was because they were parsed as alpha and not as \alpha, for example, and could not be LaTeX-rendered. The new functions I've written check the final string, which can be a very long sequence of characters, and look for greek letters without the backslash and adds this in front of the letter. If we would find eta in a string 'abc_theta' then this would give a new string 'abc_th\eta'. So, it is not possible to identify the correct letter 'theta' in the string and moreover we generate a variable which might not be defined or we recognise it in the wrong place.

[jarmarshall]

OK - we just need to do the search better - this is basic string processing - for example we don't add the backslash if the pattern is preceded by an alphabetical character. Can you direct me to which function your code is in?

[tbose1]

At the end of MuMoT.py

[tbose1]

For prepending '//': _greekReplace(s, sub, repl) _greekPrependif

For solving issues with two indices (adding {}): _doubleUnderscorify(s)

[jarmarshall]

@tbose - can you add a list of reserved variable names, similar to GREEK_LETT_LIST_1?

[tbose1]

Added GREEK_LETT_RESERVED_LIST in commit 0bac0ee87175151b6314712c6cbc32cb64ce9a5a. These are exactly the Greek letters which are not in GREEK_LETT_LIST_1.

[tbose1]

Capital Phi is now removed from GREEK_LETT_LIST_1 (see commit 9c9464a3e551854b82d0b10ac33d2ef8dd3bd680).

[jarmarshall]

@tbose1 I attempted to improve the way _greekReplace() works - I added a simple check to see if the character immediately before the occurrence of a substring is alphabetic, in which case it should not be a candidate for replacement. Can you check if this seems to work and revise the list of excluded letters accordingly? I don't fully understand what the function does, e.g. there is a hard-coded reference to eta - is this still necessary? N.B. I don't think it can be guaranteed that the character before the first occurrence of a substring exists, i.e. if the substring is at the very beginning of the string? Yet the code assumes this character can be examined - need to add a check for this to avoid problems?

[tbose1]

The reference to "eta" is necessary as I use this letter for the noise correlations. I thought about your approach before, too, but I think that this could have several problems, the one you mentioned (that there is not always a character before the letter) but maybe also the following example: let's assume we have a product of "r" and "phi" in a formula, which in a substring could be represented as "rphi". In your method you would not replace "phi" although it should be replaced. I don't know if we can safely exclude that happening.

[jarmarshall]

I don't think rphiwould be a valid expression (it wouldn't in Mathematica, for example) as it is is indistinguishable from a variable name. And already a check of the preceding character is made, so that will cause a problem either way for substrings at the start of strings

[tbose1]

My thinking was that we construct very long strings when displaying mathematical formulas and I thought that letting our string-checking functions act on the full string would be the best way, and possibly unfortunate combinations of characters might occur in the final output string. Reserving some of the Greek letters would completely avoid this problem. However, I don't know for sure if this will happen at all and if you think it won't we can certainly use the modification you made.

[jarmarshall]

I think it should be safe - any product operators will almost certainly be represented explicitly in such constructed strings? I'm assuming... so I think it should be reasonably safe, and should be possible to construct a quick test case to check?

[tbose1]

Update: I've put 'Phi' back into GREEK_LETT_LIST_1 (it is still in GREEK_LETT_RESERVED_LIST) as it is needed there to correctly format it as the symbol used for concentrations , see commit ff38fdad9cb7672e6b67916d965b6b8b55d6f968

[tbose1]

As a quick test, I've printed out various strings before applying _greekPrependify(string) and _doubleUnderscorify(string) and it seems that there is always an empty space between symbols. So, checking for alphabetic characters could work, though my feeling is still that this is more error-prone than to reserve some symbols.

[jarmarshall]

I think it will be fine - I just pushed a quick fix that will avoid running off the beginning of the string. Will look at excluding reserved letters now during parsing...