Dear All,
Can I bother you second, it seems that Proc Gchart might produce wrong output if we choose to sort by descending values.
1. Correct output by ascending value as below:
2. Incorrect output by descending values as below:
The source code as such:
%let Stock_cd = IF1304;
ods listing;
filename grafout "C:\Temp\jbs_desc.gif";
goptions reset=all
device=gif
gsfname=grafout
gsfmode=replace;
GOPTIONS xpixels=400 ypixels=300;
GOPTIONS COLORS = (BLUE, BLUE, CYAN, CXD2477C, Green, Red);
Legend1
FRAME
POSITION = (BOTTOM CENTER OUTSIDE);
Axis1
STYLE=1
WIDTH=1
LABEL=( "Current Price" )
;
Axis2
STYLE=1
WIDTH=1
MINOR=
(NUMBER=1
)
;
TITLE;
TITLE1 h=2 "&Stock_cd. Price Distribution Analysis" -2D. ;
FOOTNOTE;
PROC GCHART DATA=Interest.Sample2 gout=work.gseg;
HBAR Current_Price
/ SUMVAR=Trans_Amount
CLIPREF
DESCENDING
FRAME SUM /* NOSTATS */
TYPE=SUM
LEGEND=LEGEND1
COUTLINE=BLACK
MAXIS=AXIS1
RAXIS=AXIS2
LREF=34
CREF=BLUE
/* AUTOREF */
CTEXT=BLACK
CAXIS=BLACK
;
RUN; QUIT;
Thank you in advance for your time!
Best Regards,
Yuanbin
- and part of those raw data:
Current_Price group Trans_Amount
2584 B 78
2593.4 B 130
2594.6 B 26
2594.6
2594.6 B 26
2594.6 -26
2593.2 26
2592.8 52
2592.2 S -26
2592.8
2592.8
2592
2592.8 B 26
2592.8
2592.8
2593.2
2593.6 B 26
2592.8 S -26
2593
2593 B 26
2592.8
2592.8
2594
2593.8
2593.8 S -26
2593.8
2594.4
2594.4 -52
2603.2 S -26
2604.6
2603.8 26
2604.4 -26
2603.8
2603.4
2604.6 -26
2604.6 S -26
2603.8 S -26
2603.4 26
2603
2604
2603.2
2602.8
2601.8 B 26
2602.2 -26
2601.8
2601.2 B 26
2601 52
2600.8 S -26
2689.6 27
2690.2 -27
2690.2 27
2690.6
2690.6 S -27
2691.2 -27
2691.2 27
2691
2691.8
2691.8
2692
2691.8
2691.8
2691.8
2691.8 S -27
2691.8 S -27
2691.8
2691.4 -27
2690.8
2691.4 -54
2691.6 27
2692
2691.6 377
2691.2
2691.2 27
The ASCENDING/DESCENDING options to the HBAR (and other GCHART statements) specifies a sort order based on the statical values/measures, so no, it's not a bug.
Ordering for midpoint/class variables can be specified on the AXIS statements.
The ASCENDING/DESCENDING options to the HBAR (and other GCHART statements) specifies a sort order based on the statical values/measures, so no, it's not a bug.
Ordering for midpoint/class variables can be specified on the AXIS statements.
Hi LinusH,
I appreicated it very much for your time, it really help!
after I add option of ORDER=(2700 to 2580 by -4 ), the chart looks good:
it's wonderful! by the way, do you know how to apply for a default value for the step-length in the value-list? for example here as of 'by -4', otherwise, I have to define them in source code, If I ignore it, for example, 'ORDER=(2700 to 2580 ), it will order by ascending again?! Do you have any advice, or would you help to show me more in details? Thanks in advance!
It was some time since I did GCHART...
I don't think there is a default value for stepping. If you omit it, does your ?! it does ascending...?
You could have macro variable with your default stepping, and always specify it in your AXIS...
May not help as much, I think you be better off dig into the documentation and test different approaches yourself...
L
After took more look into the output of gchart, it seems there is an automatical stepping algorithm which displays with different step size, as a result the chart of bar looks better and continuously display as well.
Thanks a lot for the userful information!
Yuanbin
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9. Sign up by March 14 for just $795.
Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.