Unexpected scientific notation

P

Paul McNett

One of my users has reported that my app is giving them scientific notation instead
of decimal notation for one specific value among many that display properly. I am
unable to reproduce on my end, and this is the first I've heard of anything like this
since the app's launch 2 years ago.

The app bundles python 2.5.2 using py2exe.

It displays '3E+1' instead of '30.0'.

As I can't reproduce I'm looking for an idea brainstorm of what could be causing
this. What would be choosing to display such a normal number in scientific notation?

Ideas?

Paul
 
P

Paul McNett

[Some day hopefully I'll remember to change the to: address to (e-mail address removed)
instead of the original sender. I always end up sending the first reply to the
sender, then going "oops, forgot to hit 'reply-all'", and sending another copy to the
list.]

Ben said:
As I understand it, the Python string formatting operations
<URL:http://docs.python.org/library/stdtypes.html#string-formatting>
use the operating system's C library to perform (some of?) the
formatting.

The different behaviours you see might therefore be caused by
different C libraries in the operating system.

To avoid these and related problems, I would avoid floating point
wherever possible and use the ‘Decimal’ type for representing decimal
numbers.

Thanks. I forgot to mention that all numbers are already instances of
decimal.Decimal, not float. As I mentioned in a prior message, they do go through a
locale.format() call to display the value.

Paul
 
P

Paul McNett

Ben said:
Paul McNett said:
[Some day hopefully I'll remember to change the to: address to
(e-mail address removed) instead of the original sender.

Even better: Take full advantage of the standards-compliant messages
from the list, by using the “Reply to list†function of your RFC
2369 compliant mail program. That way the message is sent to the
declared list posting address, without you having to change anything.

If your mail program still doesn't have such a function, over a decade
since RFC 2369 was written, lobby the vendor to add it. Or, in the
case of free software, act some way yourself (write code, pay someone
else to do so, or some other action) to have that function added for
everyone.

I remember taking advantage of that in KMail, before that program became unusably
bloated.

For Thunderbird (which I see you're using, Paul), the open bug report
is <URL:https://bugzilla.mozilla.org/show_bug.cgi?id=45715>.
Meanwhile, you can install an add-on to provide the function
<URL:http://www.juergen-ernst.de/addons/replytolist.html>.

Thanks; I'll follow up with those. In general I don't tend to use add-ons because I
have at least 3 computers I regularly use and it is a pain to keep them all
configured consistently.

I always end up sending the first reply to the sender, then going
"oops, forgot to hit reply-all'", and sending another copy to the
list.]

At least that's merely a minor inconvenience; easily rectified by
just sending the message again using the correct function.
Yep.


That's much better, of course, than the opposite situation which
exists on some misconfigured mailing lists: that a message sent using
the “Reply to sender†function, with content written in the
knowledge that only the original message's sender should be reading
it, instead ends up going to the mailing list. That damage can't be
undone.

Well, when you are a member of a public mailing list, replying to a thread, the
expectation is that you are replying to the list, so I happen to think the correct
behavior is the one you think is broken, because practicality beats purity. If I want
to send a private message to someone, I'll start a new mail to that person, or simply
copy/paste their email addy over the list address, but the most common case is that
someone intends to reply to the list.

But arguing about this here isn't going to change anything: opinions differ just like
tabs/spaces and bottom-post/top-post.

Thanks to the Python mailing list administrators for conforming to the
standards and not breaking the configuration like that!

Thanks to the Python mailing list volunteers for running such a well-oiled and
popular list!

Paul
 
P

Paul McNett

Ben said:
In cases like this, one side can simply be wrong :)

Best of luck getting your programs behaving as you want them to!

BTW, I agree with you that in an ideal, pure world mailing lists wouldn't munge the
reply-to field, but when 80% of the people use email clients that don't support
reply-list, the practical thing to do as a list admin that wants to avoid having to
explain over and over again that "your client software is broken" is to simply
swallow some pride and munge the reply-to. Now, 99% of the users are happy, and the
remaining 1% are elite enough to understand how to get around any problems this
caused. Happy is good.

Paul
 
T

Terry Reedy

S

Steven D'Aprano

BTW, I agree with you that in an ideal, pure world mailing lists
wouldn't munge the reply-to field, but when 80% of the people use email
clients that don't support reply-list, the practical thing to do as a
list admin that wants to avoid having to explain over and over again
that "your client software is broken" is to simply swallow some pride
and munge the reply-to. Now, 99% of the users are happy, and the
remaining 1% are elite enough to understand how to get around any
problems this caused.

The only problem this leads to is people who hit send without checking
where they are sending to are likely to be embarrassed when they send
personal posts to the entire mailing list.

As far as I'm concerned, hitting send without looking to see who you are
sending to is akin to turning into a busy road without looking to see if
there are any cars coming: any accident that happens is YOUR fault, not
the fault of the road, car, mail client or mailing list.

It boggles my brain that [insert sweeping generalisation here] the people
who are most vehement about blaming the mailing list software are usually
also the least understanding when (l)users click "OK" to dialogs without
reading what the dialog says first.
 
M

Mark Dickinson

It displays '3E+1' instead of '30.0'.

As I can't reproduce I'm looking for an idea brainstorm of what could be causing
this. What would be choosing to display such a normal number in scientific notation?

Ideas?

[I thought I replied to this earlier, but the post isn't showing up.
So here it is again.]

I suspect it's your use of the Decimal normalize() method that's
causing
this. Trailing zeros on Decimal instances are significant, so
Decimal('30.0'), Decimal('30') and Decimal('3E+1') are considered
distinct (though they all have the same value). The normalize method
strips all trailing zeros, turning Decimal('30.0') into Decimal('3E
+1').

One way to get around this is to add 0 after normalizing: this will
make sure that scientific notation is used only for very large
or small numbers, as usual.

Python 2.7a0 (trunk:68298:68318, Jan 6 2009, 10:39:14)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.Decimal('30.0')

Adding 0 also has the side-effect of turning a negative zero
into a positive zero, but I suspect that this isn't going to
worry you much. :)

You might also want to look at the Decimal.quantize method.

Mark
 
P

Paul McNett

Mark said:
It displays '3E+1' instead of '30.0'.

As I can't reproduce I'm looking for an idea brainstorm of what could be causing
this. What would be choosing to display such a normal number in scientific notation?

Ideas?

[I thought I replied to this earlier, but the post isn't showing up.
So here it is again.]
LOL!

I suspect it's your use of the Decimal normalize() method that's
causing
this. Trailing zeros on Decimal instances are significant, so
Decimal('30.0'), Decimal('30') and Decimal('3E+1') are considered
distinct (though they all have the same value). The normalize method
strips all trailing zeros, turning Decimal('30.0') into Decimal('3E
+1').

One way to get around this is to add 0 after normalizing: this will
make sure that scientific notation is used only for very large
or small numbers, as usual.

Thank you for the insight. I believe the problem is with my use of normalize(), but I
still can't figure out why I can't reproduce the issue in my running app. But I can
see in the interpreter that printing Decimal("30.0").normalize() results in "3E+1".

Paul
 
M

Mark Dickinson

Thank you for the insight. I believe the problem is with my use of normalize(), but I
still can't figure out why I can't reproduce the issue in my running app.

Me neither. In particular, I can't see how it could this output could
come out
of a locale.format call. Is it possible that your user is somehow
seeing a
direct str() or "%s" of a Decimal instance, rather than something
that's been
through a format method?

Mark
 
P

Paul McNett

Paul said:
Mark said:
It displays '3E+1' instead of '30.0'.

As I can't reproduce I'm looking for an idea brainstorm of what could
be causing
this. What would be choosing to display such a normal number in
scientific notation?

Ideas?

[I thought I replied to this earlier, but the post isn't showing up.
So here it is again.]

LOL!

I'll clarify my LOL: Mark initially replied to me directly, to which I responded
directly. Because he replied directly, I kept my response offline, too, not knowing
if he had a special reason to discuss this offline instead of in public.

Then he replied to the list, so I made a different response to the list.

Anyway, thanks again Mark for your guidance.

Paul
 
M

Mark Dickinson

I'll clarify my LOL: Mark initially replied to me directly, to which I responded
directly. Because he replied directly, I kept my response offline, too, not knowing
if he had a special reason to discuss this offline instead of in public.

Yup, definitely a special reason. Nothing to do with being
unable to distinguish between 'Reply' and 'Reply to author'.
Honest.

Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top