On Tue, Apr 1, 2014 at 7:29 PM, Ian Kelly wrote:
> On Tue, Apr 1, 2014 at 1:59 AM, Ian Kelly wrote:
>> Given that, I have to question your figures:
>>
>>> 177.2133
>>
>>> compared to 177.2652780002 calculated the rough way. That's not bad,
>>> only about 5cm off! Effectively, your rou
On Tue, Apr 1, 2014 at 12:55 AM, Chris Angelico wrote:
> On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly wrote:
>> Then your computation is incorrect and will systematically
>> underestimate the stopping distance. Assuming for simplicity that the
>> acceleration actually increases linearly until it re
On Tue, Apr 1, 2014 at 1:59 AM, Ian Kelly wrote:
> Given that, I have to question your figures:
>
>> 177.2133
>
>> compared to 177.2652780002 calculated the rough way. That's not bad,
>> only about 5cm off! Effectively, your rough calculation was accurate to
>> one decimal place.
>
> A
On Tue, Apr 1, 2014 at 2:18 AM, Ian Kelly wrote:
> The reason the velocity is different after 2 seconds is because the
> linear deceleration does not match the constraints of the problem. The
> average deceleration for the first second is not 0.2 m/s, and the
> average deceleration for the second
On Tue, Apr 1, 2014 at 1:35 AM, Chris Angelico wrote:
> On Tue, Apr 1, 2014 at 6:20 PM, Steven D'Aprano wrote:
>> 177.2133
>>
>> compared to 177.2652780002 calculated the rough way. That's not bad,
>> only about 5cm off! Effectively, your rough calculation was accurate to
>> one decim
On Tue, Apr 1, 2014 at 7:07 PM, Steven D'Aprano wrote:
> On Tue, 01 Apr 2014 18:35:52 +1100, Chris Angelico wrote:
>
>> Although remembering that v is
>> velocity is easier than remembering which of u and v is initial and
>> which is final.
>
> Which comes earlier in the alphabet? :-P
So why isn'
On Tue, 01 Apr 2014 18:35:52 +1100, Chris Angelico wrote:
> Although remembering that v is
> velocity is easier than remembering which of u and v is initial and
> which is final.
Which comes earlier in the alphabet? :-P
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Apr 1, 2014 at 6:29 PM, Steven D'Aprano wrote:
>> Okay. I never studied calculus, so this is beyond my expertise. Is this
>> going to make a majorly significant difference to the end result?
>
> I thought that there was a chance that there might be, but it turns out,
> not so much. There i
Notice that it says that laymans say it has a small state in progress,
instead of a large state of 'progress'...that's arrogance, it's just the
fact that it has a Vo->V1 state of progress. My question, which I haven't
looked up the latest research on, is does it have the conservation of
momentum, i
The link isn't to prove my ideology of what happens, it to show what you
might be thinking about, instead of how I feel about it...nth dimensional
dynamics/hyperspace taken out. Been out of this for a while due to medical
reasons, but try to keep up on the latest measurements/accumulated data
with
On Tue, Apr 1, 2014 at 6:20 PM, Steven D'Aprano wrote:
> On Tue, 01 Apr 2014 16:01:40 +1100, Chris Angelico wrote:
>
> [...]
>>> The scenario you describe has (effectively) infinite rate-of-change-of-
>>> acceleration, often called "jerk". (A jerk is a rapid change in
>>> acceleration.) Human comf
You would be assuming a quantum leap type theory, that the object has no
Vo->V1, it just adjusts to the constant immediately, instead of what I
would call the quantum leap,without other 'theories' involved, that it has
a classical physics type movement in which it can accelerate from a resting
posi
On Tue, 01 Apr 2014 17:55:32 +1100, Chris Angelico wrote:
> On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly wrote:
>> Then your computation is incorrect and will systematically
>> underestimate the stopping distance. Assuming for simplicity that the
>> acceleration actually increases linearly until it
On Tue, Apr 1, 2014 at 6:21 PM, David Hutto wrote:
> The difference in our opinions, seems to be that there is an initial resting
> state, and not at an already accelerated motion that has reached it's
> maximum capacity.
>
>
> So there is a dynamic in my mind's eye, where the object is at a "rest
On Tue, 01 Apr 2014 16:01:40 +1100, Chris Angelico wrote:
[...]
>> The scenario you describe has (effectively) infinite rate-of-change-of-
>> acceleration, often called "jerk". (A jerk is a rapid change in
>> acceleration.) Human comfort is (within reasonable limits) more
>> affected by jerk than
u is the initial velocity from a starting/resting point, not a static speed
at that point, and begins to accelerate,
over a particular timeframe, in which it's momentum is not stopped by
friction on which the rails/environment it travels upon has, or the similar
properties the object might have dur
On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly wrote:
> Then your computation is incorrect and will systematically
> underestimate the stopping distance. Assuming for simplicity that the
> acceleration actually increases linearly until it reaches maximum,
> picture the velocity graph between, say, t=0
On Tue, Apr 1, 2014 at 12:24 AM, David Hutto wrote:
>>
>> >> (1) v = u + at
>> >> (2) s = 1/2(u + v)t
>> >> (3) s = ut + 1/2(at^2)
>> >> (4) v^2 = u^2 + 2as
>> >>
>> >> Only (1) and (3) are needed.
>> >
>> > Okay, what's u here? Heh.
>>
>> u is the initial velocity; v is the velocity after acceler
On Mon, Mar 31, 2014 at 11:45 PM, Rustom Mody wrote:
> On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano wrote:
>
>> Haskell has nifty pattern-matching syntax for this that looks quite close
>> to the mathematical hybrid function syntax, but in Python, we're limited
>> to explicitly using an if. If
>
>
> >> (1) v = u + at
> >> (2) s = 1/2(u + v)t
> >> (3) s = ut + 1/2(at^2)
> >> (4) v^2 = u^2 + 2as
> >>
> >> Only (1) and (3) are needed.
> >
> > Okay, what's u here? Heh.
>
> u is the initial velocity; v is the velocity after accelerating at a for
> time t.
>
This assumes that the viscosity is
On Mon, Mar 31, 2014 at 11:01 PM, Chris Angelico wrote:
> On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano wrote:
>> The scenario you describe has (effectively) infinite rate-of-change-of-
>> acceleration, often called "jerk". (A jerk is a rapid change in
>> acceleration.) Human comfort is (within
On Tue, Apr 1, 2014 at 1:45 AM, Rustom Mody wrote:
> On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano wrote:
>
> > Haskell has nifty pattern-matching syntax for this that looks quite close
> > to the mathematical hybrid function syntax, but in Python, we're limited
> > to explicitly using an if.
On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano wrote:
> Haskell has nifty pattern-matching syntax for this that looks quite close
> to the mathematical hybrid function syntax, but in Python, we're limited
> to explicitly using an if. If I were coding this, and I'm not, I'd wrap
> it in a functio
On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano wrote:
> On Tue, 01 Apr 2014 01:33:09 +1100, Chris Angelico wrote:
>
>> Call this a code review request, if you like. I'm wondering how you'd go
>> about coding something like this.
>
> I wouldn't. I'd start off by analysing the problem, and putting
On Tue, 01 Apr 2014 01:33:09 +1100, Chris Angelico wrote:
> Call this a code review request, if you like. I'm wondering how you'd go
> about coding something like this.
I wouldn't. I'd start off by analysing the problem, and putting it into
the simplest format possible, and *then* start writing
On Tue, 01 Apr 2014 10:12:38 +1100, Chris Angelico wrote:
[...]
>> I agree with others that triple-quoted strings are best reserved for
>> string literals (including docstrings), not comments.
>
> Fair enough. I can't remember where (or when!) it was that I learned
> triple-quoted strings were app
On 03/31/2014 04:12 PM, Chris Angelico wrote:
On Tue, Apr 1, 2014 at 9:57 AM, Ben Finney wrote:
Chris Angelico writes:
How do you go about doing multi-line comments? I know I've seen other
code using triple-quoted strings for long comments before.
Just use a sequence of one-line comments::
On Tue, Apr 1, 2014 at 9:57 AM, Ben Finney wrote:
> Chris Angelico writes:
>
>> How do you go about doing multi-line comments? I know I've seen other
>> code using triple-quoted strings for long comments before.
>
> Just use a sequence of one-line comments::
>
> # Lorem ipsum dolor sit amet,
Chris Angelico writes:
> How do you go about doing multi-line comments? I know I've seen other
> code using triple-quoted strings for long comments before.
Just use a sequence of one-line comments::
# Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut a
# sapien tempor, suscipi
On Tue, Apr 1, 2014 at 8:42 AM, Ned Batchelder wrote:
> On 3/31/14 12:03 PM, Chris Angelico wrote:
>>
>> Incidentally, if you want to see the code in context, it's here:
>>
>> https://github.com/Rosuav/runningtime/blob/master/runningtime.py
>>
>> ChrisA
>
>
> I know you didn't ask about these aspe
On 3/31/14 12:03 PM, Chris Angelico wrote:
Incidentally, if you want to see the code in context, it's here:
https://github.com/Rosuav/runningtime/blob/master/runningtime.py
ChrisA
I know you didn't ask about these aspects, but they jumped out at me:
tabs for indentation instead of spaces, an
On Mon, 31 Mar 2014 17:29:54 +0100, Chris Angelico
wrote:
On Tue, Apr 1, 2014 at 3:20 AM, Rustom Mody
wrote:
On the whole I prefer multiple assignments.
Maybe in this case use small variable names with
separate(d) explanatory comments??
Shorter variable names would certainly be the more
On Tue, Apr 1, 2014 at 3:20 AM, Rustom Mody wrote:
> On the whole I prefer multiple assignments.
> Maybe in this case use small variable names with
> separate(d) explanatory comments??
Shorter variable names would certainly be the more normal, heh. I let
my brother do that part of t
sn't simplify
> it any, all you've done is break it across more lines.
Not answering your original question but the above comment
Your version was sufficiently garbled indentation-wise (it may give you sweet
pleasure to know my 'client' is GG) that I gave up on reading it.
Mar
On Tue, Apr 1, 2014 at 2:40 AM, Marko Rauhamaa wrote:
> As a simple layout question, I'd do it like this:
>
>
> if mode == "Brake2":
> # Already got the brakes fully on
> distance_to_full_braking_power = 0.0
> spe
Chris Angelico :
> Call this a code review request, if you like. I'm wondering how you'd
> go about coding something like this.
As a simple layout question, I'd do it like this:
if mode == "Brake2":
# Already got the br
Call this a code review request, if you like. I'm wondering how you'd
go about coding something like this.
Imagine you're in a train, and the brakes don't apply instantly. The
definition, in the interests of passenger comfort, is that the first
second of brake application has an acceleration of 0.
On Wed, Oct 13, 2010 at 3:53 PM, Ethan Furman wrote:
> Ian Kelly wrote:
>
>> here is an example
>> where the order of assignment actually matters:
>>
>> >>> d['a'] = d = {}
>> Traceback (most recent call last):
>> File "", line 1, in
>> NameError: name 'd' is not defined
>> >>> d = d['a'] =
Ethan Furman writes:
> Ah! I was thinking the assignments went in a filter fashion, but now
> what I think is happening is that the first item is bound to the last,
> then the next item is bound to the last, etc, etc.
>
> Is this correct?
Assignment is always the same direction: the rightmost o
Ian Kelly wrote:
here is an example
where the order of assignment actually matters:
>>> d['a'] = d = {}
Traceback (most recent call last):
File "", line 1, in
NameError: name 'd' is not defined
>>> d = d['a'] = {}
>>> d
{'a': {...}}
As you can see, they're assigned left-to-right.
Ah!
On Sat, 20 Dec 2008, John O'Hagan wrote:
> On Sat, 20 Dec 2008, Terry Reedy wrote:
> > John O'Hagan wrote:
> > > I have a lot of repetitive assignments to make, within a generator,
> > > that use a function outside the generator:
> > >
> > > var1 = func("var1", args)
> > > var2 = func("var2", args)
On Dec 19, 11:34 pm, John O'Hagan wrote:
> I have a lot of repetitive assignments to make, within a generator, that use a
> function outside the generator:
>
> var1 = func("var1", args)
> var2 = func("var2", args)
> var3 = func("var3", args)
> etc...
>
> In each case the args are identical, but th
On Sat, 20 Dec 2008, Terry Reedy wrote:
> John O'Hagan wrote:
> > I have a lot of repetitive assignments to make, within a generator, that
> > use a function outside the generator:
> >
> > var1 = func("var1", args)
> > var2 = func("var2", args)
> > var3 = func("var3", args)
> > etc...
> >
> > In ea
On Sat, 20 Dec 2008, Steven D'Aprano wrote:
> On Sat, 20 Dec 2008 02:53:16 +, MRAB wrote:
> > If you're sure you want to use the current namespace then:
> >
> > for name in namelist:
> > vars()[name] = func(name, args)
>
> Doesn't work inside a function:
> >>> def parrot():
>
> ..
On Sat, 20 Dec 2008, Arnaud Delobelle wrote:
> John O'Hagan writes:
> > I have a lot of repetitive assignments to make, within a generator,
> > that use a function outside the generator:
> >
> > var1 = func("var1", args)
> > var2 = func("var2", args)
> > var3 = func("var3", args)
> > etc...
> >
>
John O'Hagan writes:
> I have a lot of repetitive assignments to make, within a generator,
> that use a function outside the generator:
>
> var1 = func("var1", args)
> var2 = func("var2", args)
> var3 = func("var3", args)
> etc...
>
> In each case the args are identical, but the first argument is
On Sat, 20 Dec 2008 02:53:16 +, MRAB wrote:
> If you're sure you want to use the current namespace then:
>
> for name in namelist:
> vars()[name] = func(name, args)
Doesn't work inside a function:
>>> def parrot():
... for name in ['A', 'B', 'C']:
... vars()[na
Terry Reedy wrote:
John O'Hagan wrote:
I have a lot of repetitive assignments to make, within a generator,
that use a function outside the generator:
var1 = func("var1", args)
var2 = func("var2", args)
var3 = func("var3", args)
etc...
In each case the args are identical, but the first argumen
John O'Hagan wrote:
I have a lot of repetitive assignments to make, within a generator, that use a
function outside the generator:
var1 = func("var1", args)
var2 = func("var2", args)
var3 = func("var3", args)
etc...
In each case the args are identical, but the first argument is a string of the
I have a lot of repetitive assignments to make, within a generator, that use a
function outside the generator:
var1 = func("var1", args)
var2 = func("var2", args)
var3 = func("var3", args)
etc...
In each case the args are identical, but the first argument is a string of the
name being assigned.
Thank you George Sakkis for your fast and accurate answer. In my life I
am encountering lot of graph-based solutions to my problems. I'll try
to implement your solution as soon as possible.
Fredrik Lundh>working on a Python to C/C++ translator without knowing
what kind of optimizations a C/C++ co
[EMAIL PROTECTED] wrote:
> I don't know if C++ compilers can do such optimizations.
working on a Python to C/C++ translator without knowing what kind
of optimizations a C/C++ compiler can do for you sounds like a great
way to waste your time...
(I would be rather bit surprised if any contemporar
<[EMAIL PROTECTED]> wrote:
> [snipped]
>
> Do you know some algorithm (or you can give some suggestions) to
> minimize the number of simple assignments needed for a "regular"
> situation like that?
You can formulate the task as a graph-theoretic problem by representing the set
of assignments as
The current version of ShedSkin (http://shedskin.sourceforge.net/
experimental Python to C++ compiler) is rather alpha, and the
development work is focused on debugging and implementing some more
basic Python functionality. But hopefully in future versions more work
will be spent to make the result
54 matches
Mail list logo
