From: Colin P. A. <co...@co...> - 2004-05-31 17:29:31
|
I am getting a problem with VE and SE (not with ISE). I think it is the same problem in each case (I find it hard to understand VE's stack trace). Here is the top of the SE stack trace: line 625 column 57 file /home/colin/gobo/library/math/decimal/abstract/ma_decimal.e ====================================== infix <= KL_PART_COMPARABLE Current = MA_DECIMAL#0x97abe20 [ exponent = 0 coefficient = #0x97aebb4 is_negative = false special = 0 ] other = MA_DECIMAL#0x982f2f8 [ exponent = 0 coefficient = #0x98232c4 is_negative = false special = 0 ] Result = false line 34 column 4 file /home/colin/gobo/library/kernel/misc/kl_part_comparable.e ====================================== is_equal MA_DECIMAL Current = MA_DECIMAL#0x97abe20 [ exponent = 0 coefficient = #0x97aebb4 is_negative = false special = 0 ] other = MA_DECIMAL#0x982f2f8 [ exponent = 0 coefficient = #0x98232c4 is_negative = false special = 0 ] Result = false comparison_result = MA_DECIMAL#0x97abe08 [ exponent = 0 coefficient = Void is_negative = false special = 0 ] line 560 column 26 file /home/colin/gobo/library/math/decimal/abstract/ma_decimal.e ====================================== invariant once MA_DECIMAL Current = MA_DECIMAL#0x97abe08 [ exponent = 0 coefficient = Void is_negative = false special = 0 ] line 2531 column 30 file /home/colin/gobo/library/math/decimal/abstract/ma_decimal.e ===== Top of run-time stack ===== -- Colin Paul Adams Preston Lancashire |
From: Eric B. <er...@go...> - 2004-05-31 18:04:20
|
Colin Paul Adams wrote: > I am getting a problem with VE and SE (not with ISE). The reason why you don't get it in ISE is probably because it is an invariant violated while checking another assertion. I don't know why you get this error, but I found something else which needs to be fixed. In MA_DECIMAL.copy we will have a crash if 'other.coefficient = Void' (in case `other' is_special). During my code review I noticed a bunch of assertions which were either missing or could be violated (the invariant violation that you just got was not in my list). We will need to work with Paul on these assertions because I think that it will help make the decimal library even more robust than it is. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Colin P. A. <co...@co...> - 2004-05-31 18:49:59
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes: Eric> We will need to work with Paul on these assertions Eric> because I think that it will help make the decimal library Eric> even more robust than it is. First, I have to apologise for sending the last message just to you, and not to the list - it seems that after upgrading my system, I have lost my customised key bindings. Now in MA_DECIMAL.to_integer, the pre-condition: within_limits: Current <= Maximum_integer_as_decimal or else Current >= Minimum_integer_as_decimal appears to be wrong - it surely should be and then, not or else. Not that that is the problem, as the pre-condition is certainly satisfied either way in this case (the value is 1). Now to repeat the VE failure, for Paul's benefit: ------------------------------------------------------------------------------- Program terminated by exception Routine: is_equal Message: Loop variant violation Code: 10004 Object: MA_DECIMAL_COEFFICIENT_IMP ------------------------------------------------------------------------------- -- Colin Paul Adams Preston Lancashire |
From: Eric B. <er...@go...> - 2004-05-31 19:07:01
|
Colin Paul Adams wrote: > Now in MA_DECIMAL.to_integer, the pre-condition: > > within_limits: Current <= Maximum_integer_as_decimal or else Current >= Minimum_integer_as_decimal > > appears to be wrong - it surely should be and then, not or else. This one was in my list that I sent to Paul today after my code review. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Paul G. C. <pau...@pl...> - 2004-05-31 19:16:09
|
Eric Bezault wrote: > Colin Paul Adams wrote: > >> Now in MA_DECIMAL.to_integer, the pre-condition: >> >> within_limits: Current <= Maximum_integer_as_decimal or else Current >> >= Minimum_integer_as_decimal >> >> appears to be wrong - it surely should be and then, not or else. > > > This one was in my list that I sent to Paul today > after my code review. > I'm busy processing the code review ;) Paul G. Crismer |
From: Paul G. C. <pau...@pl...> - 2004-05-31 18:39:36
|
Colin Paul Adams wrote: >I am getting a problem with VE and SE (not with ISE). >I think it is the same problem in each case (I find it hard to >understand VE's stack trace). > > With Visual Eiffel, there is an invariant in NUMERIC that says : self_division: divisible (Current) implies equal (Current / Current, one) MA_DECIMAL.divisible reports true unless the operand is zero. The invariant shall be violated each time we have special values (Inf, Nan, etc...). This problem needs further investigations. As Eric said, there are a lot of things to fix in the library to make it more robust regarding DBC. This is the benefit of peer review. Best regards, Paul G. Crismer |
From: Colin P. A. <co...@co...> - 2004-05-31 18:51:43
|
>>>>> "Paul" == Paul G Crismer <pau...@pl...> writes: Paul> Colin Paul Adams wrote: >> I am getting a problem with VE and SE (not with ISE). I think >> it is the same problem in each case (I find it hard to >> understand VE's stack trace). >> Paul> With Visual Eiffel, there is an invariant in NUMERIC that Paul> says : Paul> self_division: divisible (Current) implies equal (Current / Paul> Current, one) Paul> MA_DECIMAL.divisible reports true unless the operand is Paul> zero. Paul> The invariant shall be violated each time we have special Paul> values (Inf, Nan, etc...). This problem needs further Paul> investigations. As Eric said, there are a lot of things to Paul> fix in the library to make it more robust regarding DBC. I don't think this is the case for my particular problem. -- Colin Paul Adams Preston Lancashire |
From: Eric B. <er...@go...> - 2004-05-31 19:01:32
|
Colin Paul Adams wrote: > Eric> The reason why you don't get it in ISE is probably because > Eric> it is an invariant violated while checking another > Eric> assertion. > > I see. > What I can't find at the moment is the invariant clause that is failing. From what I could see in the SE exception trace, it looks like you have a decimal object which is not special (special = 0) and which has a Void `coefficient'. This violates one of the invariants of MA_DECIMAL. Now I don't know why we get such a inconsistent decimal. > For the same test case, VE reports: > > ------------------------------------------------------------------------------- > Program terminated by exception > > Routine: is_equal > Message: Loop variant violation > Code: 10004 > Object: MA_DECIMAL_COEFFICIENT_IMP > ------------------------------------------------------------------------------- This looks like another error. But it is perhaps a consequence of the same bug, but caught later if the level of nested checked assertions is different. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Colin P. A. <co...@co...> - 2004-05-31 19:19:45
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes: Eric> Colin Paul Adams wrote: The reason why you don't get it in Eric> ISE is probably because it is an invariant violated while Eric> checking another assertion. >> I see. What I can't find at the moment is the invariant clause >> that is failing. Eric> From what I could see in the SE exception trace, it looks Eric> like you have a decimal object which is not special (special Eric> = 0) and which has a Void `coefficient'. This violates one Eric> of the invariants of MA_DECIMAL. Now I don't know why we get Eric> such a inconsistent decimal. The decimal concerned prints as: [0,2,0] so the coefficient is not zero. Should I send the full exception trace? -- Colin Paul Adams Preston Lancashire |
From: Colin P. A. <co...@co...> - 2004-06-01 08:22:01
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes: >> For the same test case, VE reports: >> ------------------------------------------------------------------------------- >> Program terminated by exception Routine: is_equal Message: Loop >> variant violation Code: 10004 Object: >> MA_DECIMAL_COEFFICIENT_IMP >> ------------------------------------------------------------------------------- Eric> This looks like another error. But it is perhaps a Eric> consequence of the same bug, but caught later if the level Eric> of nested checked assertions is different. I think it must be another bug, as adding the print statements that I used to circumvent the SE problem, makes no difference for VE. I'll look into it. -- Colin Paul Adams Preston Lancashire |
From: Eric B. <er...@go...> - 2004-05-31 19:57:53
|
Colin Paul Adams wrote: > Eric> From what I could see in the SE exception trace, it looks > Eric> like you have a decimal object which is not special (special > Eric> = 0) and which has a Void `coefficient'. This violates one > Eric> of the invariants of MA_DECIMAL. Now I don't know why we get > Eric> such a inconsistent decimal. > > The decimal concerned prints as: > > [0,2,0] > > so the coefficient is not zero. I was referering to this decimal at the end of the exception trace that you sent: comparison_result = MA_DECIMAL#0x97abe08 [ exponent = 0 coefficient = Void is_negative = false special = 0 ] -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
From: Colin P. A. <co...@co...> - 2004-06-01 07:36:22
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes: Eric> I was referering to this decimal at the end of the exception Eric> trace that you sent: Eric> comparison_result = MA_DECIMAL#0x97abe08 [ exponent = 0 Eric> coefficient = Void is_negative = false special = 0 ] The decimal concerned is either Maximum_integer_as_decimal or Minimum_integer_as_decimal. Adding print (Maximum_integer_as_decimal.out) print (Minimum_integer_as_decimal.out) to my code makes the problem disappear, so it looks to me like an odd bug in SmartEiffel. -- Colin Paul Adams Preston Lancashire |