Let me start off with, I am new at this, so bear with me.
I am pulling data in from an excel file and I need an expression that can look at one of my rows that has both decimals and percentages in it. I need them to be uniform and just have decimal format. So basically, some of fields have either 5% (shown with the % sign) and others have .05. I need all of my output to have the .05 type. I have been trying to figure this out for hours and am at a loss.
Currently I am using (DT_DECIMAL,6)REPLACE(TRIM([Percentage Off]),"%","") but that seems to just be stripping the percentage sign off and it doesn't convert the number to a percentage. Any help would be kindly appreciated.
The set of links below will likely get you to the answer.
Note that you may need only a CAST, not a REPLACE.
I do not have a system at hand where to test this, but I expect it to be useful (if not providing the explicit answer) for you.
Cast (SSIS Expression).
Syntax:
(type_spec) expression
REPLACE (SSIS Expression).
Syntax:
REPLACE(character_expression,searchstring,replacementstring)
? : (Conditional) (SSIS Expression).
Syntax:
boolean_expression?expression1:expression2
Operators (SSIS Expression).
SSIS Converting Percent to Decimal.
Related
I have user-provided format strings, and for each, I have a corresponding slice. For instance, I might have Test string {{1}}: {{2}} and ["number 1", "The Bit Afterwards"]. I want to generate Test string number 1: The Bit Afterwards from this.
The format of the user-provided strings is not fixed, and can be changed if need be. However, I cannot guarantee their sanity or safety; neither can I guarantee that any given character will not be used in the string, so any tags (like {} in my example) must be escapable. I also cannot guarantee that the same number of slice values will exist as tags in the template - for example, I might quite reasonably have Test string {{1}} and ["number 1", "another parameter", "yet another parameter"].
How can I efficiently format these strings, in accordance with the input given? They are for use as strings only, and don't require HTML, SQL or any other sort of escaping.
Things I've already considered:
fmt.Sprintf - two issues: 1) using it with user-provided templates is not ideal; 2) Sprintf does not play nicely with a number of parameters that doesn't match its format string, adding %!(EXTRA type=value) to the end.
The text/template library. This would work fine in theory, but I don't want to have to make users type out {{index .arr n}} for each and every one of their tags; in this case, I only ever need slice indexes.
The valyala/fasttemplate library. This is pretty much exactly what I'm looking for, but for the fact that it doesn't currently support escaping the delimiters it uses for its tags, at the time of writing. I've opened an issue for this, but I would have thought that there's already a solution to this problem somewhere - it doesn't feel like it's that unique.
Just writing my own parser for it. This would work... but, as above, I can't be the first person to have come across this!
Any advice or suggestions would be greatly appreciated.
I'm working on a NodeJs script that handles strings with exponential values.
Something like this:
1.070000000000000e+003
Which is the best way to convert (or parse) this string and obtain a floating value?
Thanks for the help.
You may convert by using parseFloat or Number
If you prefer to parse, maybe the best way is by a regular expression:
/-?(?:0|[1-9]\d*)(?:\.\d*)?(?:[eE][+\-]?\d+)?/
as suggested here and convert the single capturing group.
I have an input file in this format: (length 20, 10 chars and 10 numerics)
jname1 0000500006
bname1 0000100002
wname1 0000400007
yname1 0000000006
jname1 0000100001
mname1 0000500012
mname2 0000700013
In my jcl I have defined my sysin data as such:
SYSIN DATA *
SORT FIELDS=(1,1,CH,A)
SUM FIELDS=(11,10,FD)
DATAEND
*
It works fine as long as I don't add the sum fields so I'm wondering if I'm using the wrong format for my numerics seeing as I know they start at field 11 and have a length of 10 the format is the only thing that could be wrong.
As you might have already realised the point of this JCL is to just list the values but grouped by the first letter of the name (so for the example data and JCL I have given it would group the numeric for mname1 and mname2 together but leave the other records untouched).
I'm kind of new at this so I was wonder what I need for the format if my numerics are like that in the input file.
If new to DFSORT, get hold of the DFSORT Getting Started guide for your version of DFSORT (http://www-01.ibm.com/support/docview.wss?uid=isg3T7000080).
This takes your through all the basic operations with many examples.
The DFSORT Application Programming Guide describes everything you need to know, in detail. Again with examples. Appendix C of that document contains all the data-types available (note, when you tried to use FD, FD is not valid data-type, so probably a typo). There are Tables throughout the document listing what data-types are available where, if there is a particular limit.
For advanced techniques, consult the DFSORT Smart Tricks publication here: http://www-01.ibm.com/support/docview.wss?uid=isg3T7000094
You need to understand a bit more the way data is stored on a Mainframe as well.
Decimals (which can be "packed-decimal" or "zoned-decimal") do not contain a decimal-point. The decimal-point is implied. In high-level languages you tell the compiler where the decimal-point is (in a fixed position) and the compiler does the alignments for you. In Assembler, you do everything yourself.
Decimals are 100% accurate, as there are machine-instructions which act directly on packed-decimal data giving packed-decimal results.
A field which actually contains a decimal-point, cannot be directly used in arithmetic.
An unsigned field is treated as positive when used in any arithmetic.
The SUM statement supports a limited number of numeric definitions, and you have chosen the correct one. It does not matter that your data is unsigned.
If the format of the output from SUM is not what you want, look at OPTION ZDPRINT (or NOZDPRINT).
If you want further formatting, you can use OUTREC or OUTFIL.
As an option to using SUM, you can use OUTFIL reporting functions (especially, although not limited to, if you want a report). You can use SECTIONS and TRAILER3 with TOT/TOTAL.
Something to watch for with SUM (which is not a problem with the reporting features) is if any given one (or more) of your SUMmed fields exceed the field size. To continue to use SUM if that happens, you need to extend the field in INREC and then get SUM to use the new, sufficient, size.
After some trial and error I finally found it, appearantly the format I needed to use was the ZD format (zoned decimal, signed), so my sysin becomes this:
SYSIN DATA *
SORT FIELDS=(1,1,CH,A)
SUM FIELDS=(11,10,ZD)
DATAEND
*
even though my records don't contain any decimals and they are unsigned, I don't really get it so if someone knows why it's like that please go ahead and explain it to me.
For now the way I'm going to remember it is this: Z = symbol for real (meaning integers so no decimals)
I'm learning Groovy. I want an array of numbers from 0 to n with interval 0.1.
double arr=[0,0.1,0.2....n]
I could write a java style for-loop, but is there a easier syntax to do this? I know Groovy has a lot of syntactic sugar.
I would go with 0.0..10.0.collect{it/10.0} but maybe there is clever way to do it by specifying increments.
there was an exact question here earlier
n=10;(0..10*n).collect{it/10}
there are no decimal step values for Groovy's ranges
currently
I have added the new token RATIONAL that recognises rational numbers on my JavaCC parser. How can I update the output part of the program to print the numeric value of the rational number?
For example ('2/5') value = 0.4, ('8/2') value = 4.0, ('4/0') value = infinity.
I will be grateful if anyone could help me. Thanks.
You need to further split the image of your RATIONAL token in order to have both numbers available for computation.
It's not clear from your question whether the parentheses and quotes are part of the defined syntax. If they are, you can easily define them as delimiters for a rational expression and define tokens for the numbers and the slash. In case of ambiguity with other places where numbers can appear, remember that lexical states are your friends.
If a rational expression is simply made of two numbers separated by a slash, then I'd recommend building an AST and evaluate it after the parsing is complete. You can alternatively evaluate it during the parsing, but the difficulty of this depends on the rest of your grammar.