On 04/16/2015 07:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction(1.64)
Fraction(41, 25)
41/25
1.64
On Apr 16, 2015 1:52 AM, Danny Yoo danny@gmail.com wrote:
On Apr 16, 2015 1:32 AM, Jim Mooney cybervigila...@gmail.com wrote:
Why does Fraction interpret a number and string so differently? They
come
out the same, but it seems rather odd
from fractions import Fraction
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction(1.64)
Fraction(41, 25)
41/25
1.64
738590337613 / 4503599627370496
1.64
--
boB Stepp wrote:
import Tkinter as tk
Question: I have been using from Tkinter import * as suggested in
Programming Python by Lutz. He remarks that unlike other situations,
this is generally safe with Tkinter. Is there a benefit to doing the
import as you have?
It's a stylistic
On Apr 16, 2015 1:32 AM, Jim Mooney cybervigila...@gmail.com wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction(1.64)
On 04/15/2015 08:21 PM, Alan Gauld wrote:
On 16/04/15 00:47, Ken G. wrote:
I just emailed that I was unable to correct a message in ModTools
so I went to Yahoo and made the change and then approved it.
What is ModTools? What kind of message?
Where does Yahoo fit in?
What does any of it
On 04/16/2015 08:11 AM, Dave Angel wrote:
On 04/16/2015 01:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
On 04/16/2015 01:03 AM, Jim Mooney wrote:
Why does Fraction interpret a number and string so differently? They come
out the same, but it seems rather odd
from fractions import Fraction
Fraction(1.64)
Fraction(738590337613, 4503599627370496)
Fraction(1.64)
Fraction(41, 25)
41/25
1.64
On 04/15/2015 08:45 PM, Dave Angel wrote:
On 04/15/2015 07:47 PM, Ken G. wrote:
I just emailed that I was unable to correct a message in ModTools
so I went to Yahoo and made the change and then approved it.
Noticing it did not appear on the list, I checked the Activity Log
in Yahoo and it
On 16/04/15 11:00, Ali Moradi wrote:
Hi, i want to load a bunch of words from my database into the listbox in
Tkinter, make them clickable, and when i clicked on them the specific
meaning of that word apears in a textbox beside the listbox.
i have a code but it's not complete. i'm a beginner in
As I go through my current coding project(s) I find myself breaking
functions down into other functions, especially when I see see
(unnecessarily) duplicated code fragments. I understand this to be
regarded as good practice. However, I am wondering if I am carrying
things too far? For instance I
On Thu, Apr 16, 2015 at 01:52:51AM -0700, Danny Yoo wrote:
It's this last supposition that should be treated most seriously. Most
computers use floating point, a representation of numbers that use a
fixed set of bits. This uniformity allows floating point math to be
implemented quickly.
Hi, i want to load a bunch of words from my database into the listbox in
Tkinter, make them clickable, and when i clicked on them the specific
meaning of that word apears in a textbox beside the listbox.
i have a code but it's not complete. i'm a beginner in Python :(
code:
#!/bin/python
from
My current understanding of function length best practice is that: 1)
Each function should have preferably ONE clearly defined purpose.
Purpose is the biggest factor for me.
2) I have seen varying recommendations as to number of lines of code per
function,
I don't weight this as heavily.
On 16/04/15 17:47, boB Stepp wrote:
things too far? For instance I have a collection of functions that do
simple units conversions such as:
def percent2Gy(dose_percent, target_dose_cGy):
Convert a dose given as a percent of target dose into Gy (Gray).
dose_Gy =
On 16.04.2015 19:24, Jim Mooney wrote:
Understood about the quondam inexactness of floating point bit
representation. I was just wondering why the different implementation of
representing it when using Fraction(float) as opposed to using
Fraction(string(float)). In terms of user presentation,
On Apr 16, 2015 1:42 PM, Jim Mooney cybervigila...@gmail.com wrote:
Understood about the quondam inexactness of floating point bit
representation. I was just wondering why the different implementation of
representing it when using Fraction(float) as opposed to using
Fraction(string(float)).
boB Stepp robertvst...@gmail.com writes:
My current understanding of function length best practice is that: 1)
Each function should have preferably ONE clearly defined purpose.
Yes, that's a principle to follow firmly, improving the design every
time. I know of no exceptions.
“Clearly
Is this inaccurate? Well, in the sense that it is not the exact true
mathematical result, yes it is, but that term can be misleading if you
think of it as a mistake. In another sense, it's not inaccurate, it is
as accurate as possible (given the limitation of only having a certain
fixed
The whole point of the discussion is that this is *not* a presentation
issue. Fraction(1.64) and Fraction(1.64) *are* two different numbers
because one gets constructed from a value that is not quite 1.64.
Wolfgang Maier
--
So the longer numerator and denominator would, indeed, be more accurate
On Thu, Apr 16, 2015 at 03:11:59PM -0700, Jim Mooney wrote:
So the longer numerator and denominator would, indeed, be more accurate if
used in certain calculations rather than being normalized to a float - such
as in a Fortran subroutine or perhaps if exported to a machine with a
longer
On 16/04/2015 17:47, boB Stepp wrote:
As I go through my current coding project(s) I find myself breaking
functions down into other functions, especially when I see see
(unnecessarily) duplicated code fragments. I understand this to be
regarded as good practice. However, I am wondering if I am
On 04/16/2015 01:24 PM, Jim Mooney wrote:
Is this inaccurate? Well, in the sense that it is not the exact true
mathematical result, yes it is, but that term can be misleading if you
think of it as a mistake. In another sense, it's not inaccurate, it is
as accurate as possible (given the
On 16/04/2015 23:40, Alan Gauld wrote:
On 16/04/15 22:03, Alan Gauld wrote:
def percent2Gy(dose_percent, target_dose_cGy):
Convert a dose given as a percent of target dose into Gy (Gray).
dose_Gy = cGy2Gy((dose_percent / 100.0) * target_dose_cGy)
return dose_Gy
Note
On 16/04/15 22:03, Alan Gauld wrote:
def percent2Gy(dose_percent, target_dose_cGy):
Convert a dose given as a percent of target dose into Gy (Gray).
dose_Gy = cGy2Gy((dose_percent / 100.0) * target_dose_cGy)
return dose_Gy
Note in this case you could just create an
boB Stepp wrote:
As I go through my current coding project(s) I find myself breaking
functions down into other functions, especially when I see see
(unnecessarily) duplicated code fragments. I understand this to be
regarded as good practice. However, I am wondering if I am carrying
things
26 matches
Mail list logo
