Add new interpolation function abs.

[kwilczynski]

This commit adds new interpolation function abs which returns an absolute
value for a given float. Having an ability to obtain an absolute value remove
the need to use and abuse the signum function to achieve the same gaol.

Signed-off-by: Krzysztof Wilczynski kw@linux.com

[kwilczynski]

Tests are passing:

$ make test TEST=./config
==> Checking that code complies with gofmt requirements...
go generate ./...
2017/09/24 23:10:48 Generated command/internal_plugin_list.go
go test -i ./config || exit 1
go list ./config | xargs -t -n4 go test  -timeout=60s -parallel=4
go test -timeout=60s -parallel=4 github.com/hashicorp/terraform/config
ok  	github.com/hashicorp/terraform/config	0.223s

[kwilczynski]

Hi @vancluever, a Pull Request as discussed.

There is one thing I would love to be able to solve - math.Abs works naively on floats, and we make it work for integers here. We can specify both the ast.TypeInt and ast.TypeFloat via the ArgTypes and it would be trivial to support both. But, it seems we need to only return single type as per ReturnType, and in this case it's obviously an integer. I can't see any way to return either type or an interface{} (hoping that the underlying type would be detected, etc.), but perhaps I am wrong. Is there something that can be done to support both floats and integers?

[kwilczynski]

As per the conversation with @vancluever, I moved abs to use ask.TypeFloat. The only red herring here is something like this abs(-1.0), where it would return 1 rather than 1.0, which is also something that pow function "suffers" from, so to speak, and seem to be a side effect of current implementation of either parser or something internal to AST code.

[vancluever]

LGTM! Just adding @jbardin and @apparentlymart to confirm.

Also as an aside - we uncovered some inference here that seems a bit confusing when it comes to whole numbers expressed as floats, as @kwilczynski describes above. I'm not too sure where it happens (before or after interpolation), but a whole number expressed as say, 1.0 ends up getting turned into an int somewhere, and comes out as 1, or at the very least gets displayed as an int when output.

At the very least it's kind of confusing in this context when the user wants to make sure they are getting a float back. Maybe some clarification is in order just to confirm? I'm trying to look to see exactly where this happens.

[apparentlymart]

It's intentional that the string representation of a float representing a whole number doesn't have a fractional part. The distinction between int and float is actually planned to be removed in the future, since it doesn't really seem to be a useful distinction for things Terraform is generally used for. (more news on that to come soon.)

Generally-speaking, any time a non-list/non-map value is moved between attributes via interpolation (as opposed to within an interpolation expression) it is always converted to a string, since Terraform Core treats all primitive types as strings today. That too is something that will change in future, as part of some type system work. For now though, "getting a float back" isn't really a meaningful concept... the best you can do is get a string representation of a number, which might later get converted back into a number again when passed to other functions.

This looks fine to me, and does the best it can within the current constraints. Thanks for working on this, @kwilczynski!

[vancluever]

FWIW, I think under the hood things work as expected, it seems the behaviour is mainly just superficial. Nothing that I saw would indicate anything seriously breaking as a result of this... so I think it will behave correctly 👍

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.