Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expressions improvements: escape chars and unicode #1333

Merged
merged 6 commits into from
Oct 22, 2018
Merged

Conversation

bendudson
Copy link
Contributor

@bendudson bendudson commented Oct 19, 2018

New features:

  1. Allow escaping of characters in expressions
  2. Allow unicode (utf-8) option names
  3. Implicit multiplication in expressions

Includes unit tests and documentation

Escaping characters

If variables have names which include symbols like + then expressions need to escape the symbols to avoid treating them as arithmetic operators. This can be important when evolving variables with names
like "H+" or "He+2".

Two mechanisms currently allowed:

  1. A backslash () escapes the following character, so an expression could include something like "h2+:density" as a symbol

  2. Backquotes escape a sequence of characters, so "h2+:density" or "h2+:density" could be used.

Note that the colon symbol always indicates section, and is not escaped. This is to avoid ambiguity. The options reader therefore checks if keys include : and throws if they do.

Unicode names

The reader has been made less strict about what it accepts as a valid symbol. Rules are:

  • Cannot contain : (as reserved for sections)
  • Must not start with a number or a . (or it will be read as a number). These can be escaped.

When referred to in an expression, arithmetic operators, brackets, commas (+-*/^(){}[],) and whitespace must be escaped.

Implicit multiplication

If a number is followed by a symbol or an opening bracket, then a multiplication is assumed. This is a nice (I think) feature of Julia which reduces clutter in expressions.

3sin(2π*x) or 3 sin(2 π * x) are equivalent to 3*sin(2*pi*x).

If variables have names which include symbols like + then expressions
need to escape the symbols to avoid treating them as arithmetic
operators. This can be important when evolving variables with names
like "H+" or "He+2".

Two mechanisms currently allowed:

1. A backslash (\) escapes the following character, so an expression
   could include something like "h2\+:density" as a symbol

2. Backquotes escape a sequence of characters, so "`h2+:density`" or
"h`2+`:density" could be used.

Note that the colon symbol always indicates section, and is not
escaped. This is to avoid ambiguity. The options reader therefore
checks if keys include `:` and throws if they do.

Unit tests added for all these things
Describes how to use variables with symbols in expressions
by escaping them using \ or ` methods.
Symbols in expressions can now have a much wider range of characters,
including utf-8. Anything except whitespace and some reserved
operators and brackets, which can be escaped if needed.

Updated documentation, added tests.
@bendudson bendudson changed the title Options escape chars Options escape chars and unicode Oct 19, 2018
Was being included in the symbol, so functions of two arguments
failed. A unit test is added to catch this.

Updated documentation
If a number is followed by a symbol or an opening bracket, then a
multiplication is assumed. This is a nice (I think) feature of Julia
which reduces clutter in large expressions.

`3sin(2π*x)` or `3 sin(2 π * x)` are equivalent to `3*sin(2*π*x)`.

Added tests and documentation.
@bendudson bendudson changed the title Options escape chars and unicode Expressions improvements: escape chars and unicode Oct 20, 2018
@ZedThree ZedThree added this to the BOUT-4.3 milestone Oct 22, 2018
@ZedThree ZedThree merged commit 490f44a into next Oct 22, 2018
@ZedThree ZedThree deleted the options-escape-chars branch October 23, 2018 09:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants