Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #69432 > unrolled thread

Code style query: multiple assignments in if/elif tree

Back to article view | Back to comp.lang.python

Contents

  Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 01:33 +1100
    Re: Code style query: multiple assignments in if/elif tree Marko Rauhamaa <marko@pacujo.net> - 2014-03-31 18:40 +0300
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 03:03 +1100
        Re: Code style query: multiple assignments in if/elif tree Rustom Mody <rustompmody@gmail.com> - 2014-03-31 09:20 -0700
          Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 03:29 +1100
            Re: Code style query: multiple assignments in if/elif tree "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-31 21:31 +0100
      Re: Code style query: multiple assignments in if/elif tree Ned Batchelder <ned@nedbatchelder.com> - 2014-03-31 17:42 -0400
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 09:50 +1100
      Re: Code style query: multiple assignments in if/elif tree Ben Finney <ben+python@benfinney.id.au> - 2014-04-01 09:57 +1100
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 10:12 +1100
        Re: Code style query: multiple assignments in if/elif tree Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-01 00:57 +0000
      Re: Code style query: multiple assignments in if/elif tree Ethan Furman <ethan@stoneleaf.us> - 2014-03-31 17:30 -0700
    Re: Code style query: multiple assignments in if/elif tree Steven D'Aprano <steve@pearwood.info> - 2014-04-01 04:26 +0000
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 16:01 +1100
        Re: Code style query: multiple assignments in if/elif tree Steven D'Aprano <steve@pearwood.info> - 2014-04-01 07:20 +0000
          Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 18:35 +1100
            Re: Code style query: multiple assignments in if/elif tree Steven D'Aprano <steve@pearwood.info> - 2014-04-01 08:07 +0000
              Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 19:12 +1100
          Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 02:18 -0600
          Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 02:24 -0600
      Re: Code style query: multiple assignments in if/elif tree Rustom Mody <rustompmody@gmail.com> - 2014-03-31 22:45 -0700
        Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 02:05 -0400
        Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 00:28 -0600
      Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 00:13 -0600
      Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 02:24 -0400
      Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 00:39 -0600
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 17:55 +1100
        Re: Code style query: multiple assignments in if/elif tree Steven D'Aprano <steve@pearwood.info> - 2014-04-01 07:29 +0000
          Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 18:49 +1100
          Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 02:29 -0600
          Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 19:56 +1100
      Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 03:21 -0400
      Re: Code style query: multiple assignments in if/elif tree Chris Angelico <rosuav@gmail.com> - 2014-04-01 18:26 +1100
      Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 03:34 -0400
      Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 03:39 -0400
      Re: Code style query: multiple assignments in if/elif tree David Hutto <dwightdhutto@gmail.com> - 2014-04-01 03:46 -0400
      Re: Code style query: multiple assignments in if/elif tree Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-01 02:55 -0600

Page 2 of 2 — ← Prev page 1 [2]

#69471

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 function. One advantage of a state variable rather than a
> continuous time function is that we can do this:
> def accel(state):
>     return {NO_BRAKING: 0.0,
>             LOW_BRAKING: 0.2,
>             MID_BRAKING: 0.425,
>             HIGH_BRAKING: 0.85}[state]

Neat
I would put the dict in a variable. And those _BRAKINGs are GALLing me!

breaking = {NO:0.0, LOW:0.2, MID:0.425:, HIGH:0.85}
def accel(state): return breaking[state]

<Irony>
In using Haskell, I often wish for dicts especially python's nifty
dict-literals
</Irony>

[toc] | [prev] | [next] | [standalone]

#69472

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 1, 2014 at 1:45 AM, Rustom Mody <rustompmody@gmail.com> 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 I were coding this, and I'm not, I'd wrap
> > it in a function. One advantage of a state variable rather than a
> > continuous time function is that we can do this:
> > def accel(state):
> >     return {NO_BRAKING: 0.0,
> >             LOW_BRAKING: 0.2,
> >             MID_BRAKING: 0.425,
> >             HIGH_BRAKING: 0.85}[state]
>
> Neat
> I would put the dict in a variable. And those _BRAKINGs are GALLing me!
>
> breaking = {NO:0.0, LOW:0.2, MID:0.425:, HIGH:0.85}
> def accel(state): return breaking[state]
>
> <Irony>
> In using Haskell, I often wish for dicts especially python's nifty
> dict-literals
> </Irony>
>
>
This still omits the viscosity(+-) of the enclosed, or exposed
track/environmental variables of the system in which the objects traveling.

