Suppose I want a cell to show TRUE or FALSE according to whether the contents of another cell begins with the word "FIX". Seems straightforward:
="FIX*" = G9
but it doesn't work -- it always returns FALSE. COUNTIF works, though:
=COUNTIF(E, "=FIX*")
Any straightforward way to make the simple comparison? Any reasonable workarounds?
iWork '09-OTHER
Do you know that iWork Formulas and Functions User Guide is available for free to teach us the behavior of functions.
For instance, it give the list of functions accepting wildcards.
So, open the PDF and start a search for the deeply hidden keyword : witdcard.
Yvan KOENIG (VALLAURIS, France) dimanche 26 juin 2011 20:54:49
iMac 21”5, i7, 2.8 GHz, 4 Gbytes, 1 Tbytes, mac OS X 10.6.8
Please : Search for questions similar to your own before submitting them to the community
To be the AW6 successor, iWork MUST integrate a TRUE DB, not a list organizer !
A comparison using the COUNTIF function and referencing a specific cell would work:
Formula in B2 and filled down the rest of column B.
Regards,
Barry
I guess that's the simplest workaround, awkward as it is. I'll use that approach. Thanks.
Yes, but I was looking for a way to do it without those functions. There should be a way to use wildcards with = as an expression, but apparently there isn't.
"Should?"
This forum doesn't deal in "should." Only in what you can (or can't) do with the tools available.
You could also use =LEFT(G9,3)="fit"
Regards,
Barry
As far as I know, the app isn't designed by MLModel but by Apple Engineers why apply the rules defined for this task.
++-+-+-+-+-+-+-+-++
Apple Human Interface Guidelines:
Apply the 80 Percent Solution
During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution‚ that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.
If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the same way. Involving a broad range of users in your design process can help you find the 80 percent solution.
+-+-+-+-+-+-+-+-+-++
I guess that what you want doesn't match this rule.
I wish to add that happily, Apple applications design isn't based on the same scheme than M…Soft one.
It's not sufficient that a feature is required by one user to see it embedded.
Yvan KOENIG (VALLAURIS, France) lundi 27 juin 2011 10:41:08
iMac 21”5, i7, 2.8 GHz, 4 Gbytes, 1 Tbytes, mac OS X 10.6.8
Please : Search for questions similar to your own before submitting them to the community
To be the AW6 successor, iWork MUST integrate a TRUE DB, not a list organizer !
Yikes! I didn't mean to start a war. I promise never to use the word "should" in this forum again. More accurately, what I meant was "I was expecting there to be a way to use wildcards with = as an expression, but I couldn't figure out how to do it -- am I missing something here? And if not, what would you use for a workaround?" And you gave me the kind of workaround I was looking for.
As to LEFT, unfortunately I simplified my example -- what I really need is to be able to find one string anywhere in another. My problem really involved matching the contents of a cell with a string with a wildcard at both ends, e.g. "*FIX*". I rethought the problem and realized that I originally tried FIND (and SEARCH) initially but was dissuaded by their causing an error when the string isn't found. That's what led me off looking for an expression-based solution. I think the direct way to express what I want within the tools Numbers provides is:
=NOT(ISERROR(FIND("FIX", G9)))
using SEARCH instead of FIND if I want to use wildcards and ignore case in the search. I like this slightly better than COUNTIF because while wordier it uses the vocabulary of logic and search rather than counting.
While I find your comment presumptuous, tone offensive, and responses entirely unhelpful, I agree with the points you make about application design. I didn't mean to suggest any changes to Numbers. See my response to Barry above. Furthermore, your signature includes a very strong statement about what iWork MUST include, which, ironically, seems a much graver violation of your implication that only Apple engineers know what iWork should include and how it should work.
MLModel wrote:
(1) While I find your comment presumptuous, tone offensive, and responses entirely unhelpful, I agree with the points you make about application design. I didn't mean to suggest any changes to Numbers. See my response to Barry above.
(2) Furthermore, your signature includes a very strong statement about what iWork MUST include, which, ironically, seems a much graver violation of your implication that only Apple engineers know what iWork should include and how it should work.
(1) As I often wrote, I write here, when I want and the way I want.
I add that "expecting" or "guessing" isn't the best way to use a spreadsheet. The syntax required by such tool can't be guessed. We must take care of the functions specifications.
A simple search with the deeply obscured word "wildcard" would have give you these two pages :
(2) I think that I may use the pointed formula because I was asked by Apple to work upon Numbers so, there is no violation here. Next time, turn your tongue seven times in your mouth before commenting. In French we say : "Quand on ne sait pas, on ferma sa gu...."
Yvan KOENIG (VALLAURIS, France) lundi 27 juin 2011 16:35:22
iMac 21”5, i7, 2.8 GHz, 4 Gbytes, 1 Tbytes, mac OS X 10.6.8
Please : Search for questions similar to your own before submitting them to the community
To be the AW6 successor, iWork MUST integrate a TRUE DB, not a list organizer !
Simple string comparison using wildcards
