On Wed, Oct 7, 2009 at 12:47 AM, Pierre GM <pgmdevl...@gmail.com> wrote:

>
> On Oct 7, 2009, at 1:12 AM, Gökhan Sever wrote:
> > One more from me:
> > I[1]: a = np.arange(5)
> > I[2]: mask = 999
> > I[6]: a[3] = 999
> > I[7]: am = ma.masked_equal(a, mask)
> >
> > I[8]: am
> > O[8]:
> > masked_array(data = [0 1 2 -- 4],
> >              mask = [False False False  True False],
> >        fill_value = 999999)
> >
> > Where does this fill_value come from? To me it is little confusing
> > having a "value" and "fill_value" in masked array method arguments.
>
> Because the two are unrelated. The `fill_value` is the value used to
> fill the masked elements (that is, the missing entries).
> When you create a masked array, you get a `fill_value`, whose actual
> value is defined by default from the dtype of the array: for int, it's
> 999999, for float, 1e+20, you get the idea.
> The value you used for masking is different, it's just whatver value
> you consider invalid. Now, if I follow you, you would expect the value
> in `masked_equal(array, value)` to be the `fill_value` of the output.
> That's an idea, would you mind fiilling a ticket/enhancement and
> assign it to me? So that I don't forget.
>

One more example. (I still think the behaviour of fill_value is
inconsistent) See below:

I[6]: f = np.arange(5, dtype=float)

I[7]: mask = 9999.9999

I[8]: f[3] = mask

I[9]: fm = ma.masked_equal(f, mask)

I[10]: fm
O[10]:
masked_array(data = [0.0 1.0 2.0 -- 4.0],
             mask = [False False False  True False],
       fill_value = 1e+20)


I[22]: fm2 = ma.masked_values(f, mask)

I[23]: fm2
O[23]:
masked_array(data = [0.0 1.0 2.0 -- 4.0],
             mask = [False False False  True False],
       fill_value = 9999.9999)


ma.masked_equal(x, value, copy=True)
ma.masked_values(x, value, rtol=1.0000000000000001e-05, atol=1e-08,
copy=True, shrink=True)

Similar function definitions, but different fill_values... Ok, it is almost
2 AM here my understanding might be crawling on the ground. Probably I will
re-read your comments and file an issue on the trac.



>
>
> > Probably you can pin-point the error by testing a 1.3.0 version
> > numpy. Not too many arc function with masked array users around I
> > guess :)
>
> Will try, but "if it ain't broken, don't fix it"...
>

Also if it is working don't update (This applies to Fedora updates :)
especially if you have an Nvidia display card)


>
> > assert(np.arccos(ma.masked), ma.masked) would be the simplest.
>
> (and in fact, it'd be assert(np.arccos(ma.masked) is ma.masked) in
> this case).
>
>
> > Good to know this. The more I spend time with numpy the more I
> > understand the importance of testing the code automatically. This
> > said, I still find the test-driven-development approach somewhat
> > bizarre. Start only by writing test code and keep implementing your
> > code until all the tests are satisfied. Very interesting...These
> > software engineers...
>
> Bah, it's not a rule cast in iron... You can start writing your code
> but do write the tests at the same time. It's the best way to make
> sure you're not breaking something later on.
> >
>
>
That's what I have been thinking, a more reasonable way. The other is way
too a reverse thinking.

Thanks for the long hours discussion.



> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
Gökhan
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to