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 the typing, pic
On Monday, March 31, 2014 9:33:54 PM UTC+5:30, Chris Angelico wrote:
> 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
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.
37 matches
Mail list logo
