python-quantities-developers team mailing list archive

[John Salvatier <jsalvatier@xxxxxxxxx>]

for "[20, 30 , 3.14159] * kPa * J **2 / BTU"
I think
array([ 20.     ,  30.     ,   3.14159]) * J**2 * kPa / BTU
Would look cleaner.

for "print [20, 30 , 3.14159] * kPa * J **2 / BTU"
I think either
[ 20.       30.        3.14159] J² · kPa / BTU
or
[ 20.       30.        3.14159] J² kPa / BTU
Would look cleaner.

Just my two cents.

I can implement concatenate and sqrt if that's useful.

John

On Tue, Feb 10, 2009 at 11:49 AM, Darren Dale <dsdale24@xxxxxxxxx> wrote:

>
>
> On Mon, Feb 9, 2009 at 9:22 PM, John Salvatier <jsalvatier@xxxxxxxxx>wrote:
>
>> Sounds good.
>>
>> Here are some miscellaneous notes:
>>
>>    1. In the tutorial, the part describing simplification in unambiguous
>>    situations is vague. It might be good to say that "unambiguous" means the
>>    units cancel directly
>>    2. I still think units when printed need more spacing between terms.
>>    The units term seems cramped
>>
>>
> What do think would look better?
>
>>
>>    1. Is there a general rule for how plural vs. non-plural unit names
>>    are handled by quantities? I ask because f = Quantity(1, 'feet') works but
>>    the UnitQuantity feet is not defined (so q = 1* feet does not work). It
>>    might be useful to mention how this works in the tutorial as this seems like
>>    the sort of thing that could frustrate new users. Alternatively, Quantities
>>    could define a bunch of common plural units, but this seems like a lot of
>>    extra variables.
>>
>> Yeah, it is maybe a bit confusing. I'll add a note in the documentation
> that plural variants for unit names are only available through strings for
> now. If there is a big demand for plural variants, they can be added later.
>
>
>> Can you tell me which numpy mailing list you will be posting to? I would
>> like to sign up so I can listen to the discussion.
>>
>
> There is only the one list- numpy-discussion
>
>
>> Have you thought about what you want to do with ufuncs?
>>
>
> ugh. We can't use __array_wrap__ because ufuncs do not provide an analogous
> hook for preprocessing input, only post-processing. Also, numpy segfaults
> when it is passed an ndarray subclass with out=None. I reported it to the
> numpy maililng list but didn't get a response.
>
> I think we need a more elegant way to handle ufuncs, using wrappers like is
> done in ma. There is a lot of repetitive stuff that needs to be done. For
> example, we need to make sure that if out is used, we are not attempting an
> operation that modifies the units in place unless out owns its own data.
> Also, passing magnitudes to the ufunc, or short-circuiting to the
> numpy.ufunc if quantities are not passed could be handled by wrapper code.
>
> I dont think its too important to address these remaining ufunc issues
> before requesting comments. Although, I think we need to implement
> concatenate and sqrt.
>
> One further thought: is there an easy way to generate a list of all the
>> units and constants with descriptions in the documentation? If so, I think
>> it would be useful to have on the doc page.
>>
>
> That would be useful. I'm not sure, I'll have to look into it.
>
> I noticed today that running setup.py install was doing an egg install on
> my computer at work, and that eric4 was not able to run scripts because of
> some issue with the egg. The scripts ran fine from the shell. I'm so sick of
> all the subtle problems associated with setuptools, and with setuptools lack
> of maintainance. Before making an announcement I'm going to remove support
> for setuptools and add support to run the tests the same way numpy and scipy
> does it.
>
> Darren
>
>
>> Best Regards,
>> John
>>
>> On Mon, Feb 9, 2009 at 12:41 PM, Darren Dale <dsdale24@xxxxxxxxx> wrote:
>>
>>> I added support for customizable default units today. Yesterday I did a
>>> bit of work to use numpy's sphinx extensions so we can pass through numpy's
>>> docstrings and document the API with sphinx, I changed the documentation
>>> decorator a little bit, extended the tutorial, implemented the regular
>>> expression to properly convert integer powers to unicode superscript
>>> characters, squashed a bunch of bugs, and there are some other improvements
>>> I'm forgetting at the moment. I posted some new snapshots at
>>> packages.python.org/quantities, please give them a try and let me know
>>> if you find any problems.
>>>
>>> I would like to post a request for comment at numpy discussion in the
>>> next couple of days. I dont think I'm going to make any more changes to the
>>> codebase for now, and I'm not planning to tag any new releases, but I need
>>> to put a page together discussing how the package is designed. When thats
>>> done, and the snapshots have seen some use, I'll make an announcement on the
>>> numpy mailing list, hopefully next monday.
>>>
>>> Darren
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
>>> Post to     : python-quantities-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~python-quantities-developers<https://launchpad.net/%7Epython-quantities-developers>
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>