https://leetcode.com/problems/maximum-subarray/
| -2 | 1 | -3 | 4 | -1 | 2 | 1 | -5 | 4 | 最初の3つの合計(-2 + 1 -3)はマイナスになるので、 そのため subarray のスタートは 4 もしくは 4以降の数字になる。
合計が正の数になる場合は保持しておく。 変数に0 を代入して、 iterate しながら数字を追加していく。 合計がマイナスになる場合は保持する必要がないので、0 にする。
Time complexity: O(n) Mem complexity: O(1)
class Solution(object): def maxSubArray(self, nums): """ :type nums: List[int] :rtype: int """ max_subarray = nums[0] current_subarray = 0 for n in nums: if current_subarray < 0: current_subarray = 0 current_subarray += n max_subarray = max(max_subarray, current_subarray) return max_subarray
https://leetcode.com/problems/best-time-to-buy-and-sell-stock/
pointer を2つ使う。 left が right より低い時点で売る可能性あり。 max_profit に最大の profit を格納。
right の pointer は右に移動し続け
left の pointer は prices[l] が prices[r] より大きい際に、 left の pointer を right の pointer の位置に移動する。
Time complexity: O(n)
Mem complexity: O(1)
class Solution(object): def maxProfit(self, prices): """ :type prices: List[int] :rtype: int """ l, r = 0, 1 max_profit = 0 while r < len(prices): if prices[l] < prices[r]: profit = prices[r] - prices[l] max_profit = max(max_profit, profit) else: l = r r += 1 return max_profit
https://leetcode.com/problems/two-sum/
| 2 | 7 | 11 | 15 | ↑ ↑ 全てのコンビネーションを確認しようと Brute Force で問題を解こうとすると ループの中でループをするのでo(n^2)となる。
| 2 | 7 | 11 | 15 | そのため HashMapを使う必要がある。 ループして array の中を確認する際に、 HashMap に val と key を持たせる。 ループ時に target - val の値が HashMap にあれば、 合計の値を持つ index が return できる。
| 2 | 7 | 11 | 15 | ↑ | HashMap | | val : index | | 2 : 1 | | HashMap | | val : index | | 2 : 1 | | 7 : 2 |← | 11 : 3 | | 15 : 4 | target は 9 なので val 7 を確認時に HashMap にすでに 2 が入っているので この時点で return できる。...
Responses HttpResponse オブジェクトと違い、レンダリングされたコンテンツでResponseオブジェクトをインスタンス化する必要がない。 その代わりにレンダリングされていないデータをパスする必要がある。
Responseクラスで使用されるレンダラーは、Djangoモデルインスタンスなどの複雑なデータ型をネイティブに処理できないため、Responseオブジェクトを作成する前に、データをプリミティブデータ型にシリアル化する必要があります。
REST frameworkのSerializerクラスを使ってこのデータをシリアライズするか、カスタムシリアライザーを使用する。
引数
data : レスポンス用のシリアライズされたデータ status : レスポンス用のステータスコード デフォルトでは 200 template_name : HTMLRenderer が選択されているならテンプレート名 header : レスポンス用の辞書型 HTTP ヘッダー content_type : レスポンス用のコンテンツタイプ。一般的にコンテンツネゴシエーションのrenderer によって自動的に設定される。しかし、場合によっては明示的にコンテンツタイプを特定する必要もある。 プロジェクトが既にある場合 ユーザーモデルは拡張する。
最初から作成する場合は モデルをオーバーライドして独自のカスタムモデルを作成
カスタムユーザーモデルは
APIView REST frameworkは Djangoの View class のサブクラスである、 APIViewclassを提供する。
APIViewclass は下記のようにView classとは異なる。
handler methods を通ったRequests は REST frameworkの Request インスタンスになり。 Django の HttpRequestインスタンスではない。
handler methods の return は REST frameworkの Responseとなり、 その view は content negotiation と response に一致した renderer を返す。
どの APIException のエクセプションは正しいレスポンスに仲介される。
来るリクエストは認証され、handler methodsに送る前に、 適切な権限やスロットルチェックが行われる。
DRF ドキュメント
ViewSet viewSet classは APIViewを継承している。 viewsetで API policy をコントロールするにあたり、 スタンダードの属性であるpermission_classes,authentication_classesが使える。
viewSet classはどのアクションも含んでいないので、 クラスをオーバーライドして明示的に定義する必要がある。...