Parameter name α refers both to linear functional response and producer competition.

[iago-lito]

According to @ismael-lajaaiti, we should disambiguate by renaming the one in the linear functional response. What's a good alternate name then? Where in the package does the change need to be propagated?

[alaindanet]

Ouch, the \alpha matrix of producer competition could be renamed by \alpha_{ij} matrice if it is more convenient. It should be added to the doc that the matrix \alpha_{ij} for alli, j, including i = j(i.e. it includes intracompetition coefficients). But wait... The arguments ofProducerCompetition(), \alpha iiand\alpha ij` would become ambiguous with the complete competition matrix...

I have too think more about it!

[iago-lito]

I am not sure I understand what you wrote here. But if you are suggesting that α (functional response) and α (producers competition) be disambiguated by renaming them to α (functional response) and α_ij (producers competition) instead, then I think it's a bad idea because it would remain ambiguous and misleading for humans.

What about renaming the α (functional response) to β (functional response) and α (producers competition) would remain unchanged? Would this clash with another name? Is it future-proof?

[andbeck]

The issue is that in ecological theory both are α. Can we keep the competition as α and rename the variable in the functional responses attack_rate?

[alaindanet]

You rightly got my poor english (and my poor formatting)! Let's keep producer_competition matrix named $\alpha$ then if @ismael-lajaaiti also agrees.

m and b could be candidate alternative names for slope and intercept? (we cannot use a because it is used in Biorates), right? c and d are also taken by the way 😅

[iago-lito]

I would personally be much in favor of @andbeck's suggestion here : attack_rate.

Single letters are short, but misleading, uninformative, likely to clash and very much volatile since using a over b may change with mood, fashion, research team, community and I bet even moon and season.

attack_rate is short, unambiguous and self-documenting.

Someone said once that if there is one good thing that computer science brought to mathematics.. it's the opportunity to use several letters for every symbol instead of just one X)

(not sure who though..)

One day I'd even be happy to suggest that all single-letters symbols in the package be renamed this way 0:)

[ismael-lajaaiti]

I agree with attack_rate too. The only thing to note is that the 'classic' functional response also contains an attack rate (referred as aᵣ) which might be confusing. Maybe here we want them to have the same name because they represent the same thing, if I'm not wrong.

Side note as we are talking about parameter naming: I would also be in favour to change parameter names that have a subscript such as aᵣ because I found them quite 'hard' to write and IMO they are not necessary (either a_r or attack_rate would do the job and might be even better actually).

[iago-lito]

100% In favour of that as well <3 Julia makes it possible to use fancy characters like ≈, ∈, α, aᵢ as variable names and even as syntactic elements. Maybe this is because there are a lot of mathematicians/physicist involved in the language development :P I need to admit that they have put a lot of effort into doing this well : these characters are only opt-in, and there is good IDE tooling to have them input into a Julia script or at the REPL with shortcuts like \alpha, \in or a\_i.

However (and maybe I'm an old-fashioned folk), I find that they remain a pain to type, especially elsewhere. Here on github for instance, I need to navigate to my vim console to copy-past'em here, same on the other channel(s). More importantly, I also think that they only clarify very few, very specific little chunks of code that are directly transcripted from standard mathematical/physics/ecological equations (like this one). In every other place, they are confusing, and we need to remember/document/search what they mean on a regular basis. Being self-documenting is more valuable than being (extremely) short IMO. And it's not even short to type since you need 7 keystrokes (\·a·l·p·h·a·<tab>) just to input α, and 11 keystrokes (\·a·l·p·h·a·<tab>·\·_·i·<tab>) just to input αᵢ. In comparison, attack_rate is also 11 characters long.

Single-letter symbols are useful when you do mathematical calculations, because then you repeat them a lot, and also you need to forget about their meaning to focus only on the functional structure of your terms. Calculations are blind to the meaning, and you do them better when you see the structure by getting rid of the meaning and shortening symbols a lot. In BEFWM2 however, we are not doing calculations. We are implementing the results of these calculations so people can use them in a context where the meaning of the symbols is important again. Then why obfuscating them under cryptic names like α, η or aᵢ ?

[alaindanet]

I agree very much with attack_rate and most of your development about naming.

I would decrease, however, the weight of the keystroke argument since everybody has nice autocompletion tools nowadays 😄

[iago-lito]

Nowadays, as you write, state-of-the-art autocompleter only needs ar<tab> to catch attack_rate. But ai<tab> does not translate into αᵢ. Try it for yourself ;)

[iago-lito]

@alaindanet maybe we should move this to #114?

[iago-lito]

Should be solved as #114 is adressed.