How are you reading the values? Via CSV by chance?

No, its a shapefile. Im trying to validate fields. So 2.0000000 should pass. im using a regexp to validate

(\\d.\\d{7}|\\d{2}.\\d{7}|\\d{3}.\\d{7}|\\d{4}.\\d{7}|\\d{5}.\\d{7}|\\d{6}.\\d{7}|\\d{7}.\\d{7})

It will fix it, but is that not modifying the data will the type..surely if i bring in 2.0000000 then that should be the value which I should be looking at in FME.

Thanks for taking the time to look at this, I will have a look at how it behaves.

Regards

Apologies @nielsgerrits​ , I selected "Select as Best" assuming that was to vote your answer the best and it deleted your Post!?

I can only reproduce your issue when the shapes attribute is 2.0000000, it becomes 2 as you said. But 2.9999999 does not become 3 in my case. Depending on what you need the StringFormatter might be a solution.

My fault, I misclicked and deleted my own post :\\

Well @nielsgerrits​ ​, I tried the StringFormatter with your suggestion ".7f " and as a work around It has fixed the issue. Thank you for the pointer!!

This is a very interesting question and scenario. With all due respect, you're reading numbers but testing them with string-based search patterns. So I'm not completely surprised it doesn't work.

On the other hand, I do think it's interesting to consider whether FME should return extra zeros. I'd say no because a) these aren't significant digits and b) a double-precision number can have 15 decimal places. For example, for 2.1234567 should we return 2.123456700000000?

But I'm going to raise that with our developers because it is worth consideration and because I think there's always confusion with Shapefile datatypes.

The other issue of 2.999999999 being rounded up I think is due to integer > float conversions. As you probably know, Shapefile stores data solely as integers (even if it says "double"). When FME converts those to proper floating-point values, there's inevitably a slight rounding (it's just how the mathematics works). It's not great, but it's one of the drawbacks of Shapefiles I'm afraid.

Anyway, for this question, I think the best solution is to rethink what you're trying to test. If you're testing for 7 decimal places then using the StringFormatter seems to me to create a self-fulfilling prophecy. The results are bound to be 7dp because you've set it to that. You've also caused FME to convert the number to a string, which might be an issue depending on what you do with that attribute afterwards.

It's kind of ironic because FME did use to read everything as a string and we've put in so much work to improve data typing! So in past FMEs, it might not have been a problem.

Does this help at all? I'm sorry it was a bit of a long answer, but I wanted to explain why I think it's reasonable to return just 2 instead of 2.0000000. I will still confirm with our developers though, because it's obviously an important issue.

Hi @mark2atsafe​ ,

Thank you for your reply. You brought up something I was worried about, in relation to the use of the stringReplacer, and altering it modifying the data inputs.

In relation to our specific case, in the formating of the data we specify the Type Max length and Decimal places in the formating of the shapefiles. So in the example i used in my original question the field containing 2.0000000 was formated as follows..

• Type: Double
• Type Name: Real
• Length: 8 (9 including decimal place)
• Precision: 7

The workbench is for validating datasets coming in from external contractors. We have had issues in the past with datasets having diferent data types and string lengths etc... so the workbench was trying to test that the data coming in meets the requirements above. I was using the AttributeValidator to check this. But as the AttributeValidator can not check the number of Decimal places the RegExp was used as a work around -- and it works, but only after after the string formater of course.

Again, thank you for your responce and for such a detailed explination, its much appreciated!!