Re: Chi2 calculation for rebinned spectra in ISIS

Dear Maria,

just one obvious comment in addition to the previous answers. You say that:
>> So the difference is almost a factor of two, and the parameters of the fit are also different. 
If the parameters are different (which of course yields a different
chi^2), it could also be the case that the best fit simply has not been
found yet. (Although the global best fit should be found easily for a
power law model.)
The essential question is, if the chi^2 in XSPEC and ISIS differ for the
same model, parameter values, binning, statistics, etc..
If that is the case, the reasons for that are probably those in Mike's
comprehensive explanation.

Cheers,
Moritz

PS: Sorry for the trivial comment, but it's better to exclude possible
simple solutions before working hard on checking the difficult ones.


On 04/29/2014 04:54 PM, Michael Nowak wrote:
> 
> On Apr 29, 2014, at 5:44 AM, María Díaz Trigo <mdiaztri_at_email.domain.hidden> <mailto:mdiaztri_at_email.domain.hidden> 
>> I have realised that the chi2 value for rebinned spectra is very
>> different when calculated by ISIS and XSPEC. The chi2 is exactly the
>> same when I use non-binned spectra, so the difference must arise with
>> the way of calculating errors after rebinning.
>>
>> I am using the default fitting method (which seems to be the same for
>> XSPEC and ISIS) and rebin the HEG spectra to have a minimum of 25
>> cts/bin. Before rebinning, a simple power law fit gives me a chi2 of
>> 838.37 for 2362 dof both in ISIS and XSPEC. After rebinning, I get:
>>
>> XSPEC: Chi2 of 217.90 (460) 
>> ISIS: Chi2 of 420.46 (460)
>>
>> So the difference is almost a factor of two, and the parameters of the
>> fit are also different. 
>>
>> Do you know why am I getting such a difference?
> 
> Hi Maria-
> 
> We'd need a few more details, but here's where the differences can arise:
> 
> * If you read in a spectral file into ISIS and *don't* rebin, then the
> error will be
> whatever is in the error column of the file, and this will depend upon
> how you
> made the file.  (This is also true in ISIS if one uses define_counts to
> create
> the data – it defaults to whatever you set the err column to be originally.)
> 
> * The one modification to the above is that ISIS will set a lower limit
> on the error
> via the Minimum_Stat_Err variable (which defaults to 1, *unless* you are
> using
> my .isisrc routines, in which case I set it to 1.e-30).  So, any bins
> with 0 counts
> in them very well might be an issue, and be treated differently in ISIS
> vs. XSPEC.
> 
> * If you rebin the data *within* ISIS, then it follows whatever was set by 
> set_rebin_error_method, which defaults to poisson == sqrt(grouped_counts),
> with the caveat that Minimum_Stat_Err still applies.
> 
> * Errors are further modified by whether or not systematic errors were
> set.  In 
> ISIS, they will only be applied if you set them within the program,
> regardless of
> what the spectral file says.
> 
> In the end, ISIS and XSPEC should always give the same answer to several
> decimal places, once we verify that things have been set up the same.
> (I honestly don't remember what the defaults are for XSPEC when it comes
> to errors – I think it also defaults to what's in the error column of
> the file,
> which possibly might not be following sqrt(summed counts), depending upon
> how the binned file was made.) 
> 
> Did you bin the data outside of ISIS and then read it in, or is this a
> case of
> binning one outside for XSPEC, and one inside for ISIS?  
> 
> The ISIS function get_data_counts will retrieve the data into a
> structure, and
> then you can just see directly what you have for the value and errors
> for the
> data.  That would likely help you figure out where any differences are
> coming
> from.  
> 
> You can feel free to directly send me data & script, and I can help
> explain further
> based upon what you did.
> 
> -Mike
> 
> 
----
You received this message because you are
subscribed to the isis-users list.
To unsubscribe, send a message to
isis-users-request_at_email.domain.hiddenwith the first line of the message as:
unsubscribe