View mode: basic / threaded / horizontal-split · Log in · Help
October 12, 2009
Specializing on Compile Time Constants
I'm working on a mathematical expression interpreter for D, which would allow
for closed form mathematical expressions to be specified as string literals at
runtime and be evaluated.  For example:

MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
writeln(myExpression(2));  // Does exactly what you think it does.

I've found the syntax so convenient that I'd like to transparently specialize
it on strings known at compile time.  The idea is that, when the expression is
hard-coded, you will still be able to use the MathExp interface, but your
expression will evaluate at the full speed of a statically compiled function.
Is there any way to test whether the value of an argument to a template
function is known at compile time and specialize on this?
October 12, 2009
Re: Specializing on Compile Time Constants
On 10/12/09 23:49, dsimcha wrote:
> I'm working on a mathematical expression interpreter for D, which would allow
> for closed form mathematical expressions to be specified as string literals at
> runtime and be evaluated.  For example:
>
> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> writeln(myExpression(2));  // Does exactly what you think it does.
>
> I've found the syntax so convenient that I'd like to transparently specialize
> it on strings known at compile time.  The idea is that, when the expression is
> hard-coded, you will still be able to use the MathExp interface, but your
> expression will evaluate at the full speed of a statically compiled function.
>   Is there any way to test whether the value of an argument to a template
> function is known at compile time and specialize on this?

Doesn't all values to a template have to be known at compile time
October 12, 2009
Re: Specializing on Compile Time Constants
== Quote from Jacob Carlborg (doob@me.com)'s article
> On 10/12/09 23:49, dsimcha wrote:
> > I'm working on a mathematical expression interpreter for D, which would allow
> > for closed form mathematical expressions to be specified as string literals at
> > runtime and be evaluated.  For example:
> >
> > MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> > writeln(myExpression(2));  // Does exactly what you think it does.
> >
> > I've found the syntax so convenient that I'd like to transparently specialize
> > it on strings known at compile time.  The idea is that, when the expression is
> > hard-coded, you will still be able to use the MathExp interface, but your
> > expression will evaluate at the full speed of a statically compiled function.
> >   Is there any way to test whether the value of an argument to a template
> > function is known at compile time and specialize on this?
> Doesn't all values to a template have to be known at compile time

No, I mean the *function* parameters of a template function.
October 12, 2009
Re: Specializing on Compile Time Constants
dsimcha wrote:
> I'm working on a mathematical expression interpreter for D, which would allow
> for closed form mathematical expressions to be specified as string literals at
> runtime and be evaluated.  For example:
> 
> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> writeln(myExpression(2));  // Does exactly what you think it does.
> 
> I've found the syntax so convenient that I'd like to transparently specialize
> it on strings known at compile time.  The idea is that, when the expression is
> hard-coded, you will still be able to use the MathExp interface, but your
> expression will evaluate at the full speed of a statically compiled function.
>  Is there any way to test whether the value of an argument to a template
> function is known at compile time and specialize on this?

As an aside, I'd so use that if you allowed LaTeX math expressions.

Andrei
October 12, 2009
Re: Specializing on Compile Time Constants
On 10/12/09 23:55, dsimcha wrote:
> == Quote from Jacob Carlborg (doob@me.com)'s article
>> On 10/12/09 23:49, dsimcha wrote:
>>> I'm working on a mathematical expression interpreter for D, which would allow
>>> for closed form mathematical expressions to be specified as string literals at
>>> runtime and be evaluated.  For example:
>>>
>>> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
>>> writeln(myExpression(2));  // Does exactly what you think it does.
>>>
>>> I've found the syntax so convenient that I'd like to transparently specialize
>>> it on strings known at compile time.  The idea is that, when the expression is
>>> hard-coded, you will still be able to use the MathExp interface, but your
>>> expression will evaluate at the full speed of a statically compiled function.
>>>    Is there any way to test whether the value of an argument to a template
>>> function is known at compile time and specialize on this?
>> Doesn't all values to a template have to be known at compile time
>
> No, I mean the *function* parameters of a template function.

Can't you pass the values as template arguments? Seems you working with 
strings (and numbers?). mathExp!("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x"); 
Note the ! after the function name.
October 12, 2009
Re: Specializing on Compile Time Constants
== Quote from Jacob Carlborg (doob@me.com)'s article
> On 10/12/09 23:55, dsimcha wrote:
> > == Quote from Jacob Carlborg (doob@me.com)'s article
> >> On 10/12/09 23:49, dsimcha wrote:
> >>> I'm working on a mathematical expression interpreter for D, which would allow
> >>> for closed form mathematical expressions to be specified as string literals at
> >>> runtime and be evaluated.  For example:
> >>>
> >>> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> >>> writeln(myExpression(2));  // Does exactly what you think it does.
> >>>
> >>> I've found the syntax so convenient that I'd like to transparently specialize
> >>> it on strings known at compile time.  The idea is that, when the expression is
> >>> hard-coded, you will still be able to use the MathExp interface, but your
> >>> expression will evaluate at the full speed of a statically compiled function.
> >>>    Is there any way to test whether the value of an argument to a template
> >>> function is known at compile time and specialize on this?
> >> Doesn't all values to a template have to be known at compile time
> >
> > No, I mean the *function* parameters of a template function.
> Can't you pass the values as template arguments? Seems you working with
> strings (and numbers?). mathExp!("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> Note the ! after the function name.

This would work, but it's a bit kludgey because it requires the user to explicitly
specify that the string is known at compile time.  I was wondering if this could
be done transparently.
October 12, 2009
Re: Specializing on Compile Time Constants
dsimcha:

>  Is there any way to test whether the value of an argument to a template
> function is known at compile time and specialize on this?

Do you mean this?
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=97424

Bye,
bearophile
October 13, 2009
Re: Specializing on Compile Time Constants
dsimcha wrote:
> == Quote from Jacob Carlborg (doob@me.com)'s article
>> On 10/12/09 23:49, dsimcha wrote:
>>> I'm working on a mathematical expression interpreter for D, which would allow
>>> for closed form mathematical expressions to be specified as string literals at
>>> runtime and be evaluated.  For example:
>>>
>>> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
>>> writeln(myExpression(2));  // Does exactly what you think it does.
>>>
>>> I've found the syntax so convenient that I'd like to transparently specialize
>>> it on strings known at compile time.  The idea is that, when the expression is
>>> hard-coded, you will still be able to use the MathExp interface, but your
>>> expression will evaluate at the full speed of a statically compiled function.
>>>   Is there any way to test whether the value of an argument to a template
>>> function is known at compile time and specialize on this?
>> Doesn't all values to a template have to be known at compile time
> 
> No, I mean the *function* parameters of a template function.


I may be wrong, but I seem to remember reading somewhere that DMD always 
tries to evaluate as much as possible at compile time. That is, if a 
function is CTFE-enabled, and its input is known at compile time, it is 
calculated at compile time.

    void main(string[] args) {
        auto x = foo(args[1]);  // foo() is evaluated at run time
        auto y = bar("baz");    // foo() is evaluated at compile time
    }

That said, I also seem to remember that the use of structs and classes 
is very limited (or nonexistent) in CTFE, and I guess your mathExp() is 
supposed to return a MathExp struct...

-Lars
October 13, 2009
Re: Specializing on Compile Time Constants
dsimcha wrote:
> I'm working on a mathematical expression interpreter for D, which would allow
> for closed form mathematical expressions to be specified as string literals at
> runtime and be evaluated.  For example:
> 
> MathExp myExpression = mathExp("x^2 + e^cos(-x) - 2 * sqrt(pi)", "x");
> writeln(myExpression(2));  // Does exactly what you think it does.
> 
> I've found the syntax so convenient that I'd like to transparently specialize
> it on strings known at compile time.  The idea is that, when the expression is
> hard-coded, you will still be able to use the MathExp interface, but your
> expression will evaluate at the full speed of a statically compiled function.


This is *so* cool. :)

-Lars
October 13, 2009
Re: Specializing on Compile Time Constants
On 2009-10-13 09:11:08 +0200, "Lars T. Kyllingstad" 
<public@kyllingen.NOSPAMnet> said:

> I may be wrong, but I seem to remember reading somewhere that DMD 
> always tries to evaluate as much as possible at compile time. That is, 
> if a function is CTFE-enabled, and its input is known at compile time, 
> it is calculated at compile time.
> 
>      void main(string[] args) {
>          auto x = foo(args[1]);  // foo() is evaluated at run time
>          auto y = bar("baz");    // foo() is evaluated at compile time
>      }

you are wrong, compile time evaluation is not performed if not 
requested (by making that constant for example).
The compiler cannot know the complexity of the calculation, and making 
it at compile time is much slower...
thus you have to explicitly instruct the computer to do it...
Top | Discussion index | About this forum | D home