On 11/08/2010 02:17 PM, Skipper Seabold wrote: > On Mon, Nov 8, 2010 at 3:14 PM, Skipper Seabold<[email protected]> wrote: >> I am doing some optimizations on random samples. In a small number of >> cases, the objective is not well-defined for a given sample (it's not >> possible to tell beforehand and hopefully won't happen much in >> practice). What is the most numpythonic way to handle this? It >> doesn't look like I can use np.seterrcall in this case (without >> ignoring its actual intent). Here's a toy example of the method I >> have come up with. >> >> import numpy as np >> >> def reset_seterr(d): >> """ >> Helper function to reset FP error-handling to user's original settings >> """ >> for action in [i+'='+"'"+d[i]+"'" for i in d]: >> exec(action) >> np.seterr(over=over, divide=divide, invalid=invalid, under=under) >> > It just occurred to me that this is unsafe. Better options for > resetting seterr? > >> def log_random_sample(X): >> """ >> Toy example to catch a FP error, re-sample, and return objective >> """ >> d = np.seterr() # get original values to reset >> np.seterr('raise') # set to raise on fp error in order to catch >> try: >> ret = np.log(X) >> reset_seterr(d) >> return ret >> except: >> lb,ub = -1,1 # includes bad domain to test recursion >> X = np.random.uniform(lb,ub) >> reset_seterr(d) >> return log_random_sample(X) >> >> lb,ub = 0,0 >> orig_setting = np.seterr() >> X = np.random.uniform(lb,ub) >> log_random_sample(X) >> assert(orig_setting == np.seterr()) >> >> This seems to work, but I'm not sure it's as transparent as it could >> be. If it is, then maybe it will be useful to others. >> >> Skipper >> > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion What do you mean by 'floating point error'? For example, log of zero is not what I would consider a 'floating point error'.
In this case, if you are after a log distribution, then you should be ensuring that the lower bound to the np.random.uniform() is always greater than zero. That is, if lb <= zero then you *know* you have a problem at the very start. Bruce _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
