Even if I do @Value(Population2011)/@Value(PopulationTotal) * 100 the result is 0

 

 

why?

---

documentation:

 

5 / 4

 

 

returns 1, while

 

 

5 / 4.0

 

 

and

 

 

5 / (4 + 0.0)

 

 

both return 1.25.

---

Ok so I have to do:

 

 

(@Value(Population2011)+ 0.0) / (@Value(PopulationTotal)+ 0.0) * 100.0

 

 

thats weird but I'll go with that...

---

Hi,

 

 

Itay is right. 5/4 returns 1, in FME 2014 and earlier.

 

But I heard that the behavior will be changed in FME 2015.

 

I discussed about this here just a few days ago.

 

3/2 returns 1 or 1.5? (http://fme-memorandum-takashi.blogspot.com/2014/12/32-returns-1-or-15.html)

 

 

It would be a significant change, I hope that Safe officially announces about this.

 

 

Takashi

---

Very interesting blog Takashi. I wonder however why the type of attribute is not preserved in the ExpressionEvaluator. The output seems to always be a string, not a int or a float. That's what confuse me. If you do int(3/2) the resut is a string with value 1 not an integer with value 1. If you do 3.0/2 the output is a string with 1.5 value not a float.

---

It's one of frequently asked questions. The answer is here.

 

FME Workbench documentation > Attributes (http://docs.safe.com/fme/html/FME_Workbench/Default.htm#3D/Attributes.htm)

 

 

"FME stores all attributes as character strings and automatically converts between a string representation and a numeric representation as needed."

 

... basically.

---

Hi all,

 

Yes, in FME2014 or earlier we go with the computing standard that processing two integers gives an integer result (so 7/2=3). In FME2015 we're going with floating point values instead, so 7/2=3.5

 

 

Old workspaces will run as before, with exactly the same results as before, until you open the transformer dialog. Then a warning will pop up to tell you that it has been updated to floating point.

 

 

But we figure it would be a rare case where a user did want 7/2=3, and most would have used 7/2.0 (or similar) which will just operate as it did before. So all should be good.

 

 

As for attribute types, as Takashi says, we've not worried too much before. We just converted as necessary. However, we're again changing to improve this. For example, I  just tried 7/2 in FME2015 and got:

 

 

Attribute(64 bit real) : `_result' has value `3.5'

 

 

I don't think we'll get too strict though. Otherwise we'd end up having "cast" transformers to convert type, whereas we'd prefer the transformers to just work, whatever the type.

 

 

Hope this helps

 

 

Mark

 

 

Mark Ireland

 

Product Evangelist

 

Safe Software Inc.

---

Hi Mark, I've noticed the improvement concerning attribute types in FME 2015 beta.

 

I think that the description I quoted in my previous post should also be updated.

 

Takashi

---

A popular in your eyes "rare" case, wich i use often:

 

 

 

Slect every 2nd, 3d etc. ..

 

 

Tester: @Counter/2=@Counter/2.0

 

Tester: @Counter/3=@Counter/3.0

 

 

..and of course there are alternatives to do this..but this is by far the most elegant one.

 

 

There are more uses for the difference:

 

Like making a list where 

 somevalue/@Testvalue

 

 

drops to zero (of course be aware of zero devide..snore)

 

or other preset or even periodic value:

 

 

somevalue/@Testvalue = (counter/2)/(counter/2.0)

 

 

And more cases etc.

 

 

Not that rare of use.

 

Luckily, tcl still keeps it up. :)

 

 

 

---