double Ceil(double x)
{
if(x!=x || // если x = NaN(SNaN) т.е. переполнение или ошибка
x> (long)1<<53 || // или число x положительное и превышает максимальную возможную мантиссу, т.е. дробная часть в x точно отсутствует
x<-(long)1<<53) // или число x отрицательное и превышает максимальную возможную мантиссу, т.е. дробная часть в x точно отсутствует return(x);
if(x-(long)x>0) // Если число положительное или дробная часть не равна нулюreturn(long)x+1.0; // добавляем к бездробной части 1elseif(x>-1 && x<0) // Если -1 < x < 0return -0.0; // то возвращаем -0.0elsereturn (double)long(x);
}
2018.08.2718:42:37.616 TestCeil (EURUSD,M1) Время выполнения функции CeilI = 1.321 наносекунд, Контрольная сумма = 5250492895.02018.08.2718:42:37.619 TestCeil (EURUSD,M1) Время выполнения функции CeilN = 1.094 наносекунд, Контрольная сумма = 5250492895.02018.08.2718:42:37.623 TestCeil (EURUSD,M1) Время выполнения функции ceil = 2.962 наносекунд, Контрольная сумма = 5250492895.02018.08.2718:42:37.623 TestCeil (EURUSD,M1) Идет бесконечный поиск расхождения по случайным числам double ... Прервите скрипт, когда надоест ждать
入力xが分数部を持つ場合の結果は稀である。
2018.08.2718:49:45.734 TestCeil (EURUSD,M1) Время выполнения функции CeilI = 0.307 наносекунд, Контрольная сумма = 1.15583114403606 e+232018.08.2718:49:45.736 TestCeil (EURUSD,M1) Время выполнения функции CeilN = 0.102 наносекунд, Контрольная сумма = 1.15583114403606 e+232018.08.2718:49:45.738 TestCeil (EURUSD,M1) Время выполнения функции ceil = 1.026 наносекунд, Контрольная сумма = 1.15583114403606 e+232018.08.2718:49:45.738 TestCeil (EURUSD,M1) Идет бесконечный поиск расхождения по случайным числам double ... Прервите скрипт, когда надоест ждать
わー、かっこいいー。ありがとうございます。そして、思ったのは、「毎回数えている」ということです。うん、まあ、論理的には、コンパイルの段階ですでに計算できるわけですからね。
だから、こんな風に。
しかし、53ではなく、DBL_MANT_DIGと 書いた方が正しいでしょう。
doubleの値がすべて小数である場合、利得が最小となるケース。
1.あなたの実装は不完全です。可能な値の範囲があらかじめ分かっている場合にのみ使用できます。
以下は、完全な実装のコードです。
2.デバッグ用にコンパイルした場合、最適化を無効にすると、自作関数は組み込み関数より大幅に遅くなります。
1.あなたの実装は不完全であり、可能な値の範囲があらかじめ分かっている場合にのみ使用できます。
以下は、完全な実装のためのコードです。
2.最適化を無効にした場合、デバッグ用にコンパイルすると、自作関数は組み込み関数よりはるかに遅くなります。
Ilyasさん、素晴らしいコードをどうもありがとうございました。
もちろん、ここでも大活躍です。
勉強しているところです。
同じこと ではありませんか？ニコライさん、こんにちは。グラフィックを担当されているようですが、実際にどのような作業をされているのかがよくわかりません。何をやっているんですか？
レンダリング機能の高速化？
一般的に、このスレッドのトピックでは、私はキャンバスに描画するための完全に別のアプローチを実装することに成功しました。CCanvas クラスを 使用しない場合。
つまり、個別の機能を修正するのではなく、1つのブロックで構成される完全な描画機構を作るということです。
(もちろん、コードが多く、非標準的な書き方をしているので、コードですべてを示すことはほとんどできませんが、一般的なことをお伝えしたいと思います）。
だから
1. ブロック（機能）
は、KanvasとElementの2つのパラメータのみを受け付けます。
2.MT-オブジェクトには、それぞれリソースが割り当てられている。リソースがまだ存在しない場合、フラグが立てられ、その後カーネル上のサイクルの範囲が決定される。
3. カーネルは、全要素のプロパティの配列である。物体の大きさや、状態別の色などのデータが含まれています。その他、様々なデータを掲載しています。すべてのオブジェクトには、合計で235のプロパティがあります。同時に、各エレメント（タイプによる）には1～11個のオブジェクトを含めることができる（制限はない）。
4.図面ブロックでは、各オブジェクトは図面の「詳細」を意味する。したがって、カーネル内のオブジェクトによるサイクルは、各Detailの画像を作成する描画サイクルとなる。キャンバスがまだ作成されていない場合は、そのキャンバスの全ディテールだけで1サイクルが行われます。カンヴァへの所属は、ディテールごとにカーネルに規定されています。つまり、すべてのKanvase、（およびParts）には、それぞれ固有のシーケンス番号があります。この数字によって、必要なKANVASの内容だけを描き出すことができるのです。
4.Kanvasが既に存在し、その画像がピクセルの配列でロードされており、単一の要素だけを再描画する必要がある場合（例えば、色変更イベントで）、コアループの範囲は、描画関数で取得した番号を持つ単一の要素の境界まで狭められます。
図面そのものはシンプルです。一次元配列のセルを左から右へ循環させるものである。サイクルが設定される前。
1.スタート地点のセル（A点）。
2.エンドセル（B点）。
3.踏み倒す。
1500行のコードブロックの動作を一言でまとめるのは難しい。20カ月間、成長し、磨きをかけてきた1つの機能です。ほとんど暗記しているので、開発し続けることが容易なのです。
カーネルとフォーカス（重要な変数をグローバルスコープに置くこと）を使うことで、ブロックは大きな可能性を手に入れることができます。その限界は、今も私には見えていません。
つまり、標準的なカンヴァス描画の手法に代わるものですね。
zyです。興味があれば、詳しく説明します。
ブロックの先頭は次のようになります。
1.あなたの実装は不完全であり、可能な値の範囲があらかじめ分かっている場合にのみ使用できます。
以下は、完全な実装のためのコードです。
改めて、コードをありがとうございました。このビットマスクには、ダブルのように頭を悩ませているんです。以前思っていたほど簡単ではないことがわかりました。
私のバージョンは、あなたのものに若干調整しました。ただ一つ違うのは、あなたのバージョンでは、-1>x>0 Ceil(-0.1)= - 0.0という値が返されたのに対し、私のバージョンでは0.0が返されたことです。いつ役に立つかわからないけれども。
そして、次のようになります。
同じものを、読みやすく、コメント付きにしただけです。
スクリプトを書きましたので（添付）、そちらのバージョンと100％同一であることを確認しました。
しかし、このバリエーションは、より速く、よりコンパクトで、より読みやすいと私は思っています。
関数本体には変数が1つも作成されていませんが、あなたのバージョンでは8バイトの変数が4つ作成されていることに注意してください。
もしかしたら、私が間違っているのかも？
入力xが常に分数部を持つ場合の結果。
入力xが分数部を持つ場合の結果は稀である。
2.デバッグ用にコンパイルする場合、最適化を無効にすると、自作関数は組み込み関数より大幅に遅くなります。
デバッグになぜスピードが必要なのか、その理由は不明です。
しかし、本当に必要であれば、コンストラクトを使ってもよい。
そして、もうひとつわからないことがあります。
ドキュメントと実際のDBL_MANT_DIG = 53はなぜですか？
を、同じウィキペディアに よると、52となります。
そして、あなたのコードから 導かれるように、52も?
ニコライさん、こんにちは。グラフィックを担当されているようですが、実際にどのような作業をされているのかがよくわかりません。何をやっているんですか？
レンダリング機能の高速化？
ピョートルさん、こんにちは。
直接返信します。
そして、もうひとつわからないことがあります。
ドキュメントと実際のDBL_MANT_DIG = 53はなぜですか？
一方、同じウィキペディアに よると＝52。
そして、あなたのコードも 52であることを暗示しているようです？
自分で答えを見つけようとしたことがありますか？
ヒント：google検索で「DBL_MANT_DIG 53 52」と入力してください。