http://www.synlube.com/viscosit.htm

> --
>


> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

[toc] | [prev] | [next] | [standalone]

#69475

On Mon, Mar 31, 2014 at 11:45 PM, Rustom Mody <rustompmody@gmail.com> 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 I were coding this, and I'm not, I'd wrap
>> it in a function. One advantage of a state variable rather than a
>> continuous time function is that we can do this:
>> def accel(state):
>>     return {NO_BRAKING: 0.0,
>>             LOW_BRAKING: 0.2,
>>             MID_BRAKING: 0.425,
>>             HIGH_BRAKING: 0.85}[state]
>
> Neat
> I would put the dict in a variable. And those _BRAKINGs are GALLing me!
>
> breaking = {NO:0.0, LOW:0.2, MID:0.425:, HIGH:0.85}
> def accel(state): return breaking[state]

If I were doing this in Python 3.4 I would be sorely tempted to use an
Enum for the state.  Then the acceleration could just be an attribute
(or method) of the state itself!

class BrakingState(Enum):
    no_braking = 0.0
    low_braking = 0.2
    mid_braking = 0.425
    high_braking = 0.85

    @property
    def acceleration(self):
        return self.value

>>> print(BrakingState.low_braking.acceleration)
0.2


Alternatively the __init__ method could set the acceleration directly
from the value(s) passed in, as in the Planet example:

https://docs.python.org/3/library/enum.html#planet

The problem I have with either of these approaches though is that if
two distinct states happen to have the same acceleration, they will be
considered aliases for the same state.  This is because the
acceleration value is doing double duty as a parameter of the state
and also as its identity.  Likewise in the Planet example, if a new
planet happened to have the same mass and radius as Jupiter, it would
be considered the same planet as Jupiter. I haven't managed to work
out a wholly satisfying way to avoid this.

[toc] | [prev] | [next] | [standalone]

#69473

On Mon, Mar 31, 2014 at 11:01 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 3:26 PM, Steven D'Aprano <steve@pearwood.info> 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 acceleration. The passengers will feel three quite
>> distinctive jerks, one when the brakes are first applied (which is
>> probably reasonable), then one at 1s, then again at 2s. That's not
>> comfortable by any stretch of the imagination.
>
> It actually is a smooth increase in deceleration, but I'm operating
> the simulator on a 1s period, so it's actually an average across the
> first second, and an average across the next second...

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 and t=1s.  You are
modeling it as a straight line segment.  However, it would actually be
part of a quadratic curve connecting the same points, convex upwards.
The line segment is short-cutting the curve between the two points.
The distance traveled is the integral of the curve, and it is easy to
see that the integral of the line segment is less than the integral of
the actual curve.


