applying value correction which linearly depends on parameter

[Patrick Ohly-2]

Hello,

I have a graph with offset "o" = f(time "t"). I can plot o as result
with t as parameter, but what I need instead is
  o' = f(t) - ( offset + scale * t)

I tried to formulate this "offset + scale * t" as:

  <source id="src.offset">
    <result>time_offset</result>
    <input>p.time</input>
  </source>

  <source id="src.basetime" scale="f.scale">
    <result>p.time</result>
    <input>p.time</input>
  </source>

  <operator id="op.basetime" type="offset" value="f.offset">
    <input>src.basetime</input>
  </operator>

  <operator id="op.scaled" type="diff">
    <input>src.offset</input>
    <input>op.basetime</input>
  </operator>

but this already fails for src.basetime:

Traceback (most recent call last):
  File "/Projects/software/perfbase/bin/pb_query.py", line 723, in ?
    main()
  File "/Projects/software/perfbase/bin/pb_query.py", line 672, in main
    data_outputs = parse_query_spec()
  File "/Projects/software/perfbase/bin/pb_query.py", line 618, in parse_query_spec
    init_query_objects(obj_id, qryobj_dag)
  File "/Projects/software/perfbase/bin/pb_query.py", line 491, in init_query_objects
    init_query_objects(obj.childs[idx], qryobj_dag)
  File "/Projects/software/perfbase/bin/pb_query.py", line 491, in init_query_objects
    init_query_objects(obj.childs[idx], qryobj_dag)
  File "/Projects/software/perfbase/bin/pb_query.py", line 491, in init_query_objects
    init_query_objects(obj.childs[idx], qryobj_dag)
  File "/Projects/software/perfbase/bin/pb_query.py", line 494, in init_query_objects
    eval("init_"+obj.xml.tag)(obj.xml)
  File "/Projects/software/perfbase/bin/pb_query.py", line 274, in init_source
    s = source(xml_node, all_nodes, exp_db)
  File "/Projects/software/perfbase.trunk/bin/pb_source.py", line 295, in __init__
    r_name = all_nodes[r.text].get_content()

My guess is that values declared as parameters in the experiment cannot
be selected as results in a query, but I haven't checked the source to
verify this. Correct? If so, would it be very difficult to change this?

Once I get beyond that hurdle, my next problem might be that the t
parameter is a "timeofday" value whereas "o" is a "float" because I
found "timeofday" too inaccurate for the small offsets that I wanted to
store - I'm not sure yet how the "timeofday" to "float" seconds would be
handled.

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joachim Worringen-4]

Patrick Ohly schrieb:
> My guess is that values declared as parameters in the experiment cannot
> be selected as results in a query, but I haven't checked the source to
> verify this. Correct? If so, would it be very difficult to change this?

Yes, this is correct. I don't think it would be difficult to change, but
I have no clear picture on the possible implications to the design.

> Once I get beyond that hurdle, my next problem might be that the t
> parameter is a "timeofday" value whereas "o" is a "float" because I
> found "timeofday" too inaccurate for the small offsets that I wanted to
> store - I'm not sure yet how the "timeofday" to "float" seconds would be
> handled.

In any case, have a look at the "eval" operator - see test/eval.
Generally, combining int with float should not be a problem.

  Joachim

--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Patrick Ohly-2]

On Fri, 2007-03-16 at 12:47 +0100, Joachim Worringen wrote:
> Patrick Ohly schrieb:
> > Once I get beyond that hurdle, my next problem might be that the t
> > parameter is a "timeofday" value whereas "o" is a "float" because I
> > found "timeofday" too inaccurate for the small offsets that I wanted to
> > store - I'm not sure yet how the "timeofday" to "float" seconds would be
> > handled.
>
> In any case, have a look at the "eval" operator - see test/eval.

Good point, that does what I need.

> Generally, combining int with float should not be a problem.

Unfortunately time is neither of these. As I feared I get a problem
during evaluation (not quite the final formula, just a simple
difference):

  File "/Projects/software/perfbase.trunk/bin/pb_operators.py", line 3137, in _calculate
    print "#* DEBUG: <operator> %s eval(): %s = %s" % (self.name, estr, str(eval(estr)))
  File "<string>", line 1
    (0.00013609)-(09:05:07.00)

So what I miss now is an operation which converts from time to seconds :-/

--
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joachim Worringen-4]

Patrick Ohly schrieb:

> Unfortunately time is neither of these. As I feared I get a problem
> during evaluation (not quite the final formula, just a simple
> difference):
>
>   File "/Projects/software/perfbase.trunk/bin/pb_operators.py", line 3137, in _calculate
>     print "#* DEBUG: <operator> %s eval(): %s = %s" % (self.name, estr, str(eval(estr)))
>   File "<string>", line 1
>     (0.00013609)-(09:05:07.00)
>
> So what I miss now is an operation which converts from time to seconds :-/

The solution that I see is a new specific operator of type "convert"
with value="s" in this case. This operator would be placed to treat the
timeval-data vector just before the eval operator. Should not be
difficult to implement; the problem will be to define its semantics in a
way that is generic and precise at the same time.

  Joachim

--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Patrick Ohly-2]

On Fri, 2007-03-16 at 13:24 +0100, Joachim Worringen wrote:

> Patrick Ohly schrieb:
> > Unfortunately time is neither of these. As I feared I get a problem
> > during evaluation (not quite the final formula, just a simple
> > difference):
> >
> >   File "/Projects/software/perfbase.trunk/bin/pb_operators.py", line 3137, in _calculate
> >     print "#* DEBUG: <operator> %s eval(): %s = %s" % (self.name, estr, str(eval(estr)))
> >   File "<string>", line 1
> >     (0.00013609)-(09:05:07.00)
> >
> > So what I miss now is an operation which converts from time to seconds :-/
>
> The solution that I see is a new specific operator of type "convert"
> with value="s" in this case. This operator would be placed to treat the
> timeval-data vector just before the eval operator. Should not be
> difficult to implement; the problem will be to define its semantics in a
> way that is generic and precise at the same time.

Perhaps let the user specify a Python fragment which defines a function,
then apply that function on the parameters specified in such a new
<python> <term>?

--
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Software & Solutions Group                
Hermuelheimer Strasse 8a                  Phone: [phone]
50321 Bruehl                              Fax: [phone]
Germany

Intel GmbH, Dornacher Strasse 1, 85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456
Ust.- IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Joachim Worringen-4]

Patrick Ohly schrieb:
> Perhaps let the user specify a Python fragment which defines a function,
> then apply that function on the parameters specified in such a new
> <python> <term>?

Yes, this sounds good. You mean within the eval-operator, I assume?

  Joachim

--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Patrick Ohly-2]

On Fri, 2007-03-16 at 14:03 +0100, Joachim Worringen wrote:
> Patrick Ohly schrieb:
> > Perhaps let the user specify a Python fragment which defines a function,
> > then apply that function on the parameters specified in such a new
> > <python> <term>?
>
> Yes, this sounds good. You mean within the eval-operator, I assume?

Yes, right. You'll probably have to compile/evaluate the function
definition with a separate globals and locals context first and then
reuse it for each eval(), otherwise the user would be limited to simple
one-line python expressions and performance would be worse.

--
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Software & Solutions Group                
Hermuelheimer Strasse 8a                  Phone: [phone]
50321 Bruehl                              Fax: [phone]
Germany

Intel GmbH, Dornacher Strasse 1, 85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456
Ust.- IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...