Wondering about something, having to do with strings and how they are handled by
an #if block.

In v.3.6.1c, trying to do this doesn't work:

#declare my_string = "abc" // with semi-colon or without
#if(my_string = "abc")
....do something
#else
#end

It produces a fatal error at the #if line, "Expected 'numeric expression',
string identifier found instead"

Some recent code posted by Edouard (his "DF3 Proximity Testbed")--meant for use
with one of the 3.7 betas, I *think*--makes use of this kind of construct, which
apparently does work now. (I'm just guessing; I only attempted to run part of
his code in 3.6.1, which produced the same error. Silly to do, I know; but I
like to experiment!)

So a question, just out of curiosity: *Has* string handling been improved since
3.6.1, to successfully process this kind of thing? I haven't yet been able to
find any info about it, when doing a search of the newsgroups.

Ken

Post a reply to this message

Am 10.05.2010 15:12, schrieb Kenneth:

> So a question, just out of curiosity: *Has* string handling been improved since
> 3.6.1, to successfully process this kind of thing? I haven't yet been able to
> find any info about it, when doing a search of the newsgroups.

Yup - quote from the change log on <http://www.povray.org/beta/>:

 >> -------------------------------------------
 >> Changes between 3.7.beta.22 and 3.7.beta.23
 >> -------------------------------------------
 >>
 >> ...
 >> Added comparison ('=', '!=', '<', '<=', '>', '>=') support for strings.

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> So a question, just out of curiosity: *Has* string handling been improved since
> 3.6.1, to successfully process this kind of thing? I haven't yet been able to
> find any info about it, when doing a search of the newsgroups.

  See changes for 3.7.beta.23 in the change log here: http://povray.org/beta/

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Yup - quote from the change log on <http://www.povray.org/beta/>:

>  >> -------------------------------------------
>  >> Changes between 3.7.beta.22 and 3.7.beta.23
>  >> -------------------------------------------
>  >>
>  >> ...
>  >> Added comparison ('=', '!=', '<', '<=', '>', '>=') support for strings.

  Btw, back then I also tried to add support for string concatenation using
operator + so that you could write

    "value=" + str(value,0,-1) + "\n"

instead of having to write

    concat("value=", str(value,0,-1), "\n"))

but I hit a wall because of how the parsing works. A straightforward
implementation might sound trivial for anybody who has programmed for the
parser code, but there are surprising pitfalls. If you try to support string
concatenation by using the + operator, you end up having SDL like this:

    #debug "Hello\n"
    #debug "there!\n"

print out:

    there!
    Hello

  The reason for this might not be immediately obvious, but should be so
for people who know how the parser works, when pointed out like this. It
has to do with how the parser interprets #-commands while it's scanning
for the next token (iow. in this case checking if a '+' token follows the
string after the first #debug). And no, turning off the #-command
interpretation during the check doesn't work because then you end up in
a situation where you pull out a #-token, after which you have broken the
'#debug' into two tokens, after which you end up with a parsing error about
a lone '#' having been found.

  The problem is not trivial to solve with the current parser. On the other
hand, by far the most common place where people need string concatenation is
with #debug, so I thought of an alternative solution to make printing messages
easier, something like:

    #print "value=", value, "\n";

  The #print-command would take comma-separated elements and smartly interpret
them according to their type (ie. if it's a string, it just prints it, if
it's a numerical identifier it prints it with default accuracy, if it's a
vector, it prints with default accuracy and delimiters, etc.)

  Never got past the planning stages, though (although the team's opinion on
that suggestion was positive). However, there's still time to add it if
someone is willing to make some minor development.

-- 
                                                          - Warp

Post a reply to this message

On 05/10/2010 11:00 AM, Warp wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
>> So a question, just out of curiosity: *Has* string handling been improved since
>> 3.6.1, to successfully process this kind of thing? I haven't yet been able to
>> find any info about it, when doing a search of the newsgroups.
> 
>   See changes for 3.7.beta.23 in the change log here: http://povray.org/beta/
> 
the change even made it into the wiki docs as well:

http://wiki.povray.org/content/Documentation:Reference_Section_2.3#String_Relational_Operators

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> find any info about it, when doing a search of the newsgroups.
>
>   See changes for 3.7.beta.23 in the change log here: http://povray.org/beta/

Good news! Thanks, to all who posted.

I have some old code that will make great use of this handy feature.

Ken

Post a reply to this message

Jim Holsenback <jho### [at] povrayorg> wrote:

> the change even made it into the wiki docs as well...

Thanks!

BTW, I think the wiki there has a slight error, in its example.  Here's what's
written...

#declare TestCase = "Testing"; // Shouldn't this be "Testing123"?
#if (TestCase < "Testing123")

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> Thanks!
>
> BTW, I think the wiki there has a slight error, in its example.  Here's what's
> written...
>
> #declare TestCase = "Testing"; // Shouldn't this be "Testing123"?
> #if (TestCase < "Testing123")
>

Oops, I think I see my own error (I *think*.) Given the way this example is
written in the wiki, is the #if comparing the NUMBER of letters in TestCase
("testing" = 7) to those of "Testing123" (10)?

Ken

Post a reply to this message

On 05/10/2010 01:53 PM, Kenneth wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:

> Oops, I think I see my own error (I *think*.) Given the way this example is
> written in the wiki, is the #if comparing the NUMBER of letters in TestCase
> ("testing" = 7) to those of "Testing123" (10)?

nope ... i believe the evaluation is done in lexicographical order ie:
testinf would be less than testing

Jim

Post a reply to this message

> On 05/10/2010 01:53 PM, Kenneth wrote:
>> "Kenneth"<kdw### [at] earthlinknet>  wrote:
>
>> Oops, I think I see my own error (I *think*.) Given the way this example is
>> written in the wiki, is the #if comparing the NUMBER of letters in TestCase
>> ("testing" = 7) to those of "Testing123" (10)?
>
> nope ... i believe the evaluation is done in lexicographical order ie:
> testinf would be less than testing
>
> Jim
>

It does a loop and test each characters in turn. The first pair of 
missmatching will trigger the condition. A successfull test for equality 
is the longest, or if only the last character is different, as you had 
to compare every characters.

"a"<"b"
"Z"<"a" as uppercase come before lower case
"a"<"aa" second "a" is compares to NULL
"b">"aa" The second "a" is ignored as the first characters are different.


Alain

Post a reply to this message