|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
>> Anyway, my request isn't based on how easy or hard it would be to
>> implement,
>> but rather on how useful it would be to me. In the past year, I've run
>> across more and more situations where I would want this.
>>
>>
>
> Name some. Maybe we don't need an eval()-like function, what we need is
> other features so that we never ever need to use eval.
In my case I was using POV-Ray as a graphing calculator and wanted the
resultant image to show both the text and graphic form of the function.
I wanted to only have to enter a function in SDL once, so I used a
string, and figured out the include-file-method as a workaround to
convert that string to something plot-able. I asked on the newsgroups
if there was a better way... wishing.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Nicolas Alvarez wrote:
>>
>> Name some. Maybe we don't need an eval()-like function, what we need
>> is other features so that we never ever need to use eval.
>
> In my case I was using POV-Ray as a graphing calculator and wanted the
> resultant image to show both the text and graphic form of the function.
> I wanted to only have to enter a function in SDL once, so I used a
> string, and figured out the include-file-method as a workaround to
> convert that string to something plot-able. I asked on the newsgroups
> if there was a better way... wishing.
> Charles
#declare F = function { x*2 };
#declare Ftext = f.toString(); // <-- that's probably the feature you need
Or a way to convert a string to a function; note that's still not an
eval(), as it would be limited to only mathematical expressions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C <"nospam a nospam.com"> wrote:
> I wanted to only have to enter a function in SDL once, so I used a
> string, and figured out the include-file-method as a workaround to
> convert that string to something plot-able. I asked on the newsgroups
> if there was a better way... wishing.
I wouldn't say that's the best possible usage for an eval() function...
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> #declare F = function { x*2 };
> #declare Ftext = f.toString(); // <-- that's probably the feature you need
That wouldn't preserve the exact original representation (because
functions are byte-coded, thus dropping the original function string
completely).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Name some. Maybe we don't need an eval()-like function, what we need is
> other features so that we never ever need to use eval.
I want to tie various strings together using concat() and then evaluate it.
This is certainly possible by writing to temporary include files, but it
would be simpler (and easier) for the artist to simply call parse (eval is
already a keyword).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Charles C <"nospam a nospam.com"> wrote:
>> I wanted to only have to enter a function in SDL once, so I used a
>> string, and figured out the include-file-method as a workaround to
>> convert that string to something plot-able. I asked on the newsgroups
>> if there was a better way... wishing.
>
> I wouldn't say that's the best possible usage for an eval() function...
I don't understand your meaning. I'd guess that somebody might say that
fishing is not the best possible use of fishing line but if somebody
actually said that I'd say it begs the question what they thought would
be a better use. Anyway, I think Ben was suggesting a general ability
to parse strings, not specifically evaluate an expression. I was giving
an example where I wanted to use the same data in two disparate ways and
found a clumsy way to avoid cut/pasting. I think it would be great if
strings could be treated almost as if they were include files in memory,
with their own name-space locality etc. You couldn't #include
StringIdentifier because then you'd be including a file by that name,
but #parse works for me...
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C <"nospam a nospam.com"> wrote:
> Warp wrote:
> > Charles C <"nospam a nospam.com"> wrote:
> >> I wanted to only have to enter a function in SDL once, so I used a
> >> string, and figured out the include-file-method as a workaround to
> >> convert that string to something plot-able. I asked on the newsgroups
> >> if there was a better way... wishing.
> >
> > I wouldn't say that's the best possible usage for an eval() function...
> I don't understand your meaning.
That if the only rational use for eval() is so that you can display a
function as a string besides evaluating it, that's not reason enough to
make the parser 10 times more complicated just get an eval() function.
> I think it would be great if
> strings could be treated almost as if they were include files in memory,
All kinds of things would be nice, but a different story is how easy
it is to implement.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Charles C <"nospam a nospam.com"> wrote:
>> Warp wrote:
>>> Charles C <"nospam a nospam.com"> wrote:
>>>> I wanted to only have to enter a function in SDL once, so I used a
>>>> string, and figured out the include-file-method as a workaround to
>>>> convert that string to something plot-able. I asked on the newsgroups
>>>> if there was a better way... wishing.
>>> I wouldn't say that's the best possible usage for an eval() function...
>
>> I don't understand your meaning.
>
> That if the only rational use for eval() is so that you can display a
> function as a string besides evaluating it, that's not reason enough to
> make the parser 10 times more complicated just get an eval() function.
Understood. Agreed. It's probably not worth it just for a single
uncommon situation if it makes the parser 10 times more complicated.*
But maybe it's not the only rational reason, and that's what the
discussion is for. I was contributing *a* reason. I didn't mean for my
reason as a stand-alone justification for a massive effort.
*I think prioritization can be measured in three dimensions: time
urgency, importance or benefit, and ease of implementation or cost.
<stands on soap box>
All ideas are worth considering, generally**, no matter how silly, but
some can be ruled out earlier than others depending on cost and benefit.
Maybe this is one of those earlier ones. In terms of POV-Ray features
if enough people want a feature, then at some point it becomes worth
considering more seriously. Even if the benefit is low and the cost is
high, people who believe there is a benefit should still chime in and
say so or we'll never really know how many people it'll help or what
different uses it might have.
**If for example you're dealing with an emergency situation I'd say go
deal with that first.
>
>> I think it would be great if
>> strings could be treated almost as if they were include files in memory,
>
> All kinds of things would be nice, but a different story is how easy
> it is to implement.
>
Very true. You don't think it would be worth it for this one. Still,
it doesn't hurt to talk about it to see what different people think -
Float an idea and if it's not good, chances are it'll drift away. :-)
My 2c
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 26.10.2007 17:32, Chambers nous fit lire :
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Name some. Maybe we don't need an eval()-like function, what we need is
>> other features so that we never ever need to use eval.
>
> I want to tie various strings together using concat() and then evaluate it.
>
> This is certainly possible by writing to temporary include files, but it
> would be simpler (and easier) for the artist to simply call parse (eval is
> already a keyword).
>
>
What about, then, having 'parse(str)' as a macro (or something else
?) which:
1/ create a temp file named automatically
2/ write str in the file
3/ close the temp file
4/ include the temp file
Please note, that with current implementation of #macro (and because
str might contains such), you cannot remove the temp file before the
end of the parsing.
It's a kludge, you will need a file-garbage-collector by the end of
parsing time, but it should be rather easy with the current parser.
--
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Le 26.10.2007 17:32, Chambers nous fit lire :
>> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>>> Name some. Maybe we don't need an eval()-like function, what we need is
>>> other features so that we never ever need to use eval.
>> I want to tie various strings together using concat() and then evaluate it.
>>
>> This is certainly possible by writing to temporary include files, but it
>> would be simpler (and easier) for the artist to simply call parse (eval is
>> already a keyword).
>>
>>
> What about, then, having 'parse(str)' as a macro (or something else
> ?) which:
> 1/ create a temp file named automatically
> 2/ write str in the file
> 3/ close the temp file
> 4/ include the temp file
>
It already exists on the standard include file strings.inc, called
Parse_String.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |