Skip to main content
Solved

removing zeroes in front of a value


Forum|alt.badge.img
Hello

 

 

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

Best answer by takashi

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.

View original
Did this help you find an answer to your question?

14 replies

david_r
Celebrity
  • July 1, 2013
Hi,

 

 

you can use a StringReplacer, like this:

 

 

Text to find: ^[0]*

 

Replacement text: (empty)

 

Use regular expressions: yes

 

 

This will remove all leading zeros from any attribute(s).

 

 

David

Forum|alt.badge.img
  • Author
  • July 1, 2013
Thanks a lot, David. It works like a charm.

Forum|alt.badge.img

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.


jonas_nelson
Enthusiast
Forum|alt.badge.img+19
  • Enthusiast
  • December 13, 2019
hektopascal wrote:

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.


takashi
Influencer
  • Best Answer
  • December 14, 2019

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.


takashi
Influencer
  • December 14, 2019
hektopascal wrote:

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.


Forum|alt.badge.img
hektopascal wrote:

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

 

 


takashi
Influencer
  • December 16, 2019
hektopascal wrote:

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.


Forum|alt.badge.img
hektopascal wrote:

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

 

 


takashi
Influencer
  • December 16, 2019
hektopascal wrote:

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?


chrisatsafe
Contributor
Forum|alt.badge.img+2
  • Contributor
  • December 20, 2019

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.


chrisatsafe
Contributor
Forum|alt.badge.img+2
  • Contributor
  • December 20, 2019
takashi wrote:

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.


bwn
Evangelist
Forum|alt.badge.img+26
  • Evangelist
  • December 21, 2019

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


takashi
Influencer
  • December 21, 2019
chrisatsafe wrote:

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 + 1

However, 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.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings