action type="schedule" -- parsing in tags
Hi Chris,
I see in your examples that the "schedule" action takes a timebase suffix at the end of the delay param:
"500 ms" for example. I found some unique behavior when you use an expression in the tag.
For example: when schedDelayUs is 500000,
delay="(schedDelayUs/1000.0) ms"
produces a delay of 500 ms, and
delay="schedDelayUs/1000.0 ms"
produces a delay of 0 ms.
Perhaps you could document how these parameters are intended to be parsed? I didn't explore the space widely, just enough to fix the bug I am seeing.
Thanks,
Mark
- SchedParseTest.xml 4.16 KB
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Christopher Sta... on 27 Mar, 2014 03:39 PM
Hi Mark,
The time unit suffixes are a feature of the expression parser. They're implemented as unary postfix operators, with precedence just above the unary prefix operators (
+ - ! not
). When evaluated, they have the following effect (wherex
is any expression):The "unique" behavior you're seeing is the result of operator precedence, specifically the fact that the time suffix operators have higher precedence than any other operators. In the expression
the parentheses cause
schedDelayUs/1000.0
to be evaluated first, with the result being multiplied by 1000. On the other hand, inthe
1000.0 ms
term is evaluated first, so the expression reduces toand your requested delay is actually 0.5 microseconds.
There are a couple reasons why I've been hesitant to document or otherwise advertise this feature. First, implementing units as a shorthand for multiplication is kind of flaky. For example, the following expression is perfectly valid and evaluates to 5e12:
Second, time units are handled inconsistently in MWorks, and mixing different approaches can get you in trouble. For example, both the "wait" and "start_timer" actions accept an arbitrary expression (which can include time units) for their "duration" parameter, while also supporting a separate "duration_units" parameter. This means you can do something like
which will result in a wait of 1000000 seconds.
Hence, I'm not sure that anyone should be encouraged to use the time unit operators.
Chris
2 Posted by Mark Histed on 27 Mar, 2014 05:01 PM
> Hence, I'm not sure that anyone should be encouraged to use the time unit operators.
>
Agreed.
Thanks for explaining. I realized it was some sort of precedence issue. I got the time unit operators out of an example (the schedule_actions example?). I will avoid them from now on.
It's perhaps worthwhile to document this lack of encouragement somewhere.
Mark
Support Staff 3 Posted by Christopher Sta... on 29 Apr, 2014 07:52 PM
Hi Mark,
After thinking about (and using) the time unit operators some more, I'm finding that they are useful enough to keep around and even recommend.
One place where I use them a lot is specifying parameters for I/O devices. For example:
Specifying the intervals with expressions like
3ms
seems much nicer than the alternatives, namely omitting the units (3000
) or giving them in a separate parameter (update_interval_units="ms"
).As another example, while writing tests for the
wait_for_condition
action, I found it very helpful to be able to write assertion conditions likeWhile the issues I mentioned previously remain a concern, I now think the best course of action is to document the time unit operators properly and include an explanation of the potential pitfalls -- which is exactly what I was already planning to do, except for the part about discouraging their usage.
Chris
4 Posted by Mark Histed on 29 Apr, 2014 08:21 PM
Thanks.
Just so I am clear:
In MWorks, I assume that "3ms" is an integer with value 3000
and "3e3" is a float also with value 3000?
M
Support Staff 5 Posted by Christopher Sta... on 30 Apr, 2014 01:52 PM
Correct. Also,
3.0ms
is a float with value 3000.Chris
Christopher Stawarz closed this discussion on 14 Apr, 2015 05:15 PM.