On Sun, Feb 10, 2013 at 4:18 PM, Hagar Delest <hagar.del...@laposte.net> wrote:
> Le 10/02/2013 21:53, Rob Weir a écrit :
>
>> The error in your thinking is to persist in arguing that there is only
>> one correct answer. That is false. I can point to mathematical
>> authorities of great reputation to argue for any of three answers. The
>> question is whether we change from the correct answer we give in AOO
>> 3.4.1 and before to a different correct answer, and in doing so break
>> compatibility.
>
>
> The problem is to give the answer that is the most useful for the user.
> Shall we tell him 1 or tell him that there is an error because he came upon
> a corner case?
> Of course I see your point. But is it the best behavior to hide a potential
> issue to the user, letting him think that everything is OK?
>
>
>
>> Let me show you how lame this argument is. What is sqrt(4)? 2,
>> right? Well, that is one convention. -2 is also a valid answer.
>> Would you be OK if we changed the code to return -2? What about an
>> error message because it is ambiguous? Of course, not, because we
>> adopt the convention to return the positive root only.
>
>
> But there is no uncertainty here. Like angles and trigonometric functions,
> there are 2 possibilities. There are no corner case here. It is assumed that
> the user knows what he's doing.
>
> I've no problem with conventions, as long as they give the best answer to
> the user.
> What about giving 1 or 0 to 0/0? That would be very comfortable! But giving
> an error is the best way because it warns the user that there is a problem
Try to argue your point honestly. You know very well that there is no
common convention where 0/0 == 1.
> (that would get unnoticed else and lead to definitively wrong results). We
> all have experienced this #DIV/0! error and we are happy with it because we
> can investigate and find out that there was a mistake somewhere.
> Same for the 0^0 issue. Giving an error could make the user aware that there
> is a mistake in his calculation. Giving a result can hide such mistakes.
>
This goes against the general design of spreadsheets. They are not
programming languages for programmers. They are intended to just
work, to give reasonable answers for user inputs. The error handling
mechanisms are very primitive. That is why spreadsheets do all sorts
of things to avoid giving errors.
For example:
RIGHT("foo";1000) returns "foo" not an error.
MID("foo"; 100;1000) returns an empty string, not a error.
Many programming language would give an exception here. Spreadsheets
don't. Spreadsheets try to be robust. This is a design that has
worked well for over 20 years.
Now you could imagine, designing from scratch a new spreadsheet
application, without concerns about backwards compatibility. In such
a case you might do all sorts of things differently, including
enforcing type safety, index checking, better error handling support,
etc. But that is not the situation we're in. We have a 12 year old
application with millions of users and many millions of documents. We
can't pretend that all design options are on the table.
-Rob
> Hagar