>> (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.

[toc] | [prev] | [next] | [standalone]

#69474

[Multipart message — attachments visible in raw view] — view raw

>
>
> >> (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 in a state of superfluidity, and in a
perfect state between itself, and it's traveling environment.


> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto

[toc] | [prev] | [next] | [standalone]

#69476

On Tue, Apr 1, 2014 at 12:24 AM, David Hutto <dwightdhutto@gmail.com> 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 accelerating at a for
>> time t.
>
>
> This assumes that the viscosity is in a state of superfluidity, and in a
> perfect state between itself, and it's traveling environment.

I fail to see how this is relevant.  I would assume that the amount of
friction is already modeled in the acceleration constants; if it were
zero then the brakes would be nonfunctional and the train would not be
able to accelerate or decelerate at all.  In any case, a change in
friction simply works out to a change in acceleration.  The equations
above still hold true.

[toc] | [prev] | [next] | [standalone]

#69477

On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly <ian.g.kelly@gmail.com> 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 and t=1s.  You are
> modeling it as a straight line segment.  However, it would actually be
> part of a quadratic curve connecting the same points, convex upwards.
> The line segment is short-cutting the curve between the two points.
> The distance traveled is the integral of the curve, and it is easy to
> see that the integral of the line segment is less than the integral of
> the actual curve.

.... great.

Okay. I never studied calculus, so this is beyond my expertise. Is
this going to make a majorly significant difference to the end result?
If so, I guess the code's going to have to be a whole lot more
sophisticated, which means I need to learn a whole lot more maths in
order to write it. And I'm still trying to find time to get familiar
with systemd (having jumped on the Upstart bandwagon and now find
myself backing a losing horse, if you'll forgive a mixed metaphor) and
Cython (just need an excuse for that one).

ChrisA

[toc] | [prev] | [next] | [standalone]

#69481

On Tue, 01 Apr 2014 17:55:32 +1100, Chris Angelico wrote:

> On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly <ian.g.kelly@gmail.com> 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,

We're talking deceleration, so it actually decreases linearly until it 
reaches minimum :-)


>> picture the velocity graph between, say, t=0 and t=1s.  You are
>> modeling it as a straight line segment.  However, it would actually be
>> part of a quadratic curve connecting the same points, convex upwards.

Concave upwards, since we're decelerating.


>> The line segment is short-cutting the curve between the two points. The
>> distance traveled is the integral of the curve, and it is easy to see
>> that the integral of the line segment is less than the integral of the
>> actual curve.

Integral of the line segment is greater than the integral of the actual 
curve. 


> .... great.
> 
> 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 is a difference, but for the purposes of the 
simulation it probably doesn't matter. If you were trying to land a 
spacecraft on Mars, that's a different story...


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#69486

On Tue, Apr 1, 2014 at 6:29 PM, Steven D'Aprano <steve@pearwood.info> 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 is a difference, but for the purposes of the
> simulation it probably doesn't matter. If you were trying to land a
> spacecraft on Mars, that's a different story...

I'm liking the idea of pretending it's linear acceleration. Our error
in the system is:

1) Distances are accurate to one meter at absolute best; and I
wouldn't guarantee that they're even that accurate.
2) The simulation will apply the brakes at some exact number of
seconds past its origin.
3) A human driver might well apply the brakes a couple of seconds too
soon, and then cruise at the curve's speed for a short distance before
actually reaching the curve.
4) A human driver might also apply the brakes too _late_, and there
are tolerances built into the curve speed limits to cater for this.
The train would rock a bit more than is desired, but it won't
instantly derail if it hits a 90km/h curve at 91km/h (which is how the
simulator treats it).

