Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Reasons (not) to vote Motion 27: NO

On 08/05/2011 04:02 PM, Nate Hayes wrote:

John Pryce wrote:

On 4 Aug 2011, at 13:09, Nate Hayes wrote:

Arnold Neumaier wrote:

Motion 26 protects the inexperienced user, while the expert user can
judge
for themselves how to make use of the decorations.


All Motion 26 does in this regard is allow users to write unreliable
programs. Since there is no standard, a user may run a program on one
conforming implementation that uses a certain set of semantics and get
valid
results (by coincidence) and then run the same program on another
conforming
implementation and fail catastrophically.


What I wrote is intended to preclude that:
On 2 Aug 2011, at 06:50, John Pryce wrote:

Please write, and put in your library, a decorated version of
intersection that fits your applications. Offer its API for general use.
Let others do the same. Just ensure THEY ALL HAVE DIFFERENT NAMES.



It doesn't matter. If an inexperienced user takes the three
intersections in
the fgood program to give a bare interval result as you are suggesting,
then
fgood([0,0],[3,4]) will still be empty; and this is not the intended result
(it should be nonempty).


Which fgood function???
Note that the example I had discussed in December does not conform to Motion 26, so you cannot use it to accuse Motion 26 of being buggy. 



So the program may still experience catastrophic failure.
The user in this case, however, can't be accused of writing buggy code
because by all standards in Motion 26 the user did nothing wrong.
An environment conforming to Motion 26 will get a type error when trying to execute the fgood from dec.txt. 


Arnold Neumaier