I'm revising a data step that resides in a SAS macro. Currently a single format is used to create a new field for the whole dataset. I'm attempting to revise it to where a different format will be used on different subsets of the dataset. (I have a field that indicates which subset the row belongs to.)
I could do this with a bunch of if statements, but that would need to be changed if the number of categories changes in the future. I think I can achieve what I want by using call symput and resolve but I'm unsure what the syntax for that would be. Can I achieve this without resorting to if statements?
Your question isn't perfectly clear, but if you want to do something like
newvar = put(oldvar,MYFMT.)
->
if x=1 then newvar=put(oldvar,MYFMT.);
else newvar=put(oldvar,MYFMT2.);
But without all of the if statements, you can use PUTN or PUTC, which allows you to specify the format at runtime.
newvar = putn(oldvar,fmtvar); *optionally can specify w and d as separate arguments also;
Related
When you open the print dialog of an editor, you typically get a field for specifying which pages you want to print - which can be multiple ranges, e.g.: "5,11,31-33"
Now, there are other scenarios in which this kind of input from a user is relevant - especially in configuration files for sequential or iterative processes where you want to qualify which iterations or elements a certain action or feature should apply to.
However, I'm not aware of a name for this kind of strings; nor of an accepted standard format/convention for them (i.e. can you add spaces? Can you use semicolons instead of commas? Must the ranges be sorted? Are overlaps allowed and are they maintained or discarded? Can ranges use ".." instead of "-"? Can you range down instead of up? etc.).
Is there some such convention or such standard?
My motivation is double: I need to parse such ranges in a piece of code I'm looking at, any I want both to do it correctly (or rather per-convention), and secondly to go look for parsing functionality in existing libraries. Right now I don't even have a name to go on.
I'm using data from synthea and it looks like most (all?) of the given and family names I'm getting back end with a three digit number (e.g. Gregg522). Is this part of the design of synthea or am I parsing the data incorrectly. A snippet of the json I'm getting back is shown below. If this is part of the design, what is the motivation of ending the name with a number (I would think this would make the data less realistic).
Yes, they generally do. It is sometimes nice to be able to see that the patients are fake/synthetic ones. However, this is a setting you can change: In the synthea.properties file, look for the setting "append_numbers_to_person_names" and set it to false.
I got a problem that I have some measurement data ( like Echo measurements), that can potentially have multiple values associated with it. In other words, you have a single measurement, but multiple values associated.
Is there a standard way to represent multiple values for a single measurement as a Observation?If so, what is the best way?
I notice that under observation, you can have multiple components, should I put my LOINC code for my measurement just at observation level and put each value at component level? Or I have to use extensions?
Thanks!
I am not sure exactly what your data looks like but here are a couple of patterns:
There is sampledData Datatype that can be used for datastreams like an EKG
example
If you have discrete values that are all interpreted together with an observation ( they can't stand alone as independent observations) the using components with an Observation.code= code, Observation.value[x] is empty , Observation.component.code= code, Observation.component.value[x]= result value. here is an example of this pattern.
In some cases you will have an Observation.value[x] as well.
Note Observation.component.code is required for each component.
For grouping indpendent observations together using component is not appropriate. This grouping is done using DiagnosticReport.result or Observation.related. The DiagnosticReport resource which typically used for reporting diagnostics in responce to an order.
I'm currently working with JMeter in order to stress test one of our systems before release. Through this, I need to simulate users clicking links on the webpage presented to them. I've decided to extract theese links with an XPath Post-Processor.
Here's my problem:
I have an a XPath expression that looks something like this:
//div[#data-attrib="foo"]//a//#href
However I need to extract a specific child for each thread (user). I want to do something like this:
//div[#data-attrib="foo"]//a[position()=n]//#href
(n being the current index)
My question:
Is there a way to make this query work, so that I'm able to extract a new index of the expression for each thread?
Also, as I mentioned, I'm using JMeter. JMeter creates a variable for each of the resulting nodes, of an XPath query. However it names them as "VarName_n", and doesn't store them as a traditional array. Does anyone know how I can dynamicaly pick one of theese variables, if possible? This would also solve my problem.
Thanks in advance :)
EDIT:
Nested variables are apparently not supported, so in order to dynamically refer to variables that are named "VarName_1", VarName_2" and so forth, this can be used:
${__BeanShell(vars.get("VarName_${n}"))}
Where "n" is an integer. So if n == 1, this will get the value of the variable named "VarName_1".
If the "n" integer changes during a single thread, the ForEach controller is designed specifically for this purpose.
For the first question -- use:
(//div[#data-attrib="foo"]//a)[position()=$n]/#href
where $n must be substituted with a specific integer.
Here we also assume that //div[#data-attrib="foo"] selects a single div element.
Do note that the XPath pseudo-operator // typically result in very slow evaluation (a complete sub-tree is searched) and also in other confusing problems ( this is why the brackets are needed in the above expression).
It is recommended to avoid using // whenever the structure of the document is known and a complete, concrete path can be specified.
As for the second question, it is not clear. Please, provide an example.
I made a report with about 30 different rectangles and textboxes that have different visibility expressions depending on the parameters. (It's a student invoice and many different messages have to appear depending on the semester) When I made all the expressions I coded in the parameters in all upper case. Now I have a problem when users enter lowercase letters, the SQL all works fine since it is not case sensitive, but the different rectangles and textboxes don't show. Is there a way in the report code to first capitalize all the parameters before running the SQL? Or do I actually have to go back to every visibility expression and add separate iif's for upper and lower case? (That seems incredibly silly to have to do). I can't change my parameters to numbers because I have been given strict requirements for input. Thanks.
I do not know if this is the most elegant solution, but you could accomplish this by following this procedure for every parameter on the Report Parameters page:
1)Re-name the parameter, leaving its prompt as that of the old parameter.
2)Add a new parameter with the same name as the old parameter.
3)Mark this new parameter as Hidden.
4)Make sure that the new parameter's available values are marked as non-queried(available values will never be actually used.)
5)Mark the Default Values as Non-queried, using the following syntax:
=ucase(Parameters!OldParameterName.Value)
Can't you just UCASE the params (do it in the xml view, it will be quicker and you might even be able to do a regex find/replace)