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
36 matches
Mail list logo