Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2003
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2003

[Date Index] [Thread Index] [Author Index]

Search the Archive

Boolean type-checking arguments

  • To: mathgroup at smc.vnet.net
  • Subject: [mg41807] Boolean type-checking arguments
  • From: Murray Eisenberg <murray at math.umass.edu>
  • Date: Fri, 6 Jun 2003 09:50:38 -0400 (EDT)
  • Organization: Mathematics & Statistics, Univ. of Mass./Amherst
  • Reply-to: murray at math.umass.edu
  • Sender: owner-wri-mathgroup at wolfram.com

When type checking the argument to a function, it's often easy to use a 
built-in object in a pattern, e.g.:

   f[n_Integer] := n + 1

   g[x_?Positive] := Sqrt[x]

But what about type-checking that an argument is Boolean, i.e., True or 
False?  Of course it's easy enough to define a function to do this:

   tfQ[sym_] := MemberQ[{True, False}, sym]
   (* or:  tfQ[sym_] := Element[sym, Booleans] *)

   h[y_, flag_?tfQ] := ....

But is there no NAMED, single built-in object that does what the 
above-defined tfQ does?

If I am correct that there is not, this may result from what seems to be 
a fundamental language design decision, namely, that True and False are 
just symbols -- they do have head Symbol -- rather than being of a 
special type having, say head Boolean.  Why was that design decision made?

-- 
Reply to "REPLY TO" address and NOT to the "FROM" address!!
Otherwise I will never see your reply!!!!!!!!!!!!!!!!!!!!!!

Murray Eisenberg                     murray at math.umass.edu
Mathematics & Statistics Dept.
Lederle Graduate Research Tower      phone 413 549-1020 (H)
University of Massachusetts                413 545-2859 (W)
710 North Pleasant Street            fax   413 545-1801
Amherst, MA 01003-9305


  • Prev by Date: Re: Combinations of two lists
  • Next by Date: Re: Re: Big problem in solving radicals.
  • Previous by thread: Re: Numerical Optimization of Expensive Functions
  • Next by thread: Mathlink performance and task switches