From: Tobias C. Rittweiler <tcr@fr...>  20100430 08:02:54

Roman Marynchak <roman.marynchak@...> writes: > In the initial patch I signal SBKERNEL::ARGUMENTSOUTOFVALIDDOMAIN, this > condition is derived from ARITHMETICERROR. This is similar to Lispworks > behavior. CLISP signals DIVIZIONBYZERO, which is a bit confusing. Is that > possible to derive from ARITHMETICERROR and REFERENCEERROR at the same > time? Conditions support multiple inheritance like classes, so: (definecondition arithmeticreferenceerror (arithmeticerror referencecondition) ()) T. 
From: Roman Marynchak <roman.marynchak@gm...>  20100429 20:01:27
Attachments:
Message as HTML

Hello, I have found a tricky issue with EXPT behaviour in different implementations. Namely, evaluating (expt 0.0 0) yields: 1.0 in SBCL 1 in CLISP 1.0 in Lispworks. (expt 0 0.0) results in: 1.0 in SBCL error in CLISP error in Lispworks CLHS says that 0^0 = 1, and gives no details about float/integer combinations of these zeros. So, what is the valid answer here? Is there some complex math theory behind all this? Regards, Roman 
From: Malcolm Reynolds <malcolm.reynolds@gm...>  20100429 20:16:26

I'm not sure about the Lisp standard's view on this, but here is a variety of reasons why the correct mathematical answer is (arguably) 1, for any combination of integers or floats. I guess this doesn't answer whether it should be 1.0 or 1 but it definitely shouldn't be an error. http://www.faqs.org/faqs/scimathfaq/specialnumbers/0to0/ Malcolm On Thu, Apr 29, 2010 at 9:01 PM, Roman Marynchak <roman.marynchak@...> wrote: > Hello, > > I have found a tricky issue with EXPT behaviour in different > implementations. > > Namely, evaluating (expt 0.0 0) yields: > > 1.0 in SBCL > 1 in CLISP > 1.0 in Lispworks. > > (expt 0 0.0) results in: > > 1.0 in SBCL > error in CLISP > error in Lispworks > > > CLHS says that 0^0 = 1, and gives no details about float/integer > combinations of these zeros. > > So, what is the valid answer here? Is there some complex math theory behind > all this? > > > Regards, > Roman > >  > > _______________________________________________ > Sbcldevel mailing list > Sbcldevel@... > https://lists.sourceforge.net/lists/listinfo/sbcldevel > > 
From: Roman Marynchak <roman.marynchak@gm...>  20100429 20:31:43
Attachments:
Message as HTML

The thing is that (expt 0 0) yields 1 in all three implementations, so no question here. That interesting article mostly discusses this case. And about 0.0^0.0 it says: " As a rule of thumb, one can say that 0^0 = 1 , but 0.0^(0.0) is undefined, meaning that when approaching from a different direction there is no clearly predetermined value to assign to 0.0^(0.0) ; but Kahan has argued that 0.0^(0.0) should be 1, because if f(x), g(x) > 0 as x approaches some limit, and f(x) and g(x) are analytic functions, then f(x)^g(x) > 1 " so it seems that error comes due to the undefined result of 0.0^0.0. Maybe there is some article devoted to this case? I have just implemented the EXPT patch for SBCL, but I do not know what should I return: 1, 1.0 or raise an error? Regards, Roman 2010/4/29 Malcolm Reynolds <malcolm.reynolds@...> > I'm not sure about the Lisp standard's view on this, but here is a > variety of reasons why the correct mathematical answer is (arguably) > 1, for any combination of integers or floats. I guess this doesn't > answer whether it should be 1.0 or 1 but it definitely shouldn't be an > error. > > http://www.faqs.org/faqs/scimathfaq/specialnumbers/0to0/ > > Malcolm > > On Thu, Apr 29, 2010 at 9:01 PM, Roman Marynchak > <roman.marynchak@...> wrote: > > Hello, > > > > I have found a tricky issue with EXPT behaviour in different > > implementations. > > > > Namely, evaluating (expt 0.0 0) yields: > > > > 1.0 in SBCL > > 1 in CLISP > > 1.0 in Lispworks. > > > > (expt 0 0.0) results in: > > > > 1.0 in SBCL > > error in CLISP > > error in Lispworks > > > > > > CLHS says that 0^0 = 1, and gives no details about float/integer > > combinations of these zeros. > > > > So, what is the valid answer here? Is there some complex math theory > behind > > all this? > > > > > > Regards, > > Roman > > > > >  > > > > _______________________________________________ > > Sbcldevel mailing list > > Sbcldevel@... > > https://lists.sourceforge.net/lists/listinfo/sbcldevel > > > > > 
From: Harald HancheOlsen <hanche@ma...>  20100429 23:59:21

