by RonPurewal Wed Jun 12, 2013 12:22 am
hey,
it's generally not a good idea to graph stuff like this. first, the graph is going to be super weird, because the function is made by piecing together a whole bunch of little bits of other functions. second, as if that weren't bad enough, even if you do succeed in making a graph it's not necessarily going to be obvious how to interpret the weird absolute-value conditions i, ii, iii. so, meh.
(in general, graphing functions is VERY unimportant on the gmat, with only one exception: functions whose graphs are straight lines.)
you also can't substitute algebraically very easily.
(you can substitute algebraically, but, for each roman numeral, you'd have to do two different substitutions: one for cases in which x > 0, and the other for cases in which x < 0, corresponding to the two different parts of how F is defined. and then you'd still have to contend with absolute values.)
so, that leaves testing cases.
in general, when you test cases, you may find it helpful to make a table.
for the columns -- just start with what you're picking, and end with the target expression(s). then, if there are any significant intermediate steps, make columns for those, too, in between the start and the finish.
i'd also make a separate table for each of i, ii, iii. that may sound like a big time investment, but it isn't -- as long as you get moving.
so, for instance, let's just look at, say, (i).
i'd make the following columns:
x, |x|, F(|x|), F(x), |F(x)|.
then just throw in some different x's (use pos/neg/zero of course), and see whether the reddish and bluish things are always the same. if they are, then the statement is true. if they're ever different, the statement is false.
similarly for the other two statements.
by the way, the same technique is also a fantastic way to organize data sufficiency problems, too.
and tax spreadsheets if you sell stuff on the internet.