Representing the case "no result"



Raymond Toy wrote:
> Dieter Kaiser wrote:
>   
>> Am Montag, den 08.06.2009, 03:59 +0200 schrieb Harald Geyer:
>>   
>>     
>>> Well, you might introduce a new object without having all
>>> simplifications in place and it would still be better then returning
>>> an empty list.
>>>     
>>>       
>> OK, the starting point was that we have no convention for a "NO RESULT"
>> or "NO SOLUTION" like a divergent integral.
>>
>> What's about to return an expression like:
>>
>> (list '($NOOBJECT) (gensym))
>>
>> This would give:
>>
>> (%i24) integrate(x,x,0,inf);
>> defint: The integral is divergent.
>> (%o24) noobject(?g24049)
>>   
>>     
>
> I think it's pretty bad to expose gensyms to the user.
>   
>> When two integrals are involved in an expressions we get:
>>
>> (%i25) a*integrate(x,x,0,inf)/integrate(x^2,x,0,inf)^b;
>> defint: The integral is divergent.
>> defint: The integral is divergent.
>> (%o25) a*noobject(?g24196)/noobject(?g24343)^b
>>   
>>     
> 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],  ....
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

I have a paper on using NaNs for diagnostic information like this using 
a hash table.
Also one can initialize arrays this way in case you want to see if you 
are using an uninitialized datum.
Maxima would allow you to use a[1,1]  as a literal a[1,1],  but maybe 
you want to do this:

a[1,1]:NoObject[47], a[1,2]: ......

Diagnosis[47]: Uninitialized array a[1,1].
....

> 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.
Note that there is not just one NaN.  In double precision you have 
something like 2^51 different NaNs
so your Fortran system could have (for example) recorded the program 
counter where the NaN was
produced.  Or something else useful.
Also, of course, Fortran would have to be run interactively so you could 
interact with the debugging/diagnosis
system.


> What I really wanted was the program to die when a NaN was generated so
> I could figure out what was causing the NaN.
Wouldn't it be better if you got the program to stop and allow you to 
debug it?
>   Wouldn't maxima now have
> the same problem?
>   
See suggestion about Diagnosis[47]

> Perhaps the answer is in the parts of the thread that I didn't read.
Probably not.

Note that we would have to treat NoObject[i]   as "bottom"  ... or maybe 
like []  :)




RJF