Representing the case "no result"



Raymond Toy wrote:
> Richard Fateman wrote:
>   
>> Raymond Toy wrote:
>>   
>>     
>>> I haven't been following this discussion too closely, but how is
>>> noobject(gensym) any better than just signaling an error?  How does %o25
>>> help the user in any way?  Can you do anything useful with such a
>>> result?  Can you tell how noobject(?g24196) came about?  (Well, in a
>>> non-trivial example.  This example is pretty clear where each noobject
>>> came from.)
>>>   
>>>     
>>>       
>> 1.  There is really no need for a gensym.  There could simply be an 
>> array of noobjects.
>> E.g. NoObject[45], NoObject[46],  ....
>>   
>>     
> This seems much better than a gensym.
>   
actually, it need not be an array. In Maxima it is simpler, 
representationally, to use NoObject(45).  A "function".
>> 2. What can be done with this?
>> Well, we can also produce
>> Diagnosis[45]:  "The integral  integrate(......) is divergent"
>> Diagnosis[46]:  "Division by zero in function foo()"
>> etc
>>   
>>     
> This seems nice.  But what would be nicer than having the program stop
> (as we can with Maxima) exactly at the point of the error so we can
> debug it? 
Sometimes. You are assuming that the person running the program is also 
the person who wrote the
program or is capable of debugging it.  A successful program presumably 
is run by other people.
Of course such a program should not produce errors :)

>  After all, we could have a complicated function foo that
> causes division by zero in many places.  I'd like to see it stop when we
> get there.
>   
You probably want to stop it some time before that... But some divisions 
by zero disappear.
e.g.
 3+ 1/(1/0)   is just 3.

>> I have a paper on using NaNs for diagnostic information like this using 
>> a hash table.
>>   
>>     
> Can you send me a pointer to that?
>   
http://www.cs.berkeley.edu/~fateman/papers/retrodiag.pdf
>>   
>>     
>>> Back when I used to run Fortran simulations, I sometimes would get cool
>>> results like NaN for all of my expected output.  It's nice that it
>>> didn't crash, but getting NaN for an answer was pretty useless to me. 
>>>   
>>>     
>>>       
>> That's because Fortran support systems were bad, and didn't use NaNs for 
>> diagnosis.
>>   
>>     
> I don't know of any system that actually encodes such info.   But it's
> an interesting idea.
>   
I wrote one.  But it was not interesting enough for the ISSAC program 
committee  in 1999 :)