Vectors in Visual Python

[FLChamp]

SOrry if this message is a little confused, it most probably reflects
the state of the author!

I have made a small program that plots the orbit of a planet in visual
python using visual.vector for all values. If i run the program it is
clear that the orbit is non-keplerian as the planets gradually moves
away from the sun. I am pretty sure the orbit should be keplerian so i
guess there must be some source of error in the program.

I am using "from __future__ import division" and the initial conditions
I have are from NASA's horizons system, all values are accuracte to
more than 10 decimal places.

I was wondering if there was a way to specify the type of number used
by visual.vector, for example, when using an array it is possible to
specify the type as float64. If visual.vector was using a smaller
amount of memory to store the number could this be the source of the
error I am finding? If not what else could be the culprit?

I have used a 4th order RK method which I have previously produced
Keplerian orbits with.

I hope I have made some sense here and look forward to any input

Many Thanks

Ben

 

[Arthur]

SOrry if this message is a little confused, it most probably reflects
the state of the author!

One bit of confusion is in names. There was a name space clash early
on. As things shook out "Visual Python" is ActiveState's Python
developement environment for Visual Studio .Net
http://www.activestate.com/Products/Visual_Python/
and the 3d programming environmnet to which you question refers
became " VPython". Just a point of information. Certainly no great
confusion in the context of your question, but there could be in other
contexts.

I have made a small program that plots the orbit of a planet in visual
python using visual.vector for all values. If i run the program it is
clear that the orbit is non-keplerian as the planets gradually moves
away from the sun. I am pretty sure the orbit should be keplerian so i
guess there must be some source of error in the program.

I am using "from __future__ import division" and the initial conditions
I have are from NASA's horizons system, all values are accuracte to
more than 10 decimal places.

I was wondering if there was a way to specify the type of number used
by visual.vector, for example, when using an array it is possible to
specify the type as float64. If visual.vector was using a smaller
amount of memory to store the number could this be the source of the
error I am finding? If not what else could be the culprit?

My understanding:

