On 30 September 2015 at 15:17, Jeroen Demeyer <jdeme...@cage.ugent.be>
wrote:

> On 2015-09-30 14:54, 'Bill Hart' via mpir-devel wrote:
>
>>     Why do you say that? For the two variables in question, there are
>>     certainly invalid values: changing the default value from 11 to 0
>>     fixes the problem. So I would say that the 11 is invalid (or maybe
>>     it's only invalid in combination with other values, but I don't
>>     think that matters much).
>>
>> I don't see how this is relevant.
>>
> Well, changing the default value for these parameters to 0 is a very easy
> fix and it seems to work.
>
> But I don't know MPIR well enough to decide whether it's a
> good/acceptable/bad fix.


Changing the default value to 0 for those two values is probably a
reasonable thing to do. Please do that.

But please note I am not advocating that as a valid workaround on its own.

I think the real problem likely comes from somewhere else. Most likely, the
tuning values for the crossover to divide-and-conquer are missing. But I'm
guessing and don't want to be quoted on that somewhere down the track.

What I want to be quoted on is:

1) Run the tuning program on arches for which the values are missing.

2) Check the two values in question are set to 0 by the tuning program on
those arches (it most likely is).

3) If not, manually set those two values to 0 until we can verify the new
algorithm actually works correctly on the arches in question.

4) This is a workaround for the issue you reported, not a bug fix. It is
the best we can do until someone has the time and the hardware to actually
track the bug down on a real machine.

5) I will eventually find time to set up some VM's, which will improve the
situation, though that quite clearly can't substitute for testing the
library on real machines.

Developing for machines we don't have involves some guesswork. We sometimes
get it wrong. We also have infinitesimal resources to develop MPIR and we
have to prioritise so that the one month a year we get to spend on MPIR
development actually makes a difference to the greatest number of people.
Supporting old 32 bit machines can hardly be one of those priorities.

Are you aware that we don't properly support hardware later than about
2010? Could this perhaps be a more serious issue?

Bill.

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to