Add all that up, and the end result is unlikely to be accurate to
better than ten seconds - and that's being generous. Ultimately, this
would be for drawing up projected timetables, so it's not going to be
used at more than one-minute accuracy; although comparing two proposed
routes might technically make use of more accuracy than that ("we
could go around to the left of this, or to the right of it; which
would be the faster route?" "This one, by thirty seconds"), any
difference of less than a minute would really have to be called
"practically equal".

By the way, line speed (the maximum safe speed on straight track) is
400km/h, so your estimates involving a 320km/h bullet train are in the
right ballpark. Curves could be practically any speed between zero and
that, although one would hope there aren't any Kooyong Stations on the
route! (Just up [1] of the station [2] is a tram crossing, which for
decades has been so bumpy and messy that trains had to slow down to
about 10 or 20 kays to get through safely.)

ChrisA
[1] https://en.wikipedia.org/wiki/Rail_directions#United_Kingdom
[2] https://en.wikipedia.org/wiki/Kooyong_railway_station

[toc] | [prev] | [next] | [standalone]

#69493

On Tue, Apr 1, 2014 at 1:59 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> Given that, I have to question your figures:
>
>> 177.211111333333
>
>> compared to 177.26527800000002 calculated the rough way. That's not bad,
>> only about 5cm off! Effectively, your rough calculation was accurate to
>> one decimal place.
>
> As I noted the rough way should be an underestimate, so I'm not sure
> why it's an overestimate here.  That said, I don't see where either of
> us made a mistake.

And I realize now that this is also because the linear deceleration
assumption doesn't match the average deceleration stated in the
problem.  It actually decelerates faster and cuts under the t=1s and
t=2s points in the velocity graph, and therefore is actually a
slightly larger underestimate.

[toc] | [prev] | [next] | [standalone]

#69496

On Tue, Apr 1, 2014 at 7:29 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 1:59 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> Given that, I have to question your figures:
>>
>>> 177.211111333333
>>
>>> compared to 177.26527800000002 calculated the rough way. That's not bad,
>>> only about 5cm off! Effectively, your rough calculation was accurate to
>>> one decimal place.
>>
>> As I noted the rough way should be an underestimate, so I'm not sure
>> why it's an overestimate here.  That said, I don't see where either of
>> us made a mistake.
>
> And I realize now that this is also because the linear deceleration
> assumption doesn't match the average deceleration stated in the
> problem.  It actually decelerates faster and cuts under the t=1s and
> t=2s points in the velocity graph, and therefore is actually a
> slightly larger underestimate.

Okay... so... hmm.

I'm trying to wrap a fried brain around your post here, and I'm not
sure it covered it properly. It's like a tortilla with the meat
spilling out. (My analogies aren't much saner when I'm not brain
fried, trust me.)

The important part here is to work out exactly how fast we'll be going
at the end of two seconds of gentle braking (before the 0.85m/s/s bit
begins). If that velocity is exactly the initial speed minus 0.625
m/s/s, then the error won't accumulate, and it's just a slight
difference that's well within tolerance. But if that velocity is
higher or lower, then it's going to be significant; the initial speed
could be 111.1̅ m/s (line speed of 400 km/h), and at that speed, 0.1
m/s difference could make a visible difference to the distance
travelled (the difference between 111.0 and 111.1 m/s makes a 10m
difference in the distance to reach 90 km/h or 25 m/s). Although,
truth be told, that's probably still not *very* significant; it's 0.12
seconds of time difference.

The exact deceleration curve isn't significant; all that matters is
how far the train goes during that curve, and how much speed it loses.

ChrisA

[toc] | [prev] | [next] | [standalone]

#69479

[Multipart message — attachments visible in raw view] — view raw

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 during acceleration in relation to the
environment it travels within.

So the object has a starting point at which there is no equal, or opposing
force, as it begins to accelerate from a resting position(Newton: an object
will remain in motion, until acted upon  by an equal or opposite force, and
in this case the motion is propulsion of the object, or the newtons of
propulsion, until it is moving at the exact speed of the propulsion applied
to the object->Vo-V1, with 0 friction/viscosity during this timeframe).

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 "resting"
point initially, and either the environment, or the object can maneuver
their own viscosity in relation to the other.


On Tue, Apr 1, 2014 at 2:39 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> On Tue, Apr 1, 2014 at 12:24 AM, David Hutto <dwightdhutto@gmail.com>
> 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 accelerating at a for
> >> time t.
> >
> >
> > This assumes that the viscosity is in a state of superfluidity, and in a
> > perfect state between itself, and it's traveling environment.
>
> I fail to see how this is relevant.  I would assume that the amount of
> friction is already modeled in the acceleration constants; if it were
> zero then the brakes would be nonfunctional and the train would not be
> able to accelerate or decelerate at all.  In any case, a change in
> friction simply works out to a change in acceleration.  The equations
> above still hold true.
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

[toc] | [prev] | [next] | [standalone]

#69480

On Tue, Apr 1, 2014 at 6:21 PM, David Hutto <dwightdhutto@gmail.com> 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 "resting"
> point initially, and either the environment, or the object can maneuver
> their own viscosity in relation to the other.

The initial state, in this problem, is of a vehicle moving at a known
speed (an input to the formula; it's a variable, but one that we know
at that point). Friction, viscosity, etc, etc, etc are all handled
elsewhere; these trains are generally way overpowered, and the onboard
computer caps the power and non-emergency braking such that the change
in speed never exceeds 0.85 m/s/s. I don't know how exactly it goes
about that, but for the purposes of this test, we can assume that it's
able to achieve that acceleration.

ChrisA

[toc] | [prev] | [next] | [standalone]

#69482

[Multipart message — attachments visible in raw view] — view raw

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
position, to a velocity, and then regain orbit:

http://wiki.answers.com/Q/What_is_a_quantum_leap



On Tue, Apr 1, 2014 at 3:21 AM, David Hutto <dwightdhutto@gmail.com> wrote:

> 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 during acceleration in relation to the
> environment it travels within.
>
> So the object has a starting point at which there is no equal, or opposing
> force, as it begins to accelerate from a resting position(Newton: an object
> will remain in motion, until acted upon  by an equal or opposite force, and
> in this case the motion is propulsion of the object, or the newtons of
> propulsion, until it is moving at the exact speed of the propulsion applied
> to the object->Vo-V1, with 0 friction/viscosity during this timeframe).
>
> 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 "resting"
> point initially, and either the environment, or the object can maneuver
> their own viscosity in relation to the other.
>
>
> On Tue, Apr 1, 2014 at 2:39 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>
>> On Tue, Apr 1, 2014 at 12:24 AM, David Hutto <dwightdhutto@gmail.com>
>> 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 accelerating at a
>> for
>> >> time t.
>> >
>> >
>> > This assumes that the viscosity is in a state of superfluidity, and in a
>> > perfect state between itself, and it's traveling environment.
>>
>> I fail to see how this is relevant.  I would assume that the amount of
>> friction is already modeled in the acceleration constants; if it were
>> zero then the brakes would be nonfunctional and the train would not be
>> able to accelerate or decelerate at all.  In any case, a change in
>> friction simply works out to a change in acceleration.  The equations
>> above still hold true.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> <http://www.hitwebdevelopment.com>*
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

[toc] | [prev] | [next] | [standalone]

#69484

[Multipart message — attachments visible in raw view] — view raw

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 today's(what has been publicly released) manufacturing levels.


On Tue, Apr 1, 2014 at 3:34 AM, David Hutto <dwightdhutto@gmail.com> wrote:

> 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
> position, to a velocity, and then regain orbit:
>
> http://wiki.answers.com/Q/What_is_a_quantum_leap
>
>
>
> On Tue, Apr 1, 2014 at 3:21 AM, David Hutto <dwightdhutto@gmail.com>wrote:
>
>> 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 during acceleration in relation to the
>> environment it travels within.
>>
>> So the object has a starting point at which there is no equal, or
>> opposing force, as it begins to accelerate from a resting position(Newton:
>> an object will remain in motion, until acted upon  by an equal or opposite
>> force, and in this case the motion is propulsion of the object, or the
>> newtons of propulsion, until it is moving at the exact speed of the
>> propulsion applied to the object->Vo-V1, with 0 friction/viscosity during
>> this timeframe).
>>
>> 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
>> "resting" point initially, and either the environment, or the object can
>> maneuver their own viscosity in relation to the other.
>>
>>
>> On Tue, Apr 1, 2014 at 2:39 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>
>>> On Tue, Apr 1, 2014 at 12:24 AM, David Hutto <dwightdhutto@gmail.com>
>>> 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 accelerating at a
>>> for
>>> >> time t.
>>> >
>>> >
>>> > This assumes that the viscosity is in a state of superfluidity, and in
>>> a
>>> > perfect state between itself, and it's traveling environment.
>>>
>>> I fail to see how this is relevant.  I would assume that the amount of
>>> friction is already modeled in the acceleration constants; if it were
>>> zero then the brakes would be nonfunctional and the train would not be
>>> able to accelerate or decelerate at all.  In any case, a change in
>>> friction simply works out to a change in acceleration.  The equations
>>> above still hold true.
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>
>>
>>
>> --
>> Best Regards,
>> David Hutto
>> *CEO:* *http://www.hitwebdevelopment.com
>> <http://www.hitwebdevelopment.com>*
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> <http://www.hitwebdevelopment.com>*
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

[toc] | [prev] | [next] | [standalone]

#69485

[Multipart message — attachments visible in raw view] — view raw

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, in which during the time frames that can be sampled in hertz, as
it transitions to the higher shell level , and do those timeframes increase
or decrease in relation to the eV(electron volts) applied?


On Tue, Apr 1, 2014 at 3:39 AM, David Hutto <dwightdhutto@gmail.com> wrote:

> 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 today's(what has been publicly released) manufacturing levels.
>
>
> On Tue, Apr 1, 2014 at 3:34 AM, David Hutto <dwightdhutto@gmail.com>wrote:
>
>> 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
>> position, to a velocity, and then regain orbit:
>>
>> http://wiki.answers.com/Q/What_is_a_quantum_leap
>>
>>
>>
>> On Tue, Apr 1, 2014 at 3:21 AM, David Hutto <dwightdhutto@gmail.com>wrote:
>>
>>> 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 during acceleration in relation to the
>>> environment it travels within.
>>>
>>> So the object has a starting point at which there is no equal, or
>>> opposing force, as it begins to accelerate from a resting position(Newton:
>>> an object will remain in motion, until acted upon  by an equal or opposite
>>> force, and in this case the motion is propulsion of the object, or the
>>> newtons of propulsion, until it is moving at the exact speed of the
>>> propulsion applied to the object->Vo-V1, with 0 friction/viscosity during
>>> this timeframe).
>>>
>>> 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
>>> "resting" point initially, and either the environment, or the object can
>>> maneuver their own viscosity in relation to the other.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 2:39 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>>>
>>>> On Tue, Apr 1, 2014 at 12:24 AM, David Hutto <dwightdhutto@gmail.com>
>>>> 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 accelerating at a
>>>> for
>>>> >> time t.
>>>> >
>>>> >
>>>> > This assumes that the viscosity is in a state of superfluidity, and
>>>> in a
>>>> > perfect state between itself, and it's traveling environment.
>>>>
>>>> I fail to see how this is relevant.  I would assume that the amount of
>>>> friction is already modeled in the acceleration constants; if it were
>>>> zero then the brakes would be nonfunctional and the train would not be
>>>> able to accelerate or decelerate at all.  In any case, a change in
>>>> friction simply works out to a change in acceleration.  The equations
>>>> above still hold true.
>>>> --
>>>> https://mail.python.org/mailman/listinfo/python-list
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> David Hutto
>>> *CEO:* *http://www.hitwebdevelopment.com
>>> <http://www.hitwebdevelopment.com>*
>>>
>>
>>
>>
>> --
>> Best Regards,
>> David Hutto
>> *CEO:* *http://www.hitwebdevelopment.com
>> <http://www.hitwebdevelopment.com>*
>>
>
>
>
> --
> Best Regards,
> David Hutto
> *CEO:* *http://www.hitwebdevelopment.com
> <http://www.hitwebdevelopment.com>*
>



-- 
Best Regards,
David Hutto
*CEO:* *http://www.hitwebdevelopment.com <http://www.hitwebdevelopment.com>*

[toc] | [prev] | [next] | [standalone]

#69495

On Tue, Apr 1, 2014 at 12:55 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Apr 1, 2014 at 5:13 PM, Ian Kelly <ian.g.kelly@gmail.com> 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 and t=1s.  You are
>> modeling it as a straight line segment.  However, it would actually be
>> part of a quadratic curve connecting the same points, convex upwards.
>> The line segment is short-cutting the curve between the two points.
>> The distance traveled is the integral of the curve, and it is easy to
>> see that the integral of the line segment is less than the integral of
>> the actual curve.
>
> .... great.
>
> Okay. I never studied calculus, so this is beyond my expertise. Is
> this going to make a majorly significant difference to the end result?
> If so, I guess the code's going to have to be a whole lot more
> sophisticated, which means I need to learn a whole lot more maths in
> order to write it. And I'm still trying to find time to get familiar
> with systemd (having jumped on the Upstart bandwagon and now find
> myself backing a losing horse, if you'll forgive a mixed metaphor) and
> Cython (just need an excuse for that one).

Assuming the stated acceleration averages are correct, we can put an
upper bound on the error.  Draw a rectangle bounding the two
consecutive points on the velocity graph.  Given that the actual
velocity decreases monotonically (which should be a safe assumption),
that curve must be contained within this rectangle.  Given that the
deceleration also increases monotonically, we can also say that the
curve must be contained within the upper triangle of that rectangle,
as bisected by the straight line segment of the constant average
acceleration version.  The area of this triangle is 1s * 0.2 m/s / 2 =
0.1m.  The area of the same triangle between t=1s and t=2s is 1s *
0.425 m/s / 2= 0.2125 m.  Summing those, the upper bound for the error
is only 0.3125 m.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web