Re: Plans for gnuplot version 5 - typecasting

[<pl...@pi...>]

On 03/07/14 21:23, Ethan A Merritt wrote:
> On Friday, 07 March, 2014 12:05:27 Ethan A Merritt wrote:
>> ere is one way to do it.  This may not cover all the desired cases:
>>
>> gnuplot>  argb(a,r,g,b) = sprintf("0x%.2x%.2x%.2x%.2x",a,r,g,b)
>> gnuplot> print argb(0x78,0,0,0)
>> 0x78000000
>> gnuplot> print argb(0xff, 0, 255, 127.0)
>> 0xff00ff7f
>>
>> Yes that produces a string rather than an integer, but the plotting commands
>> are happy to take the string.
>
>
> Correction.  If you want to pass that directly to a plot command you
> currently need to modify it to
>
> gnuplot>  argb(a,r,g,b) = sprintf("#%.2x%.2x%.2x%.2x",a,r,g,b)
>
> The first form generates a valid hexadecimal constant but the
> color code will only parse it that way if passed as a bare integer,
> not in a string constant.  So this works:
>      plot x lc rgb 0xff00ff7f
> But this doesn't
>      plot x lc rgb "0xff00ff7f"
>
> That's fixable.
>
> 	Ethan
>
>

Ethan, this touches on something that I often get hit with when trying 
to generalise to plot some kind of iteration. The problem is how to 
compose a filename, line type specifier, label id or some such element 
composed from the an iteration variable and/or gnuplot constants.

Often it will involve string concatenation or a sprintf() result but as 
we see here, a string result may not be acceptable to the parser.

Now you could tweak the code to accept both integer and string , which 
seems to be what you mean by  "That's fixable." However, wouldn't it be 
a much more far reaching fix to have some kind of typecasting ability?

The fundamental problem here is automatic type magic does not always 
give the desired or required variable type and the parser spits it out. 
Indeed it's often pretty difficult for someone to does not have a 
detailed knowledge of the code to determine what the type of the result 
is going to be.


Type-casting is the classic solution to that kind of problem and 
presumably would not be that difficult of disruptive to introduce.


In that context this may not be v5 issue, but I'll let you judge the 
implications.

/Peter.