I'm needing to sort a graph by dd-hh24 but print hh12-am. GRAPHF would do nicely.

--wg

This message has been edited. Last edited by: Kerry,

GRAPFF = (FOC1517).
However, conside TABLEF to a HOLD file the GRAPH... Would that work for you? Something like thai:

TABLEF FILE MYFILE
SUM AMOUNT
BY HIGHEST 5 TIMESTAMP
ON TABLE HOLD
END
GRAPH FILE HOLD
SUM AMOUNT BY TIMESTAMP
END

Nope, won't do it. GRAPH FILE HOLD re-sorts.
I can sort the hold file and the TABLEF it picking the columns I want and it's perfect. But can't get that into GRAPH (without sort taking place).

I see some other techniques using REPEAT and setting GRAPH api statements, but that's more work than the whole project is worth.

GRAPHF FILE HOLD would be a perfect solution and easy.

Thanks Doug,
--wg

What do you mean by "GRAPH FILE HOLD re-sorts? You can GRAPH FILE your data in the same sort order as that which was used to create your HOLD file, can't you?

Can you provide sample code, data, or a MFD?

Doug,

Sorry, I'm not explaining myself....
Let say you want to graph col2 across col1
and col1 is numeric hours (01-24) and they repeat because col3 are days and there's more than 1 day in the data. So, I want it sorted by day, then by hour, but I'm only graphing hour (col1) and job counts (col2).... col3 is not in the graph file request. So, graph file using across (or by) resorts on the hours value.

--wg

Another FOCUS syntax would work, if it existed... that is (using my previou example):
GRAPH FILE FNAME
SUM col2 ACROSS col1
BY col3 NOPRINT
...
END
However, NOPRINT doesn't seem to work in GRAPH.

BTW, I've already resolved this using the repeat loop api stuff found on focal point.

The average webFOCUS user would not be able to do that.

--wg

try
BY DAY NOPRINT
ACROSS HOUR

This message has been edited. Last edited by: PBrightwell,

Pat,

I thought I had tried that, but did again anyway to make sure. It gets close but it makes a chart for each value and when grmerge is on, it doesn't put the hour value on (or below) the bar.

Thanks,
--wg

GRAPH can do it. You just need to change the format of the time-stamp sort variable.

I assume TIMESTAMP has a date-time Usage, for example HYYMDI.

-* pull specimen data ("length", at 2-hour intervals) from CAR
TABLE FILE CAR
  PRINT LENGTH 
COMPUTE
  SEQ/I5=SEQ+1;
  START/HYYMDI=DT(2009/08/01 16:00:00);
  TIMESTAMP/HMDYYI = HADD(START, 'HOUR', 2*SEQ, 12, TIMESTAMP);
ON TABLE HOLD
END

-* define a date-time field, with usage that hides the date information, to serve as the sort field.
-* the sort sequence will still respect the date
DEFINE FILE HOLD
  TIME/HHIa=TIMESTAMP;
END
GRAPH FILE HOLD
  SUM LENGTH
  ACROSS TIME
END

This message has been edited. Last edited by: j.gross,

no doug, you can't
GRAPH presents in alpha order unless you override with
COLUMNS command
GRAPH SALES BY COUNTRY
COLUMNS 'ITALY' AND 'FRANCE' AND 'ENGLAND' AND 'BURKINA FASO'

quote:

GRAPH presents...

To put it another way, GRAPH (like TABLE) arranged the data in an internal table per the sorting (BY / ACROSS) syntax in the request.

In the case of GRAPH, the BY and/or ACROSS syntax is required in order to specify the independent variable(s) for graphing the data.

As with TABLE, you can use COLUMNS ... to modify the ordering of the independent variable's data values, but the order of the incoming data records has no influence on the resulting graph produced.


