Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch master updated. branch-5_40-base-83-ged20729

[Gunter K. <gu...@pe...>]

On 27.06.2017 00:08, Raymond Toy wrote:
>>>>>> "Andreas" == Andreas Eder <aek...@gm...> writes:
> 
>     Andreas> On Mo 26 Jun 2017 at 20:29, Raymond Toy <toy...@gm...> wrote:
> 
>     >> On Sun, Jun 25, 2017 at 2:25 AM, Andreas Eder via Maxima-commits <
>     >> max...@li...> wrote:
>     >> 
>     >>> commit e6a7a8af637ee29f549b1dd47633fb08172e17ae
>     >>> Author: Andreas Eder (are_muc) <and...@gm...>
>     >>> Date:   Sun Jun 25 11:06:41 2017 +0200
>     >>> 
>     >>> replaced uses of the half macro with the variable 1//2.
>     >>> had to adapt relative error bounds for the erf-inverse_erf
>     >>> tests
>     >>> sligthly.
>     >>> 
>     >>> 
>     >> ​This makes no sense to me.  Why should the results be different?
>     >> 
>     >> This needs some investigation.  Is it because the defvar version
>     >> wasn't
>     >> simplified?​
> 
>     Andreas> No, it is simplified.
>     Andreas> The defvar is: (defvar 1//2 '((rat simp) 1 2))
>     Andreas> That is, as far as I can tell, simplified.
>     Andreas> What I suspect is a different order of evaluation. The macro version is
>     Andreas> expande into a literal at macroexpansion time, whereas the defvar
>     Andreas> generates a reference to the variable at compile time. The might lead
>     Andreas> to
>     Andreas> different orders of evaluation. But I'm no expert in these matters.
>     Andreas> The difference is very small and I always expect such things when
>     Andreas> dealing with floating point.
> 
> That might be true, but in the tests, there shouldn't be any
> difference.  The VALUE being used should be exactly the same in the
> numeric tests as before.
> 

If the cause for the change is indeed the evaluation order my next
question would be: Did the change increase the accuracy (after all there
is no guarantee that the value originally contained in the testbench was
even correct before the change)? And does it do so in the majority of cases?
When designing digital filters I always keep an eye on the order the
operations are executed in in: Most of the times there is one order
which is prone for integer overflows and one that is prone for loosing
accuracy.

Kind regards,

  Gunter.