Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC). Syntax Members dwLowDateTime The low-order part of the file time. dwHighDateTime The high-order part of the file time. Remarks To convert a FILETIME structure into a time that is easy to display to a user, use the FileTimeToSystemTime...
それを与えるために、datetime 型は10バイトになり、MqlDateTime構造体は若返る はずです。
うわー、夢中になっちゃいましたね :)
long is enough.8バイトである。誰も構造の話などしていない。 すべては今のままでいい。
スレッドを読んで、ミリ秒が必要なのはスポーツの面白さだけだと気づきました。msの精度で100m走の値段が測れるようになること。
それをあげるとすれば、datetime 型が10バイトになり、MqlDateTime構造体が太く なるはずです。
MQL6を待つと、ミリ秒タイマーやティック履歴などがそこに表示されるようになります。しかし、今更追加する意味があるとは思えません。IMHO
読むことと理解することは別物です。
しかし、MqlDateTimeが何バイト占有するかを計算してくれてありがとう、それは真剣に私の12ギガに影響を与えるだろう、私はすでにMT5スワップを見てきました。
Sereyevは、私が最初から明確だと思うことを言ったが、私は私がどのフォーラムにいるのか忘れてしまった。ミリ秒はサーバーとの同期のためではなく、イベントのシーケンスを理解するためのものです !
sergeev:
long is enough.8バイトです。
さらに提案する...
longをtimeに変換して、ミリ秒を取り出す方法。
そのためには、構造体やデータ型を 追加し、そこと相互変換するための新しい関数が2、3個必要になります。
ラッパーが用意されているdatetimeがあるのに、なぜ？
さらに提案する...
longをtimeに変換し、ミリ秒を取り出す方法です。
そのためには、構造体やデータ型を 追加し、前後に変換するための3つの新しい関数が必要になります。
datetimeはラッパーが用意されているのに、なぜ？
アンドリュー 失礼ながら、あなたは答えを考えていませんね。
ミリ 秒単位の時間は、秒単位の時間に1000を 掛けたもの＋その超ミリ秒の数 です。
ぜんすう
ミリ秒単位の時間を1000で割ると、昔からよく使われるdatetimeと そのすべての機能が得られます。PLUS 割り算の余り - ミリ秒の数。
それだけです。
sergeev:
ミリ秒単位の時間を1000で割ると、あらゆる可能性を秘めた、昔からよく使われるdatetimeが 得られる。PLUS 割り算の余りがミリ秒数です。
では、時間を知るためには、何かで何かを割らなければならないのでしょうか？四捨五入の誤差は？分割せずに回避する方法はないのでしょうか？
では、時間を知るためには、何かで何かを割らなければならないのですか？丸め誤差は？分割せずに回避する方法はないのでしょうか？
が、数値は整数です :)
割り算をしない場合は、下3桁を取るだけで、ミリ秒になります。
割り算をしない場合は、下3桁をミリ秒とすればよい。
分けずに取るにはどうしたらいいですか？文字列に変換して、右3文字を整数に戻す？それでは感動がない。
また、除算や乗算などの余りを求める演算を追加してミリ秒を求めるのは、ある種の蛮勇と言えるでしょう。IMHOそれどころか、既製品として入手できるはずです。
それよりも、なぜ開発者は時間を保存 するのに、今話題のミリ秒ではなくUNIX形式を選んだのだろうか？
きっと何かを知っているのでしょう。
Datetime型。
Тип datetime предназначен для хранения даты и времени в виде количества секунд, прошедших с 01 января 1970 года. Занимает в памяти 8 байт.
こんな風に作ればいいんだ。
datetime型は、日付と時刻を1970年1月1日からの経過ミリ 秒数で格納するように設計されています。8バイトのメモリーを消費します。
分割などという無意味なことは、何の関係があるのでしょうか？時間は任意の単位で保存可能（tertesも 可）。どんな単位にも（地球上の時間／秒）、火星の単位にも変換できる。これによって、変換に費やす計算資源量が小さくなったり大きくなったりすることはない。変換は人間が単純に理解するために必要なもので、機械が行うものではありません。
おそらく、経費を節約して、歴史的なデータベースの圧縮を強くすることにしたのだろう。開発者の皆さん、歴史のために答えてください、なぜ秒殺を選んだのでしょうか？なぜミリ秒単位の精度が必要なのか、今でもわからないくらいですから、単純に精度を上げる必要がないと考えたのでしょう。
反対側から攻めます。
1.ビッド＝1.30245 数量50枚。このレベルは30ms継続する。
2.買付＝1.30244枚 75枚。このレベルは25ms持続する。
3.入札＝1.30243枚 300枚。2秒間存在した。
この情報は、トレードに役立ちます。
多分pipsizersのためにはい...しかし、ここでゼロ遅延で市場にあなたの50ロットを入力するようなブローカーは何ですか？
分けずに取るにはどうしたらいいですか？文字列に変換して、右3文字を整数に戻す？それでは感動がない。
datetimeがどのように構造体に変換されるのか、不思議に思ったことはありませんか？ 割り算や余り算ではなく？
それとも、違う仕組みになっているのでしょうか？http://msdn.microsoft.com/ru-RU/library/windows/desktop/ms724284%28v=vs.85%29.aspx
それどころか、すぐに手に入るはずです。
8バイトを与えられただけで、他に開発者に何を要求するんだ？
興味深いのは、そのことではなく、なぜ開発者がもともと時間の保存に UNIX形式を選び、今話題のミリ秒ではないのか、ということです。
あなたは、ある種のタイムフォーマットについて話し続けているようですが、OKです。 どのようなものを知っていますか？
個人的には3人知っています。
- 4バイト - ユニックス時代1970年から2038年までの秒数(INT)
- 8 バイト - 1601 から 30828 までの 100 ナノ秒の数（FILETIME）。
- 8バイト - 1970年から2038年までのミリ秒数(INT64)
8バイトの時刻記憶構造体SYSTEMTIMEもあるが，派生したものである。
私が提案するのは、MTサーバーにすでにあるもの、つまりunix時代の8バイトを与えるということです。
何を隠すか:)