slightlynybbled / engineering_notation Goto Github PK

numpy int64 not compatible?

Apologies that I am posting this here. Wish I could have posted it on Discussion though.

Description:

Will you be introducing a sub-class (or another class) where I do not print the quantity in character form. But rather in exponent (scientific) form.
Example

EngNumber(37112.1231233123, precision = 4)

returns

37.1121k

can it return this instead?

37.1121E+03

Motivation:

We are printing the return numbers in an excel sheet (extracted from DataFrame). And when printed in excel, preferably the character doesn't mix with the numbers, else it will turn the cell into string in Excel. Hence, getting rid of the character will be very useful for Excel users.

I have a solution which derived from here. But was just thinking it will be more elegant if it comes from this package

Example:

>>> d0 = EngNumber('10k')
>>> print(d0)
10k
>>> print(d0.unit)
None
>>> d1 = EngNumber('10kHz')
>>> print(d1)
10kHz
>>> print(d1.unit)
Hz

Add femto, atto, zepto, and yocto per user request.

https://en.wikipedia.org/wiki/Engineering_notation

Not sure if this is fundamental limitation that is easy to fix or not but get this error when trying to use EngNumber with pandas dataframe constructors. Workaround I have is to use float(eng_number_variable) with modules that dont work natively with EngNumber datatype so still really like engineering_notation module. Thanks for the useful module.

Current implementation has the fault that the suffix for engineering notation could conceivably be confused for the unit:

>>> eu = EngUnit('2meter`)
>>> float(eu)
0.002
>>> eu.unit
eter

Add option for a space between the numeric and the unit:

>>> eu = EngUnit('2 meter`)
>>> float(eu)
2.0
>>> eu.unit
meter

The default formatting method is precision, which is the digits after the decimal point, but it leads to different levels of details of different numbers. Let's say, if we set precision=0, the number 4.23195e-4 and 4.23195e-3 will become:

423u

and

4m

correspondingly. This is very confused on some kinds of data.

What I prefer is to print the numbers by significant digits, like:

>>> eng = lambda x: EngNumber(x, significant=3)
>>> eng(4.23195e-4)
'423u'
>>> eng(4.23195e-3)
'4.23m'

Just want to start off by saying, very useful module, thanks for developing!

It would be slightly more useful for me if there were some facility to have a space between the number and the SI prefix.
So instead of printing 2.39G, I'd be able to get 2.39 G.

The motivation: I'm currently using the module to generate reports of calculations of network bandwidth, and it's a style thing in my organisation to have a space after the number and before the unit:

The total network bandwidth consumed is 2.39 Gb/s.

for instance.

After a quick eyeball of the code, I think I could probably add the functionality. Would you consider a PR?

User reported a bug:

I have noticed that with significant=3 I occasionally see "1000fA" displayed, which presumably was rounding up from 999.xnA where x>=5

Need to investigate and disposition.

In setup.py, include the long_description_content_type=text/markdown line.

What I'd like is to instantiate EngUnit using a number (passed from elsewhere in my program), and a string. Right now there are multiple possible workarounds, so this is more of a quality of life request.

For example:

num = 3.53e-4
eng = EngUnit(num, 's')
print(eng)  # prints 3.53us

Possible workarounds:

# this one is fine, but doesn't work inline, say, in function argument or list comprehension
num = 3.53e-4
eng = EngUnit(num)
eng.unit = 's'
print(eng)

# shudder
num = 3.53e-4
eng = EngUnit(str(num) + 's')
print(eng)

This is fine:

x=0.10000000149011612;x = engineering_notation.EngNumber(x); print(x)
100m
This is not:
x=0.10000000149011612;x = engineering_notation.EngNumber(x,precision=3); print(x)
100.m
This is fine:
x=0.10000000149011612;x = engineering_notation.EngNumber(x,precision=2); print(x)
100m
This is fine:
x=0.10000000149011612;x = engineering_notation.EngNumber(x,precision=4); print(x)
100.0m

I consider this a bug, as it's not typical to leave a trailing decimal. What do you think?
Also, I think the significant figure approach suggested in another issue is mathematically more useful.

Hi!

This is a really useful package for me that work in automated test equipment.
One really good feature would be the hability to fix not only the precision but also the quantity of number before de decimal point so we can control completely the number of output characters when working with serial terminals:

EngNumber('4.999k', precision=3, significant = 3,padding = '0')
004.999k

EngNumber('4.999k', precision=2, significant = 2,padding = '0')
04.99k

Padding with spaces would be the most useful for me.

That would be great!

Anecdotally, the negative numbers already work correctly, but I would like to make sure.

Thanks for this tool. It does basically what we need.

In the Electronics world, it is very common to use the "R notation" where the decimal separator gets replaced by the prefix. You can read more about it here: https://en.wikipedia.org/wiki/RKM_code

This is the behaviour we would desire:

>>> EngNumber('2k2')
2.20k
>>> EngUnit('4u7F')
4.70uF
>>> EngUnit('2R2')
2.20R

Would it be possible to add this capability?

Thanks!