It seems to me that the hyperspec is quite specific about (expt 0.0 0): When powernumber is an integer 0, then the result is always the value one in the type of basenumber, even if the basenumber is zero (of any type). That is: (expt x 0) == (coerce 1 (typeof x)) You can't possibly get any clearer than that. And it continues: If powernumber is a zero of any other type, then the result is also the value one, in the type of the arguments after the application of the contagion rules in Section 12.1.1.2 (Contagion in Numeric Operations), with one exception: the consequences are undefined if basenumber is zero when powernumber is zero and not of type integer. In other words, the consequences of (expt ZERO 0.0) are undefined if ZERO is a zero of any type.  Harald 
From: Roman Marynchak <roman.marynchak@gm...>  20100430 06:17:46
Attachments:
Message as HTML

Thanks for this explanation. Now I understand the behavior of EXPT in CLISP and Lispworks, and I will modify the patch for SBCL accordingly. Regards, Roman 2010/4/30 Harald HancheOlsen <hanche@...> > It seems to me that the hyperspec is quite specific about > (expt 0.0 0): > > When powernumber is an integer 0, then the result is always the > value one in the type of basenumber, even if the basenumber is > zero (of any type). That is: > > (expt x 0) == (coerce 1 (typeof x)) > > You can't possibly get any clearer than that. > > And it continues: > > If powernumber is a zero of any other type, then the result is also > the value one, in the type of the arguments after the application of > the contagion rules in Section 12.1.1.2 (Contagion in Numeric > Operations), with one exception: the consequences are undefined if > basenumber is zero when powernumber is zero and not of type > integer. > > In other words, the consequences of (expt ZERO 0.0) are undefined if > ZERO is a zero of any type. > >  Harald > > >  > _______________________________________________ > Sbcldevel mailing list > Sbcldevel@... > https://lists.sourceforge.net/lists/listinfo/sbcldevel > 
From: Tobias C. Rittweiler <tcr@fr...>  20100430 07:30:06

Roman Marynchak <roman.marynchak@...> writes: > Thanks for this explanation. Now I understand the behavior of EXPT in CLISP > and Lispworks, and I will modify the patch for SBCL accordingly. You can signal an appropriate subtype of sbkernel::referenceerror and include '(:ansicl :function expt) as reference so future people bitten by it will have a pointer into the right direction. T. 
From: Roman Marynchak <roman.marynchak@gm...>  20100430 07:51:08
Attachments:
Message as HTML

In the initial patch I signal SBKERNEL::ARGUMENTSOUTOFVALIDDOMAIN, this condition is derived from ARITHMETICERROR. This is similar to Lispworks behavior. CLISP signals DIVIZIONBYZERO, which is a bit confusing. Is that possible to derive from ARITHMETICERROR and REFERENCEERROR at the same time? Regards, Roman 2010/4/30 Tobias C. Rittweiler <tcr@...> > Roman Marynchak <roman.marynchak@...> writes: > > > Thanks for this explanation. Now I understand the behavior of EXPT in > CLISP > > and Lispworks, and I will modify the patch for SBCL accordingly. > > You can signal an appropriate subtype of sbkernel::referenceerror and > include '(:ansicl :function expt) as reference so future people bitten > by it will have a pointer into the right direction. > > T. > > > >  > _______________________________________________ > Sbcldevel mailing list > Sbcldevel@... > https://lists.sourceforge.net/lists/listinfo/sbcldevel > 
From: Tobias C. Rittweiler <tcr@fr...>  20100430 08:02:54

Roman Marynchak <roman.marynchak@...> writes: > In the initial patch I signal SBKERNEL::ARGUMENTSOUTOFVALIDDOMAIN, this > condition is derived from ARITHMETICERROR. This is similar to Lispworks > behavior. CLISP signals DIVIZIONBYZERO, which is a bit confusing. Is that > possible to derive from ARITHMETICERROR and REFERENCEERROR at the same > time? Conditions support multiple inheritance like classes, so: (definecondition arithmeticreferenceerror (arithmeticerror referencecondition) ()) T. 