Hi Damian --
This is a good question, one that comes up somewhat frequently, and one
for which I think we'd like more input from the Chapel user community.
The reason we originally shied away from supporting param floating point
expressions was concern about the degree to which the compile-time
compiler/platform's floating point arithmetic would be compatible with the
execution-time compiler/platform's floating point arithmetic w.r.t. things
like roundoff. So rather than open up a batch of potential
surprises/issues, we took the conservative/easy path and just didn't add
support for param operators/expressions for floating point.
Since then, when people have been surprised that it isn't supported, it's
been proposed that since 'param' machinery is very explicit in Chapel,
perhaps we could simply say "You said compute it at compile-time, why did
you think it would necessarily match anything at execution-time?" as an
excuse in response to any surprises. Or perhaps any full-fledged support
for specifying rounding modes and such should be extended to
compile-time/param expressions as well... "whatever precision is active"
is part of the challenge in your mail -- what does/should that mean at
compile-time?
OTOH, I think there's also a bit of a question about whether there is
significant value of computing such values at compile-time as compared to,
say, declaring a module-level 'const' that would be computed once at
program startup time and could be re-used?
Without further input, at present, I'd say that there's no big push to
adding support for param floating point; but also no significant barriers
or opposition (that I'm aware of). Simply decisions to be made and work
to be done to implement it.
-Brad
On Sun, 5 Jul 2015, Damian McGuckin wrote:
>
> CRITICALITY : NOT URGENT
>
> Is a param comprises of real expressions with results known at compile
> time likely to be supported at any time into the future.
>
> For example I want the program to know the most accurate value
> possible of say 2.0/3.0 to whatever precision is active
>
> Only the first param defined below is legitimate;
>
> inline proc twothirds(param x : real(64)) param return 2.0:real(64) / x;
>
> proc run()
> {
> param try1 = 0.666666666666666666666666666666666666666666666:real(64);
> param try2 = twothirds(3.0:real(64));
> param try3 = 2.0:real(64) / 3.0:real(64);
>
> // some other waffle
> }
>
> Thanks - Damian
>
> Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
> Views & opinions here are mine and not those of any past or present employer
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Chapel-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-users
>
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
