Re: Time formats [was Re: Feature request - assignment in expressions]

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

Hi again,

just found a bit of time to have another look at this. A couple of small=
  =

probs, one with assign() , the other with strptime you suggested I look =
at.

On Tue, 08 May 2007 20:01:06 +0200, Ethan Merritt  =

<merritt@u.washington.edu> wrote:

> On Tuesday 08 May 2007 09:43, Juergen Wieferink wrote:
>>
>> > I have never understood the time-handling code.  I suspect that the=

>> > whole special case time format mechanism is no longer needed, as th=
e  =

>> same
>> > goal can be achieved using general string-handling functions.
>> > In your case, you probably need to use some combination of  =

>> stringcolumn()
>> > strptime() strftime() rather than setting a time format.
>>

I tried using strptime with the same time format that works with my data=
  =

but found I had to divide by 3600 just to get it on the plot. However it=
  =

did get around the trucation to the nearest hour I was seeing when passi=
ng  =

the result of timecolumn().

So it seems that strptime() does not always parse the data in the same w=
ay  =

as with timefmt as the help suggests.

It seems that this time feature has been somewhat tacked on to fullfil  =

requests for this format but that it has not been implement, or at least=
  =

implemented in the same way through out.

If you are working on the code to deal with this in a more structured wa=
y  =

I think that would be very benefitial, current behavious seems to vary  =

somewhat depending on where and how time format is used.



>> I don't think so.  I see two problems (probably there are more):
>> * Automatic tic generation is date/time aware.  This could be
>>   adjusted manually, but the automatic tics wouldn't be too sensible.=

>
> Could be.  As I said, I am not familiar with the time format options.
>
>> * Tic label generation.  The command "set format" just takes a
>>   format string, which is used either for date/time or ordinary
>>   numbers.  The functions strptime() and strftime() only work with a
>>   more flexible "set format" which takes a string valued expression, =
 =

>> which
>>   is evaluated at plot time.
>
> Sure.  But that could be a useful addition in its own right.
> I didn't mean to say that the time format options could be deprecated
> with no additional work; I just meant that the basic pieces are in pla=
ce
> to replace them with a more general mechanism.
>
> Don't forget that we have several long-standing requests to extend
> the time format system so that it can handle intervals smaller than
> a second, and also to allow it to handle spherical coordinate systems
> deg/min/sec/fractional-sec
>
> One could write a lot of special-purpose code to handle these
> extensions, but I would rather see the effort spent on implementing
> a generic mechanism of which the existing time formats and the
> proposed geographic variants are just user-configurable examples.
>
>

My other problem is that the code snip I posted seems to be correctly  =

calculating the areas of the increamental trapezoidal segements but fail=
s  =

to add the existing value of my area variable.


area=3D0; started=3D0;prev_x=3D0;prev_y=3D0;
add_aug(x,y)=3Dassign("area",(started)?\
                                      area + (x-prev_x)*(y-prev_y)/2.0  =

+ 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) \
                                     :( 0.0*assign("started",1)  =

+ 0.0*assign("prev_x",x) + 0.0*assign("prev_y",y) ) \
                    );


plot  datafile   using  =

1:(add_aug(strptime("%H:%M",stringcolumn(1))/3600*2,P( Th4($3-2.0)   =

-(Th7($5)-0.52) ))) axes x1y2  with lines s f t "aug" \



So referencing area inside assign("area", ) seems to return zero, wherea=
s  =

the other calls to assign() work and references to the other variables  =

inside assign() produces expected results.

Can you confirm that bug and hopefully correct it?

Many thanks.