On the last item, do we really have to follow that strange, `d`,`g` and so
on conventions on formatting? With all respect to the humongous historical
baggage, I think that notation is pretty archaic and terminal like. If
being pythonic is of a concern here, maybe it is better to use a more
verbose syntax. Just throwing out an idea after 15 seconds of thought (so
by no means an alternative suggestion)
eng:6i5d -> engineering notation (always powers of ten of multiples of 3) 6
integral digits and 5 decimal digits.
float (whatever the default is)
float:4i2d (you get the idea)
etc.
FULL DISCLOSURE: I am a very displeased customer of `fprintf ` of matlab
(and others) and this archaic formatting. I never got a hang of it so it
might be the case that I don't quite get the rationale behind it and I
almost always get it wrong. Maybe at least the rationale can be clarified.
Lastly, repeating what others mentioned: thank you for this well prepared
initiative
On Wed, Feb 15, 2017 at 10:48 PM, Gustav Larsson <lars...@cs.uchicago.edu>
wrote:
> This is great!
>
>
> Thanks! Glad to be met by enthusiasm about this.
>
> 1. You basically have a NEP already! Making a PR from it allows to
>> give line-by-line comments, so would help!
>
>
> I will do this soon.
>
> 2. Don't worry about supporting python2 specifics; just try to ensure
>> it doesn't break; I would not say more about it!
>
>
> Sounds good to me.
>
> 3. On `set_printoptions` -- ideally, it will become possible to use
>> this as a context (i.e., `with set_printoption(...)`). It might make
>> sense to have an `override_format` keyword argument to it.
>
>
> Having a `with np.printoptions(...)` context manager is a great idea. It
> does sound orthogonal to __format__ though, so it could be addressed
> separately.
>
> 4. Otherwise, my main suggestion is to start small with the more
>> obvious ones, and not worry too much about format validation, but
>> rather about getting the simple ones to work well (e.g., for an object
>> array, just apply the format given; if it doesn't work, it will error
>> out on its own, which is OK).
>
>
> Sounds good to me. I was thinking of approaching the implementation by
> writing unit tests first and group them into different priority tiers. That
> way, the unit tests can go through another review before implementation
> gets going. I agree that __format__ doesn't have to check format validation
> if a ValueError is going to be raised anyway by sub-calls.
>
> 5. One bit of detail: the "g" one does confuse me.
>
>
> I will re-write this a bit to make it clearer. Basically, the 'g' with the
> mix of 'e'/'f' depending on max/min>1000 is all from the current numpy
> behavior, so it is not something I had much creative input on at all.
> Although, as it is written right now it may seem so. That is, the goal is
> to have {:} == {:g} for float arrays, analogous to how {:} == {:g} for
> built-in floats. Then, if the user departs a bit, like {:.2g}, it will
> simply be identical to calling np.set_printoptions(precision=2) first.
>
> Gustav
>
> On Wed, Feb 15, 2017 at 8:03 AM, Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Hi Gustav,
>>
>> This is great! A few quick comments (mostly echo-ing Stephan's).
>>
>> 1. You basically have a NEP already! Making a PR from it allows to
>> give line-by-line comments, so would help!
>>
>> 2. Don't worry about supporting python2 specifics; just try to ensure
>> it doesn't break; I would not say more about it!
>>
>> 3. On `set_printoptions` -- ideally, it will become possible to use
>> this as a context (i.e., `with set_printoption(...)`). It might make
>> sense to have an `override_format` keyword argument to it.
>>
>> 4. Otherwise, my main suggestion is to start small with the more
>> obvious ones, and not worry too much about format validation, but
>> rather about getting the simple ones to work well (e.g., for an object
>> array, just apply the format given; if it doesn't work, it will error
>> out on its own, which is OK).
>>
>> 5. One bit of detail: the "g" one does confuse me.
>>
>> All the best,
>>
>> Marten
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion@scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
