RagDyeR wrote:

[...]
> This is the second time in as many days that I'm bringing up *my* issue with
> the unary, or as you mention here, the "comma" syntax.

To clear up any misunderstanding, I'm definitely in favor of the
comma-syntax, while you are, in fact, arguing/recommending against the
use of SumProduct's comma-syntax.

>
> In today's world, the use of the web for mining data is as common a fact of
> life as is the use of the computer itself.
> They are in fact, virtually synonymous.
>

I don't think so. That was the point of my reply.

> Data imported into XL, and the form and format of this data, is a very
> common issue within these NGs.
> On a daily basis, there are numerous questions pertaining to unworkable
> formulas, where the ultimate solution is to "homogenize" the data forms and
> formats.

Issues with numeric data, erroneously typed as text (either by user or
by the "vagaries" of the system's parser) do not constitute a valid
reason to delegate the re-solution to functions.

>
> The "problem" with the comma syntax is, it's *sneaky*!
> In a convoluted scenario of "mixed" data, it returns a "wrong" result,
> without any conspicuous declaration.
> Zero is calculated for the "bad" data (numeric text as well as alpha text),
> and its result is mixed in with the "good" data.
>

Such concerns are better dealt with by means of separate formulas that
audit the data. If a range should be numeric, a simple audit formula can
verify whether that is the case. For example:

=COUNT(Range)=ROWS(Range)

As a side note, I teach this subject in my audit classes with the 3rd
year accountancy students.

> The developer completes the project and it's turned over to office staff for
> implementation.
> Then, let the cards fall where they may!

The developer should provide an audit sheet (rarely done), regarding the
data types and the processing a spreadsheet model carries out. Auditors
(e.g., accountants) ought to require audit sheets.

>
> The asterisk form, on the other hand, *does* calculate the numeric text, and
> "errors out" in the presence of alpha text, thus performing double duty.
> It's the notification that's the important thing.

A data area can consist of either user-entered values or calculated
values. There might be good reasons for using ="" or any other
text-value. Such an area becomes unprocessible by your suggestion.

> If you're told something's wrong, you can look for it!

Quite so. One would be well-advised to inspect the results of
judiciously set up audit formulas.

[...]

--

[1] The SumProduct function should implicitly coerce the truth values to
their Excel numeric equivalents.
[2] The lookup functions should have an optional argument for the return
value, defaulting to #N/A in its absence.