Hi Brad,
On Sun, 5 Jul 2015, Brad Chamberlain wrote:
> 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.
That's probably a bit too loose, but tolerable at this stage.
> 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?
Setting the rounding mode as a compile time flags would put you one up
on C/C++! Which should be pretty easy to implement.
However, floating point expressions are something C has done for as long
as know of it.
> 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,
Huge if you are trying to help the optimizer I would say. See below.
> say,
> declaring a module-level 'const' that would be computed once at
> program startup time and could be re-used?
I am going to ignore that because that is slightly different.
I am guessing based purely on my experience with being able to say in
C/C++
static const double <variable-name> = <compile-time-expression>;
compared with
const double <variable-name> = <compile-time-expression>;
As things get more complex, the former comes out in front. For example
#include <stdio.h>
#include <math.h>
#define SQRT_TWO sqrt(fabs(-2.0))
main()
{
static const double sqrtTwo = SQRT_TWO;
static const double sqrtHalf = SQRT_TWO * 0.5;
printf("Look Ma - no sqrt() call! %16.8f %16.8f\n", sqrtTwo, sqrtHalf);
return(0);
}
Compile this with 'gcc', even without the optimizer, and the sqrt() call
is done by the compiler. Note that 'gcc' complains a bit but still does
what it is asked. Look at the assembler and there is no trace of any call
to 'sqrt()' or 'fabs()'.
I think that the 'sqrt' case would be quite hard in Chapel because you
would need either need an overloaded 'sqrt'
proc sqrt(param x : real(w)) param
{
}
or have some other smarts in the compiler. And that opens up a whole new
ball game.
So, let's stick to simple arithmetic expressions and param proc/s.
> 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.
For now, as long as it is not a big no-no for at least standard operators,
I am happy.
No rush to implement.
Regards - 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
