I use DDMathParser to solver formula expressions using Swift. The following code works fine, however, implicit multiplication doesn't. Reading the docs it should work... So, what do I miss here?
my code:
...
substitutions.updateValue(3, forKey: "x")
let myString = "3$x"
do{
let expression = try Expression(string: myString, operatorSet: operatorSet, options: myTRO, locale: myLocale)
let result = try evaluator.evaluate(expression, substitutions: substitutions)
print("expression is: \(expression), the result is : \(result)")
} catch {
print("Error")
}
...
The code throws the "Error". Using the string "3*$x" the expression is calculated as expected.
DDMathParser author here.
So, the .invalidFormat error is thrown when the framework has a sequence of tokens and is looking for an operator in order to figure out what goes around it. If it can't find an operator but still has tokens to resolve but no operator, then it throws the .invalidFormat error.
This implies that you have a 3.0 number token and a $x variable token, but no × multiplication token.
I see also that you're passing in a custom set of TokenResolverOptions (the myTRO variable). I'd guess that you're passing in an option set that does not include the .allowImplicitMultiplication value. If I try to parse 3$x without the .allowImplicitMultiplication resolver option, then I get the .invalidFormat error thrown.
Ok, got it myself. As Dave DeLong mentioned .allowImplicitMultiplication is included by default in the options but will get ignored when creating custom options. Since I want to use localized expressions (decimal separator within expression string is local) I need to use the advanced definition of Expression:
let expression = try Expression(string: ..., operatorSet: ..., options: ..., locale: ...)
In order to use the localized string option I defined let myLocale = NSLocale.current but accidentally also created a new operatorSet new options and passed it to the expression definition. The right way is not to create custom operatorSet and options but to use the defaults within the Expression definition:
let expression = try Expression(string: expressionString, operatorSet: OperatorSet.default, options: TokenResolverOptions.default, locale: myLocale)
Dave DeLong did a really great job in creating the DDMatParser framework. For newbies it is very hard to get started with. The wiki section at DDMathParser is pretty basic and doesn't give some details or examples for all the other great functionality DDMatParser is providing.
Related
To reduce size of my simulation output files, I want to give variable name exceptions instead of a list of many certain variables to the simulationsOptions/outputFilter (cf. OpenModelica Users Guide / Output) of my model. I found the regexp operator "^" to fullfill my needs, but that didn't work as expected. So I think that something is wrong with the interpretation of connected character strings when negated.
Example:
When I have any derivatives der(...) in my model and use variableFilter=der.* the output file will contain all the filtered derivatives. Since there are no other varibles beginning with character d the same happens with variableFilter=d.*. For testing I also tried variableFilter=rde.* to confirm that every variable is filtered.
When I now try to except by variableFilter=^der.*, =^rde.* or =^d.*, I get exactly the same result as without using ^. So the operator seems to be ignored in this notation.
When I otherwise use variableFilter=[^der].*, =[^rde].* or even =[^d].*, all wanted derivation variables are filtered from the ouput, but there is no difference between those three expressions above. For me it seems that every character is interpretated standalone and not as as a connected string.
Did I understand and use the regexp usage right or could this be a code bug?
Side/follow-up question: Where can I officially report this for software revision?
_
OpenModelica v.1.19.2 (64-bit)
I'm attempting to build a caseless regex binary using Regex.compile/2 but can't seem to find an example on how the option should be set.
Regex.compile("^(foo):?", :caseless)
** (FunctionClauseError) no function clause matching in Regex.compile/3
The following arguments were given to Regex.compile/3:
# 1
"^(foo):?"
# 2
:caseless
# 3
"8.41 2017-07-05"
(elixir) lib/regex.ex:140: Regex.compile/3
In short
According to the link you provided, options need to be provisioned as a list as you can provide multiple options. The following should work:
Regex.compile("^(foo):?", [:caseless])
In more detail
The type specification is as follows:
compile(source, options \\ "")
compile(binary(), binary() | [term()]) :: {:ok, t()} | {:error, any()}
The second line is the type specification in dialyzer and basically states that the function compile accepts two arguments:
The first one is a binary, corresponding to your "^(foo):?"
The second one is either a binary, or either a list containing several terms.
The return value will be either {:ok, t()} in the case of success, where t() is a %Regex{} struct or either will be {:error, any()} in the case of an error.
Coming back to the discussion of the second parameter, in the case of a list, you will need to leverage the various options as mentioned here.
In the case of binary, you can provide the second argument as a one letter abbreviation. So whereas the following will fail:
Regex.compile("^(foo):?", "caseless")
The following on the other hand succeeds:
Regex.compile("^(foo):?", "i")
The mapping you can get from the table of the various module modifiers I linked to above.
The main difference between the approaches stems from the fact that Erlang Regex as powered by :re builds on top of the PCRE standard. According to that standard, the various module modifiers are handled by the single lower case letters, such as i, u etc.. So you could combine accordingly both options with binary as follows:
Regex.compile("^(foo):?", "iu")
which technically speaking should give you the equivalent of:
Regex.compile("^(foo):?", [:caseless, :unicode])
This allows you to communicate about Regex in Erlang and in Elixir through either the language specifications, or either the PCRE specifications.
Highly Advanced Details
As the OP rightly pointed out in the comments, there is some confusion as to why the Regex produced in two different ways(e.g. through options as list vs options as binary) looks differently.
To explain this discrepancy in more detail, consider the following scenarios:
r0 = Regex.compile!("(foo):?") ---> ~r/(foo):?/
r1 = Regex.compile!("(foo):?", "i") ---> ~r/(foo):?/i
--->~r/(foo):?/# ?????? WHERE IS THEi` ?????
When confronted with this, one might gain the impression that the Elixir Regex is broken. r0 and r2 are identical and different from r1.
However, functionality wise, r2 behaves like r1, not like r0, consider the following examples as shamelessly inspired by the comment of the OP:
Regex.replace(r0, "Foo: bar", "") ---> "Foo: bar"
Regex.replace(r1, "Foo: bar", "") ---> " bar"
Regex.replace(r2, "Foo: bar", "") ---> " bar"
So how is this possible?
If you recall from above, e.g. pertaining to the explanation of the type t(), a Regex in Elixir is nothing but a struct under the hood.
A Regex may be presented beautifully in the following way: ~r/(foo):?/, but in reality it is nothing but something like this:
%Regex{ opts: opts, re_pattern: re_pattern, re_version: re_version, source: source }
Now, from all those struct fields, the only thing that counts at the end of the day is what is under: re_pattern. That will contain the fully compiled Regex with all the options. So we find that accordingly:
r1.re_pattern == r2.re_pattern
But
r0.re_pattern != r2.re_pattern
As far as the opts field is concerned, that is a container solely reserved for the options in binary format. So you will find that:
- r0.opts == r2.opts == ""
Whereas:
- r1.opts == "i"
These same opts fields are utilized to beautifully display the options at the end of Regex accordingly, so you will see:
~r/(foo):?/ for both r0 as well as r2
But you will see:
~r/(foo):?/i for both r1
on account of the opts fields differing from each other.
It is for this reason that you could manually update the Regex if you would like it to look more consistent by doing this for instance:
%{r2 | opts: "i"} ---> ~r/(foo):?/i
Except for the field, re_pattern, none of the other fields have any functional influence to the actual Regex. Those other fields are merely there for the purpose of documentation only.
Next, on the basis of the source code, you can see that binary options get translated to the list version of options because that is how Erlang regex engine, :re expects them to be.
Even though not difficult in itself, the Elixir core team have opted not to provide translation for the reverse, e.g. from the actual list of module modifier atoms to the equivalent PCRE binary option, thus you end up with the opts field remaining empty and bereft of the corresponding options in PCRE binary format and thus, you end up with the defective rendering of the Regex as evidenced by the discrepancy above.
Above I have only delved into the mechanics that explain the discrepancy, however, whether such a discrepancy is warranted or not is another question in itself. I would be immensely grateful if someone with more insight than me could be so kind as to clarify if there is any way to defend such a discrepancy.
Conclusion
r0 = Regex.compile!("(foo):?") ---> ~r/(foo):?/
r1 = Regex.compile!("(foo):?", "i") ---> ~r/(foo):?/i
r2 = Regex.compile!("(foo):?", [:caseless]) ---> ~r/(foo):?/
r1 and r2 may look different, but they behave exactly the same.
I have been trying to understand why some regular expressions give me an error "Unknown tag" while using the validator.v2 package in golang. It works for some regular expressions but does not work with some which have "{}" inside them, and when I use the validator.Validate() it gives me an error at runtime "unknown tag".
Here's the code:
type Company struct {
Name string `validate:"regexp=^[a-zA-Z .]{1,100}$"`
}
which gives me the following error at runtime:
Name: unknown tag
however this regex works perfectly fine
type Company struct {
Name string `validate:"regexp=^[a-zA-Z .]*$"`
}
I am using the braces because of length restrictions that I want to put on the string. There could be other ways to do it, but I feel the regex is the way to go and is easier to have it along with other rules right there in the expression.
The problem appears to be the , char in your first regex. You can see in the validator source code that the tag is split on ,. By UTSLing, I see no support for escaped commas in the tags; this is probably an oversight on the part of the project author. I suggest filing a bug/feature request.
The problem pointed out by #Flimzy is correct, but it's not a bug.
Probably it was fixed since then, so at the moment validator supports escape sequence \\ for such case, and you can do it like this:
type Company struct {
Name string `validate:"regexp=^[a-zA-Z .]{1\\,100}$"`
}
i really tried to find an answer but i couldn't.
I try to use the regex reference_matchNr to increment a user defined variable.
But i get always the following error msg:
${__intSum(${summe},${count1},summe)};
jmeter.assertions.BeanShellAssertion: java.lang.NumberFormatException: For input string: "${count1}"
or
${__intSum(${summe},"${count1}",summe)};
jmeter.assertions.BeanShellAssertion: java.lang.NumberFormatException: For input string: ""${count1}""
or
${__intSum(${summe},count1,summe)};
jmeter.assertions.BeanShellAssertion: java.lang.NumberFormatException: For input string: "count1"
I used the following code to get the matchNr value:
int count1 = Integer.parseInt(vars.get("status_matchNr"));
The strange thing is i'm able to write the value in the jmeter log(log.info) or in a file.
Thanks in advance.
My expectation is that you're using __intSum() function inside the Beanshell Assertion to add 2 values.
This is not gonna work as the function gets interpreted before the assertion hence your count1 variable is not defined by the moment of function execution.
So workarounds are:
Use "Parameters" input for function evaluation prior interpreting the assertion. You ain't gonna need to convert your "status_matchNr" variable to integer, intSum function will do it for you. So if you put the following line to "Parameters"
${__intSum(${summe},${status_matchNr},summe)};
It assumes that "summe" variable is defined and can be cast to an integer
Go the "code only" way - perform sum of 2 integers purely in Beanshell code like:
int count1 = Integer.parseInt(vars.get("status_matchNr"));
int summe = Integer.parseInt(vars.get("summe"));
summe += count1;
vars.put("summe", String.valueOf(summe));
//your assertion logic here
May I also recommend considering switching from Beanshell to JSR223 Assertion and groovy language as Beanshell has performance problems and may become a bottleneck if your load is high. See Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! guide for details, groovy scripting engine installation instructions and different scripting approaches benchmark.
I am trying to convert the results of a query into an array
this.arLibrary = ValueList(qryLibrary.ID).ListToArray();
And I get the following error
Detail A script statement must end with ";".The CFML compiler was
processing:A script statement beginning with
this.arLibrary on line 43, column 9.A cfscript tag
beginning on line 21, column 2. KnownColumn -1 KnownLine -1
KnownText <unknown> Line 43 Message Invalid construct.
Snippet this.arLibrary =
ValueList(qryLibrary.ID).
StackTrace
This does work
temp = ValueList(qryLibrary.ID);
this.arMetricLibActive = temp.ListToArray();
It makes me wonder if ValueList() is a string
Yes, it's a string. The error is a parsing issue in the CFML engine. The same syntax works fine in Lucee. File a bug like Henry suggested.
Here's an example in the CommandBox REPL
CFSCRIPT-REPL: foo = queryNew('bar')
{
"COLUMNS":[
"BAR"
],
"DATA":[
]
}
CFSCRIPT-REPL: valueList( foo.bar ).listToArray()
[
]
James, it'd be useful if you read error messages when they are presented to you: they generally contain pertinent information. I don't mean this in a "stating the obvious" sort of way, but rather that it's actually a very important part of troubleshooting problems. You are faced with an error message from the compiler, which means the error occurred when the source code was being compiled. However you are asking a question about data types, which - in a loosely and dynamically typed language like CFML - is a runtime consideration. "Runtime" implies "when the code is being run" which is intrinsically after the code is compiled. If the code can't compile: it won't be run.
So the issue is not whether valueList() returns a string or anything like that.
The issue here is that there is a bug in ColdFusion's CFML parser, and it is not able to interpret this expression:
ValueList(qryLibrary.ID).ListToArray()
I don't know why there's a problem with this: there should be no problem with parsing the calling of a method on another function call's return value; and indeed it seems to be a peculiarity of using valueList() like this, as opposed to built-in functions in general.
File a bug.
As for what to do about it in your code in the meantime, I think Dan is right: generally one can use a query column as an array anyhow, provided one uses bracket notation to reference the column, eg: qryLibrary["ID"]. Brad draws attention to this not working on Lucee, but... this is neither here nor there, and just something that Lucee needs to deal with. There was a bug raised for this in Railo - https://issues.jboss.org/browse/RAILO-641 - but they declined to address it, with only semi-valid reasoning.
Epilog:
This works on ColdFusion 2016 and above
<cfscript>
qryLibrary = QueryNew("ID", "varchar");
qryLibrary.addrow({"id" : "cat"});
qryLibrary.addrow({"id" : "dog"});
qryLibrary.addrow({"id" : "fish"});
writedump(qryLibrary);
arLibrary = ValueList(qryLibrary.ID).ListToArray();
writedump(arLibrary);
</cfscript>
https://cffiddle.org/app/file?filepath=6588296c-5e4d-49a4-894b-4986513e9e30/0ecde857-6d28-4e43-88a7-7830c109ab11/84cd7e81-16f8-43d7-b4c9-5490b1b5d007.cfm