If the sort variable only carries HHMM data, "BY timefield" will fold together records from corresponding hours of the several days, with or without use of "COLUMNS ..." syntax. A time-only display format (like HHM or Hha) is the way to go, if you want to string out the data as a single series and list only the Time (leaving the Dates implicit) on the axis.

This message has been edited. Last edited by: j.gross,

By "You can GRAPH FILE your data in the same sort order..." I meant that the data is in your hold file and can be sorted as required... Maybe I missed something... Anyway, It looks like you guys have it under control... But, GRAPHF would be kewl... Enjoy...

Kewl it might be, but radically different from TABLEF.

TABLEF was provided to address an efficiency issue: It enables one to bypass the sorting and accumulating into an "internal matrix" of the all data for the report, when the data are known to be pre-sorted conformably with the requested output sequence. TABLEF will ingest that data, and perform data reduction within sort breaks if so requested -- formatting and outputting each accumulated record as soon as a sort break (or EOF) occurs in the input record stream. As a consequence to its lack of an internal matrix, TABLEF does not (cannot) support report features that require more than one record's look-ahead or a full accumulation of data before emitting a line of the report: multiple verbs, NOSPLIT, ACROSS.

As a "side benefit", TABLEF can be (mis)used with input data that are not conformably sorted; it will allow any break in the sort-key column values to trigger a sort-break in the output format, without regard or concern as to whether the change in values is in the expected direction or the opposite direction. Not even a warning message.

But graphing is different from driving a line-printer. By its nature, graphing requires a pass through all the data before any output formatting takes place (e.g., the scale of a simple line graph or bar chart depends on the range of values along the axes), so GRAPHF would still have to form the internal matrix -- and hence would provide no benefit in terms of data-handling efficiency.

The only benefit from a GRAPHF feature would be in loading the internal matrix in an order that blindly follows that of the data source -- the side benefit of TABLEF noted above. But, given that the internal matrix is implemented as an internal Focus file (and the loading thereof as an internal Modify), loading the internal matrix in violation of its nominal sort-key order would be a new and quite different animal from the processing done by TABLEF (which has no internal matrix) and TABLE/GRAPH (which sort their incoming data in conformity with the declared sort keys and their specified ascending/descending sort order).


I suggest, instead, a New Feature for GRAPH, to allow an outer BY ... NOPRINT or ACROSS ... NOPRINT to have the expected effect: the visible BY or ACROSS values would provide the values along the labeled axis, but the non-print and printing sort-keys along that axis together would determine the order in which the values are arranged on the axis (exactly like the behavior of TABLE). That would serve the reporting need, and more likely be deemed by product management as worthwhile in terms of the implementation effort vs. benefit to developers.

This message has been edited. Last edited by: j.gross,

Jack,

Thanks for your excellent (and thorough) explanation.

Based on your information, I'll settle for the BY or ACROSS NOPRINT feature.

When can I expect that? ....Just kiddin'

Thanks,
--wg

I totally agree, Jack, that GRAPHF would be radically different. And, like WG said: "I'll settle for the BY or ACROSS NOPRINT feature." as well...

So, when can WE expect that?

quote:

a New Feature for GRAPH, to allow an outer BY ... NOPRINT or ACROSS ... NOPRINT

Works Great, has for quite a while.

 GRAPH FILE CAR
SUM RETAIL_COST
BY COUNTRY NOPRINT
BY MODEL
ON GRAPH PCHOLD FORMAT PNG
ON GRAPH SET GRAPHDEFAULT OFF
ON GRAPH SET LOOKGRAPH VBAR
ON GRAPH SET GRMERGE ADVANCED
ON GRAPH SET GRMULTIGRAPH 0
ON GRAPH SET GRXAXIS 2
ON GRAPH SET GRAPHSTYLE *
setPlace(true);
setPlaceSkip(getO1Label(),0);
setTextRotation(getO1Label(),1);
ENDSTYLE
END

Maybe with BY, but not with ACROSS.

If you change BY to ACROSS in your example, the bar label values displayed reflect Country rather than Model.