I am looking for a way to remove zeroes from some attributes, but not all.
1) I have sliced up a string using the "AttributeSplitter" with delimiter "3s4s"
2) original data is 1234567 -> two new lists (list1: 123 & list2: 4567).
3) Sometimes list2 have 0 as the first character. I am looking for a way to delete this 0 without deleting values with four characters.
Regards,
Stig
you can use a StringReplacer, like this:
Text to find: ^d0]*
Replacement text: (empty)
Use regular expressions: yes
This will remove all leading zeros from any attribute(s).
David
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
Interesting. But then again, to round a string (=text) might be different from rounding a number.
That's a strange behavior. I think FME should consider '00016' as 16 when treating the value as a number. @danatsafe, could you please take a closer look at this?
I would use the AttributeTrimmer (Trim Type: Left, Trim Characters: 0, Arrow Trim Down to Nothing) to remove leading 0s from a string.
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
That's a strange behavior. I think FME should consider '00016' as 16 when treating the value as a number. @danatsafe, could you please take a closer look at this?
I would use the AttributeTrimmer (Trim Type: Left, Trim Characters: 0, Arrow Trim Down to Nothing) to remove leading 0s from a string.
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
This is not a bug but the result of the fact that the math in FME is using Tcl math engine and in Tcl numbers starting with 0 are treated as Octal number, so 016 = 8 + 6 = 14, you can try it out in FMEFunctionCaller here
@Evaluate(10*10) = 100 - decimal
@Evaluate(010*010) = 64 - octal
@Evaluate(0b10*0b10) = 4 – binary
@Evaluate(0x10*0x10) = 256 – hexadecimal
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
Yes, 016 is an octal number representation in Tcl script, but I remember FME abandoned the Tcl manner at some point, and in the modern FME you should use the prefix "0o" to represent an octal number in math expressions. The ExpressionEvaluator returns 16 for "016", 14 for "0o16".
The AttributeRounder seems to still follow the Tcl manner. I don't know if it's intentional.
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
Hi Takasi
I look like underling mat still use Tcl, but if you look at the mapping file code for ExpressionEvaluator you will see that it don’t use @Evaleuate() but @EvaluateExpression() and that it force the mat to use floating point numbers rather than integer math.
@Evaluate(010.0 * 010.0 ) = 100 – floting point math
I just looked at the mapping file code for AttributeRounder and it use Tcl rather than the the build in @round() so that is the course of the problem
Peter
DO NOT use attributerounder! In my workspace, the string '00016' became the number 14 when attributeRounder had finished... one of the weirdest bugs I've chased.
I feel something inconsistent in FME specifications here. I would like to hear Safe's official opinion. @daleatsafe, how do you think of this?
Hi @takashi, @peterlaulund,, @jonas_nelson, and @hektopascal:
I heard back from one of our developers on this matter and @peterlaulund is correct because numbers that start with 0 are assumed to be octal by some libraries: https://core.tcl-lang.org/tips/doc/trunk/tip/114.md
It sounds like @takashi's method of trimming the zeros, rounding then padding is the best way forward for this.
I feel something inconsistent in FME specifications here. I would like to hear Safe's official opinion. @daleatsafe, how do you think of this?
Hi @takashi, @peterlaulund,, @jonas_nelson, and @hektopascal:
I heard back from one of our developers on this matter and @peterlaulund is correct because numbers that start with 0 are assumed to be octal by some libraries: https://core.tcl-lang.org/tips/doc/trunk/tip/114.md
It sounds like @takashi's method of trimming the zeros, rounding then padding is the best way forward for this.
An alternative is if you just want the answer to be a numeric is to use a formula to recast the string to a numeric.
You could just use an AttributeCreator with a formula that recasts the string to a numeric like int() and double()
@int(@Value(StringAttribute))In the above, if StringAttribute = "0123" the result from the formula is an integer 123
Hi @takashi, @peterlaulund,, @jonas_nelson, and @hektopascal:
I heard back from one of our developers on this matter and @peterlaulund is correct because numbers that start with 0 are assumed to be octal by some libraries: https://core.tcl-lang.org/tips/doc/trunk/tip/114.md
It sounds like @takashi's method of trimming the zeros, rounding then padding is the best way forward for this.
Hi @chrisatsafe, thanks for your response.
I know that a number starting with 0 was always treated as an octal number in the old versions of FME. For example, this expression set in the ExpressionEvaluator in FME 2014 and earlier returns 9, since 010 was treated as an octal number which is equal to 8 in decimal.
010 + 1However, in 2015 or so, I remember that Safe decided to change the representation for octal numbers. That is, in FME 2015 or later, leading zeros of an integer representation will be ignored, so the expression above returns 11. Only "0o" is available to represent an octal number in math expressions.
According to the history above, I thought that 00016 should always be treated as 16 in decimal in the modern FME, and therefore I feel that the AttributeRounder case is inconsistent with the current FME specifications. Possibly similar inconsistency could be in some other transformers.
I'd like to hear how Safe thinks about the inconsistency.