is that VPython "vectors" are in effect flat 3 element Numeric arrays,
and Numeric ararys can be constructed with Float64 specified as the
datatype. (wonder if that speciufication is a "declaration", and if
so whether that would indicate some conflict between Python's ideology
(Alex's version) and that of its defacto standard numerical processing
library - but I digress) .

Have you tried feeding the VPython the vectors, arrays declared as
Float64 types.

May, or may not, get you somewhere.

Art

 

[Terry Reedy]

is that VPython "vectors" are in effect flat 3 element Numeric arrays,
and Numeric ararys can be constructed with Float64 specified as the
datatype. (wonder if that speciufication is a "declaration", and if
so whether that would indicate some conflict between Python's ideology
(Alex's version) and that of its defacto standard numerical processing
library - but I digress) .

I (and I believe Alex) object to name declaration *statements* and/or the
strong typing of *names*.

I (and I believe Alex) approve of the strong typing of *objects*, which
must somehow be indicated in the object creation *expression*. This is
absolutely fundamental to Python. There are at least three ways to
indicate the desired object type: literal type, constuctor (and other
function) identity, and constructor (and other function) arguments.

When constructor arguments only specifiy the type of members of a
homogeneous collection object, the visible type() of the collection itself
may not be affected. I believe member type specifications for numerical
and num- arrays are like this, as they are for stdlib array.arrays.

Sorry, no conflict ;-)

Terry J. Reedy

 

[Alex Martelli]

is that VPython "vectors" are in effect flat 3 element Numeric arrays,
and Numeric ararys can be constructed with Float64 specified as the
datatype. (wonder if that speciufication is a "declaration", and if
so whether that would indicate some conflict between Python's ideology
(Alex's version) and that of its defacto standard numerical processing
library - but I digress) .

That ``speciufication'' (sic) is no more ``a "declaration"'' than any
other parameter you can pass to a constructor (or any other factory
callable). I find it hard to believe that this can be less than
totally, entirely, and utterly obvious to anybody with a 3-digits IQ.


Trying to subdivide the issue into sub-issues that I hope will be pretty
obvious even for most 2-digits IQs...:

I can pass parameters when I call something -- do you think ``that's a
declaration''?!

Some of the calls I perform build and return new objects -- do you
REALLY think ``that's a declaration''?!

Obviously, the parameters I pass will normally affect the results of my
calls -- do you TRULY, SERIOUSLKY think ``that's a declaration''?!

*WHAT ON EARTH* could *POSSIBLY* make you "wonder" if any of these
aspects make a perfectly ordinary executable statement into what's
instead ``a declaration''?!?!


Please clarify if you were making a lame joke without smilies, are
utterly confused about what "declaration" *MEANS*, or what other folly
prompted you to this astounding remark, thanks. Having found out how to
build a lasting killfile, I'd like to see if using it liberally on
people who appear to post here just to provoke flamewars, rather than to
offer and receive help, and participate in interesting discussion, can
make the newsgroup decently usable to me again. It's a pity that any
newbie reading the group will be confused and damaged by tons of
unchallenged idiocies posted there by large number of fools, but, ah
well, I can't fix that, obviously -- I can just hope and trust that the
fools' karma suffers in proportion to the stupid harm they inflict.


Alex

 

[Alex Martelli]

I (and I believe Alex) object to name declaration *statements* and/or the
strong typing of *names*.

I confirm that my key objection is to declarations in the strict sense:
thingies that aren't executable, but rather billets doux to the
compiler, for example to affect its treatment of barenames.

I (and I believe Alex) approve of the strong typing of *objects*, which

Absolute and unqualified agreement on this point, yes.

must somehow be indicated in the object creation *expression*. This is
absolutely fundamental to Python. There are at least three ways to
indicate the desired object type: literal type, constuctor (and other
function) identity, and constructor (and other function) arguments.

And yes to all of this, as well.


Alex

 

[Arthur]

Please clarify if you were making a lame joke without smilies, are
utterly confused about what "declaration" *MEANS*, or what other folly
prompted you to this astounding remark, thanks.

Interesting pedagogical technique all-in-all Mr. Martelli.

What point is there in trying to help you understand the basis of my
confusion, if my confusion is nothing more than a point of ridicule.

I know exactly what "declaration" is - a fucking word, nothing more
nothing less.

Art

 

[Arthur]

Having found out how to
build a lasting killfile, I'd like to see if using it liberally on
people who appear to post here just to provoke flamewars, rather than to
offer and receive help, and participate in interesting discussion, can

You are an accomplished provocateur.

It is true that I joined the variable declaration discussion without
the intent of offering or receiving help. I joined it actually to try
to make a point that I thought was community spirited -
thinking that the visciousness with wihich you were attacking someone
suggesting a proposal for an optional feature - even if an iill
adivised proposal for and ill advised optional feature (I frankly
don't care much about that part of the discussion one way or another)
- was unwarranted, and more importantly *unwise* for someone in a
postion of community leadership - considering past, recent, and
undoubtedly future issues that have and will arise.

What don't *you* understand about that??

We all have are own kinds of stupidities, it seems to me.

Art

 

[Alex Martelli]

thinking that the visciousness with wihich you were attacking someone
suggesting a proposal for an optional feature - even if an iill
adivised proposal for and ill advised optional feature (I frankly
don't care much about that part of the discussion one way or another)

While in my case it's essentially ALL that I care about in this
discussion: the technical aspects of Python.

- was unwarranted, and more importantly *unwise* for someone in a

If, like you, I didn't care about the technical aspects of Python, it
sure would be unwise to get upset -- I could let the language go to hell
in a handbasket, as long as I made sure I looked good myself.

Caring deeply and passionately about something greater than oneself,
particularly something which may seem dry and abstract to those who
don't care a whit for it, might no doubt be deemed intrinsically unwise
-- and yet, there is much to be said for such passion. Without the
ability to get passionate and inflamed, we might perhaps be wiser, but
we'd be Vulcans, not humans. Moreover, unless some of us felt such
passion for certain technical issues, you guys who don't care would not
get the benefits of the time and energy we freely devote to them -- so
it's unwise, even from a strictly selfish viewpoint, to try to turn us
firebrands into such coolly calculating Vulcans.

postion of community leadership - considering past, recent, and
undoubtedly future issues that have and will arise.

What don't *you* understand about that??

Could you _really_ believe, considering the many years of consistent
history of my posts on this group, that by reviving the issue you could
get *any* other effect but fanning the flames all over again? THAT is
what I don't understand: whether you're doing that _deliberately_, or
out of almost-unbelievable levels of cluelessness.

We all have are own kinds of stupidities, it seems to me.

This is no doubt the case. For example, many of us instinctively brake
and swerve when a small animal jumps into the road in front of the car
they're driving, seriously endangering themselves and the passengers
thereby. If we were presented the issue in a context giving us time to
reflect and react rationally -- "To how much danger to life and limb
would you subject yourself, your wife, and your children, to increase
the likelihood of survival for some stupid cat who can't wait to cross
the road?" -- we'd probably react quite differently. And yet, while it
IS objectively stupid to behave that way, it _is_ one of the stupidities
that make us human.

A _deliberate_ and consistent preference can be disagreed with, but it's
pretty pointless to call it "stupid" or "unwise"; there is just no
accounting for tastes. If you _prefer_ the flame about declarations to
continue for its own sake (or because you believe it makes you look
good, whatever), while not caring about its contents, I may consider
that evil and hateful, but it's neither intelligent nor stupid _per se_.
If your preferences are otherwise, and yet your behavior is easily seen
to be such as to have that effect, then THIS is indeed very stupid.


Alex

 

[Arthur]

While in my case it's essentially ALL that I care about in this
discussion: the technical aspects of Python.

Then *only * talk about the technical aspects of Python, Is my, or
anybody else's stupidity, a technical aspect of Python?

If, like you, I didn't care about the technical aspects of Python, it
sure would be unwise to get upset -- I could let the language go to hell
in a handbasket, as long as I made sure I looked good myself.

Save your fire for real threats - was the exact point I was trying to
make.

Is the questionaing of a newbie on a list Guido doesn't even read a
threat to the fate of Python - technical or otherwise. Not in the
slightest, tiniest way . What is much more a threat to Python is an
inhospitable, dogmatic.and intimidating community ethos.

Let's not get to Altamont before we need to.

Caring deeply and passionately about something greater than oneself,
particularly something which may seem dry and abstract to those who
don't care a whit for it, might no doubt be deemed intrinsically unwise
-- and yet, there is much to be said for such passion. Without the
ability to get passionate and inflamed, we might perhaps be wiser, but
we'd be Vulcans, not humans. Moreover, unless some of us felt such
passion for certain technical issues, you guys who don't care would not
get the benefits of the time and energy we freely devote to them -- so
it's unwise, even from a strictly selfish viewpoint, to try to turn us
firebrands into such coolly calculating Vulcans.

I appreciate your books indeed,Alex. They are calm .I'm a customer. I
can study expositions. Not rants.

Could you _really_ believe, considering the many years of consistent
history of my posts on this group, that by reviving the issue you could
get *any* other effect but fanning the flames all over again? THAT is
what I don't understand: whether you're doing that _deliberately_, or
out of almost-unbelievable levels of cluelessness.

What issue was being "revived"? There was no issue there being
discussed that is on the table in any serious way. In that sense it
was a harmless discussion, inititated by someone new to Python, and in
the almost inevitable why this? why that? exploratory assessment
stage. I think you were candid enough to admit you had had such a
stage yourself.

Being hardcoded less into any alternative view of the universe when
coming to Python - i.e. ignorant - I faced much less of this.
Knowing little, I had a very smalll unlearning curve.

My struggle has been almost the opposite - and my lament has not been
why this?, why that? - but why change this? and why change that?

This is no doubt the case. For example, many of us instinctively brake
and swerve when a small animal jumps into the road in front of the car
they're driving, seriously endangering themselves and the passengers
thereby. If we were presented the issue in a context giving us time to
reflect and react rationally -- "To how much danger to life and limb
would you subject yourself, your wife, and your children, to increase
the likelihood of survival for some stupid cat who can't wait to cross
the road?" -- we'd probably react quite differently. And yet, while it
IS objectively stupid to behave that way, it _is_ one of the stupidities
that make us human.

If that is your way of admitting perhaps some human overreaction -
attacking as a threat something that rationally is or was not - its
appreciated that you are able to do so.

A _deliberate_ and consistent preference can be disagreed with, but it's
pretty pointless to call it "stupid" or "unwise"; there is just no
accounting for tastes. If you _prefer_ the flame about declarations to
continue for its own sake (or because you believe it makes you look
good, whatever), while not caring about its contents, I may consider
that evil and hateful, but it's neither intelligent nor stupid _per se_.
If your preferences are otherwise, and yet your behavior is easily seen
to be such as to have that effect, then THIS is indeed very stupid.

When Guido started thinking out loud about optional static typing he
came under attack most specifcally with the argument that optional
static typing will be technically optional, but in practice will
become mandatory and will therefore fundamentally change Python and
its culture.

I tried to make the argument that a proposed "optional" feature should
at least find its own range of rhetorical excess, as compared to other
kinds of discussions of possible language design decisions, partly
with that discussion resonating in the background.

You respnd by pontificating about how the world works. My instinct is
to go toe-to-toe with you or anybody else on the subject of how the
world works - maybe having a little more time to spend on the subject
in the last 53 years, having spent *less* time on the subject of how
Python works.

We are in a strange culture in Pythonland. He who knows the most
about Python internals knows all. A little bizarre. If Pythonl;and
is to be an innovative - or even intersting place - it needs, IMO, to
get past this kind of adolescence.

Art

 

[FLChamp]

Thanks for all your help everyone, if only it had addressed what I had
asked I may have actually learned something about Python!!

If anything was addressed to my problem then it has completely passed
me by as most points were clearly made by a computer scientist and I am
not one of those in the slightest. My experience of using any type of
programming language is limited to the little we are taught in my
non-computing subject and hence I have no idea what the below is all
about!! In future example code may be more useful to help newbies like
me

"That ``speciufication'' (sic) is no more ``a "declaration"'' than any
other parameter you can pass to a constructor (or any other factory
callable)."

 

[Diez B. Roggisch]

If anything was addressed to my problem then it has completely passed
me by as most points were clearly made by a computer scientist and I am
not one of those in the slightest. My experience of using any type of
programming language is limited to the little we are taught in my
non-computing subject and hence I have no idea what the below is all
about!! In future example code may be more useful to help newbies like
me

I think it has been addressed, by Art:

"""
My understanding:

is that VPython "vectors" are in effect flat 3 element Numeric arrays,
and Numeric ararys can be constructed with Float64 specified as the
datatype.
"""

It was embedded in some disgressing comments (he himself says so, btw.) so
you might have missed it.