[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-glpk] 0 ** 0; result undefined
From: |
xypron |
Subject: |
Re: [Bug-glpk] 0 ** 0; result undefined |
Date: |
Sat, 8 Nov 2008 09:33:03 -0800 (PST) |
According to ISO/IEC 9899:TC2 (ISO C99)
A domain error may occur if x is zero and y is zero. (in function pow).
Obviously this is implementation dependent.
Hence the code in fp_power has to check to be compatible with different C
compilers.
Best regards
Xypron
xypron wrote:
>
> A nice discussion on 0^0 can be found at
> http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
> http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
>
> The coding in question is in src/glpmpl03.c function fp_power.
> As pow(0,0) returns 1 it would not cause any problems, to treat 0^0 as
> defined.
> As no GMPL model runs better when 0^0 is undefined but some are easier to
> formulate if it is defined making it defined seems a good choice.
>
> Best regards
>
> Xypron
>
>
>
> Andrew Makhorin wrote:
>>
>>> "0 ** 0; result undefined "
>>
>>> Result of 0 ** 0 is defined, it #39;s 1. That #39;s all.
>>
>> In the strong mathematical sense 0 ** 0 is undefined. Defining 0 ** 0
>> as 1 violates continuity and sometimes may lead to false conclusions.
>>
>> Nevertheless, if you disagree with that, you can always check operands
>> to produce desirable result, for example:
>>
>> param a := (if x = 0 and y = 0 then 1 else x ** y);
>>
>>
>>
>> _______________________________________________
>> Bug-glpk mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/bug-glpk
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/0-**-0--result-undefined-tp20396737p20398310.html
Sent from the Gnu - GLPK - Bugs mailing list archive at Nabble.com.