Visual Python中的向量 [英] Vectors in Visual Python
问题描述
如果这个消息有点困惑，那很可能反映了作者的状态。
我制作了一个小程序使用visual.vector获取所有值的视觉中的行星轨道
python。如果我运行该程序，那么它是明确的，即当行星逐渐从太阳移开时，轨道是非开普勒的。我很确定轨道应该是开普勒，所以我猜这个程序中肯定会有一些错误来源。
我正在使用来自__future__进口部门和初始条件
我来自NASA的视野系统，所有数值都精确到
超过10位小数。
我想知道是否有办法通过visual.vector指定使用的数字类型
，例如，当使用数组时，可以
将类型指定为float64。如果visual.vector使用较小的
内存量来存储数字，这可能是我发现的
错误的来源吗？如果不是还有什么可能是罪魁祸首？
我使用了我之前制作的4阶RK方法
开普勒轨道运行。
我希望我在这里有所了解并期待任何输入
非常感谢
Ben
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
推荐答案
2005年2月9日02:29:35 -0800，FLChamp < be ********** @ gmail.com>
写道：
On 9 Feb 2005 02:29:35 -0800, "FLChamp" <be**********@gmail.com>
wrote:
SOrry如果这个消息有点困惑，它最有可能反映了作者的状态！
名字中有一点混乱。早期有一个名字空间冲突
。事情震惊了Visual Python是ActiveState的Python
Visual Studio开发环境.Net
http://www.activestate.com/Products/Visual_Python/
和你提问的3d编程环境指的是
变成了 VPython" ;.只是一个信息点。当然在你的问题的背景下没有什么好的混淆，但是在其他的背景下可能会出现这种情况。
我制作了一个小程序来绘制轨道。视觉上使用visual.vector获取所有值的行星。如果我运行该程序，那么当轨道逐渐移动远离太阳时，轨道是非开普勒的，这是明确的。我很确定轨道应该是开关的，所以我猜测程序中肯定会有一些错误来源。
我正在使用来自__future__ import division。我最初的条件是来自美国宇航局的视野系统，所有数值都精确到超过10个小数位。
我想知道是否有办法通过visual.vector指定使用的数字类型，例如，使用数组时，可以将类型指定为float64。如果visual.vector使用较小的内存来存储数字，这可能是我发现的错误的来源吗？如果不是还有什么可能是罪魁祸首？
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?
我的理解：
是VPythonvector实际上是平3元素数字数组，
和数字ararys可以用Float64指定为
数据类型。 （想知道这个说明是否是一个声明，如果
那么这是否表明Python的意识形态之间存在冲突
（亚历克斯的版本）和它的事实标准数值处理
库 - 但我离题了。
你试过向VPython提供向量，数组声明为
Float64类型。
可能会，也可能不会，让你到达某个地方。
艺术
" Arthur" < AJ ****** @ optonline.com>在消息中写道
news：pb ******************************** @ 4ax.com ...
"Arthur" <aj******@optonline.com> wrote in message
news:pb********************************@4ax.com...
是VPythonvector。实际上是平3元素数字数组，
和数字ararys可以用Float64指定为
数据类型。 （想知道这个说明是否是一个声明，如果那么这是否表明Python的意识形态（Alex的版本）与其事实标准数字处理之间存在冲突
图书馆 - 但我离题了。）
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) .
我（我相信Alex）反对命名声明*声明*和/或
强力输入*姓名*。
我（我相信Alex）赞成*对象*的强类型，其中
必须以某种方式在对象创建*表达式*中指示。这绝对是Python的基础。
绝对是Python的基础。至少有三种方法可以表示所需的对象类型：文字类型，构造函数（以及其他
函数）标识，以及构造函数（和其他函数）参数。 br />
当构造函数参数只指定了
齐次集合对象的成员类型时，集合本身的可见类型（）
可能不会受到影响。我相信数字
和num-数组的成员类型规范是这样的，因为它们适用于stdlib array.arrays。
对不起，没有冲突; - ）
Terry J. Reedy
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
Arthur< aj ****** @ optonline.com> ;写道：
Arthur <aj******@optonline.com> wrote:
是VPython" vectors"实际上是平3元素数字数组，
和数字ararys可以用Float64指定为
数据类型。 （想知道这个说明是否是一个声明，如果那么这是否表明Python的意识形态（Alex的版本）与其事实标准数字处理之间存在冲突
图书馆 - 但是我离题了。）
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) .
`speciufication''''（原文如此）不再是一个声明'''' ''比任何
其他参数你可以传递给构造函数（或任何其他工厂
可调用）。我发现很难相信这对于任何拥有3位智商的人来说完全，完全和完全显而易见。
试图将问题细分为即使对于大多数2位数的智商来说，我希望这些子问题很明显很明显......：
当我打电话时，我可以传递参数 - - 你觉得``那是'
声明''''？！
我执行的一些调用构建并返回新对象 - 你好吗？
真的认为`'那是'声明''''？！
显然，我通过的参数通常会影响我的结果
电话 - 你真的，SERIOUSLKY认为'那是'声明''''？
*什么地球*可能*可能*让你惊叹如果这些
方面中的任何一个在一个完全普通的可执行语句中形成'
而不是''声明''''？！？！
请澄清你是否在没有表情符号的情况下制作一个蹩脚的笑话，对于什么是声明而言是完全混淆的。 *意思*，或其他愚蠢的
提示你这个惊人的评论，谢谢。在找到了如何建立一个持久的杀戮文件之后，我想看看是否在人们身上大量使用它们似乎只是为了挑起火焰战争而不是给b $ b提供和接受帮助，并参与有趣的讨论，可以让b $ b再次使新闻组对我有用。遗憾的是，阅读这个小组的任何新手都会被大量的傻瓜在那里发布的大量的b / b
未经质疑的id id混淆和损坏，但是，啊好吧，我无法解决这个问题，很明显 - 我只能希望并相信那些愚蠢的业力与他们造成的愚蠢伤害成比例。
Alex
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
这篇关于Visual Python中的向量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
