当我们遍历下面的字典时,每次迭代都会(正确地)返回一个键值对
for key, value in dict.items():
print "%s key has the value %s" % (key, value)
Run Code Online (Sandbox Code Playgroud)
'some key'key有值'some value'(重复多次有ak,v对)
以上内容对我有意义,但是如果我们这样做:
for key in dict.items():
print "%s key has the value %s" % (key, value)
Run Code Online (Sandbox Code Playgroud)
("some key", "some value")有值"some value"(左元组将迭代每个键值对,右值将保持在字典中的第一个值并重复)
我们最终获得在第一个%s(键)和第二个%s(值)中返回的每个k,v对不迭代,它只返回for循环的每次迭代的dict中的第一个值.
我明白,如果你只是迭代,for key in dict那么你只是在迭代密钥.这里因为我们dict.items()只使用for循环中的键来迭代一组元组(通过使用),所以循环应该运行与第一个示例相同的次数,因为密钥和值对的密钥数量相同.
我抓到的麻烦是为什么python在第二个例子中为你提供了整个元组key.
感谢所有人的帮助 - 我想再添加一个问题.
for a,a in dict.items():
print a
Run Code Online (Sandbox Code Playgroud)
为什么以上打印值,如果我print a,a- 显然两个值都打印两次.如果我输入了,for a,b我会迭代(key,value)对,所以我逻辑上认为我现在迭代 …
我理解一般的想法,即生成器返回一个“保存状态”的可迭代对象,并且不会立即计算所有内容,而是在每次调用时进行计算next。这是如何运作的?例如[x for x in range(10) if x%2==0]vs (x for x in range(10) if x%2==0)。在列表理解中,所有内容都会立即计算并存储在内存中。
在生成器中,不会生成整个列表,而是生成一个可迭代的生成器对象,该对象在每次调用 next 时进行计算。但这个生成器必须以某种方式知道它的“边界”,对吗?如果生成器没有在后台执行所有计算,它如何知道从哪里继续计算?我认为它必须知道列表理解中的每一步,最终如果您最终循环整个生成器直到达到 StopIteration,我认为您使用的内存量大致相同。
宏在明确告知之前不会评估它们的参数,但是函数会这样做。在以下代码中:
(defmacro foo [xs]
(println xs (type xs)) ;; unquoted list
(blah xs))
(defn blah [xs] ;; xs is unquoted list, yet not evaluated
(println xs)
xs)
(foo (+ 1 2 3))
Run Code Online (Sandbox Code Playgroud)
似乎blah没有评估xs,因为我们仍然有整个列表:(+ 1 2 3)绑定到xsblah 的正文中。
我基本上只是记住了宏中的辅助函数和它们对参数的评估之间的这种相互作用,但老实说,这违背了我的直觉(即 xs在进入主体之前会进行评估,因为函数参数总是被评估)。
我的想法基本上是:“好吧,在这个宏体中,我有xs一个未xs评估的列表,但是如果我从宏内部调用一个函数,它应该评估该列表”。
显然,我对事情的运作方式有一个令人尴尬的根本误解。我的解释中缺少什么?评估实际上是如何发生的?
编辑
我想我只是混淆了各种术语,但考虑到引用形式与未评估形式同义,并且给定宏参数未评估,它们被隐式引用。
所以在我上面的例子中,说xsis unquoted 有点误导。例如,这个宏:
(defmacro bluh [xs]
`(+ 1 2 ~xs))
Run Code Online (Sandbox Code Playgroud)
与下面的宏基本相同(不包括符号上的命名空间)。xs在调用中解析list会返回一个未评估(引用?)的列表。
(defmacro bleh [xs]
(list '+ '1 …Run Code Online (Sandbox Code Playgroud) 我有一个场景,我正在通道上处理事件,其中一个事件是需要在特定时间范围内发生的心跳。非心跳的事件将继续消耗计时器,但是每当收到心跳时我想重置计时器。执行此操作的明显方法是使用 time.NewTimer.
例如:
\nfunc main() {\n to := time.NewTimer(3200 * time.Millisecond)\n for {\n select {\n case event, ok := <-c:\n if !ok {\n return\n } else if event.Msg == "heartbeat" {\n to.Reset(3200 * time.Millisecond) \n }\n case remediate := <-to.C:\n fmt.Println("do some stuff ...")\n return\n }\n }\n}\nRun Code Online (Sandbox Code Playgroud)\n请注意,time.Ticker此处不起作用,因为只有在未收到心跳的情况下才应触发修复,而不是每次都如此。
上面的解决方案在我尝试过的少数低容量测试中有效,但是我遇到了一个 Github 问题,表明重置尚未触发的计时器是不行的。此外,文档还指出:
\n\n\n仅应在通道已耗尽的计时器停止或过期时调用重置。如果程序已经从 tC 接收到一个值,则知道定时器已到期并且通道已耗尽,因此可以直接使用 t.Reset。但是,如果程序尚未从 tC 接收到值,则必须停止计时器,并且\xe2\x80\x94如果 Stop 报告计时器在停止之前已过期\xe2\x80\x94通道显式耗尽:
\n
if !t.Stop() {\n <-t.C\n}\nt.Reset(d)\nRun Code Online (Sandbox Code Playgroud)\n这让我停了下来,因为它似乎准确地描述了我正在尝试做的事情。每当收到心跳时,我就会Timer在触发之前重置 …
我正在观看 Raymond Hettinger 的一段很棒的视频,我对装饰器示例有点困惑:
def cache(func):
saved={}
@wraps(func)
def newfunc(*args):
if args in saved:
return newfunc(*args) # should be return saved[args]?
result = func(*args)
saved[args]=result
return result
return newfunc
Run Code Online (Sandbox Code Playgroud)
我不是装饰器方面的专家,但是在发现该项目被缓存时对 newfunc(*args) 的调用返回不会导致永远不会结束的递归循环吗?我认为它应该返回保存的[args](该函数最终返回结果,这是同一件事,但我认为如果在缓存中找到一个项目,它永远不会到达那里。)
我有一个使用leningen创建的项目,我在其中保存了src/some_project_name目录中的clj文件(以及自动生成的core.clj文件).
与这些clj文件一起保存的是我想要slurp从它们旁边的clj文件中获取的文本文件.我的理解是,读取文件是相对于工作目录的,并且工作目录将位于您启动REPL的任何位置.我从src/some_project_name里面启动了REPL,其中所有文件都位于,而不是root.(System/getProperty "user.dir")确认这是活动目录.
但是我也读过这slurp将查找相对于你的根目录的文件,尽管从src/some_project_name中启动了REPL,但显然正在发生这种情况.我必须列出相对于根目录的文本文件路径才能找到它们,例如"src/some_project_name/foo.txt"而不仅仅是"foo.txt".
在设置项目之前,可以相对于REPL运行的任何地方访问文件(正如我所期望的那样).现在,在设置项目之后,无论REPL在何处启动,它们似乎只能相对于root进行访问.
我对此没有任何问题,但我不明白.是否有一些设置由leningen完成拦截REPL评估,并告诉它从root搜索而不是在活动目录的位置搜索?
我刚刚开始尝试使用以下模板制作一个简单的 cljs 应用程序:
lein new figwheel someproject -- --reagent
我希望在 cider 中使用 REPL 进行 cljs 开发,就像我通常在普通 clj 项目中使用的方式一样,所以我做了一些研究并最终得到了这里:
https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl
我通读了说明,并验证了所有正确的依赖项都在 project.clj 中(无需更改任何内容,看起来模板添加了我需要的所有内容)。上面链接中的最后一步表明我需要将以下代码添加到我的 emacs 配置中:
(require 'cider)
(setq cider-cljs-lein-repl
"(do (require 'figwheel-sidecar.repl-api)
(figwheel-sidecar.repl-api/start-figwheel!)
(figwheel-sidecar.repl-api/cljs-repl))")
Run Code Online (Sandbox Code Playgroud)
现在 - 我是一个 emacs 新手,所以我使用的设置仍然是我第一次从“ Clojure for the Brave and True ”中学到的:
https://github.com/flyingmachine/emacs-for-clojure
我试图首先将上面的代码片段放入 中~/.emacs.d/init.el,但是每当我尝试时M-x cider-jack-in ...,都没有cider-jack-in-clojurescript选择。我还尝试将代码片段放在 中~/.emacs.d/customizations/setup-clojure.el,这看起来更合乎逻辑,但结果相同。
我真的很想能够启动并运行这个 REPL,所以任何帮助将不胜感激。
我理解递归的概念,我感到困惑的是流量控制.我看到过这种方式有两种,一种是我得到的,另一种是我没有的.例一:
def fact(n):
if n == 0:
return 1
else:
return n * fact(n-1)
Run Code Online (Sandbox Code Playgroud)
所以在这个例子中,如果我们运行fact(3),会发生以下情况:
fact(3) = 3*fact(3-1)`
fact(2) = 2*fact(2-1)
fact(1) = 1*fact(1-1)
fact(0) = 1
Run Code Online (Sandbox Code Playgroud)
或合并: 3*2*1*1 = 6
现在,对于下面的内容,我被绊倒的地方在于流量控制的工作原理.我在脑海中根深蒂固,当一个函数被调用时,其他一切都被暂停,直到该函数完成,此时程序返回到main.以下是我的大脑认为发生在下面的事情:
def factorial(n):
if n == 0:
return 1
else:
recurse = factorial(n-1)
result = n * recurse
return result
Run Code Online (Sandbox Code Playgroud)
我们称之为factorial(3):
factorial(3)=factorial(2)=factorial(1)=factorial(0)=1
Run Code Online (Sandbox Code Playgroud)
我认为这种情况发生的原因是因为result在调用之后分配并且在我看来代码永远不会到达那里因为流控制result在分配之前暂停main .我认为这个函数只是运行n==0直到1返回的测试,然后程序退出.
帮助我理解为什么我似乎无法将这个概念化.
刚开始使用该库... RandomForestClassifiers有一些问题(我已经看过文档但不清楚)
我的问题很简单,说我有一个火车数据集,例如
美国广播公司
1 2 3
其中A是自变量(y),BC是因变量(x)。假设测试集看起来相同,但是顺序是
商业咨询委员会
1 2 3
当我打电话时forest.fit(train_data[0:,1:],train_data[0:,0])
,我是否需要在运行之前重新排序测试集以匹配此顺序?(忽略了我需要删除已经预测的y值(a)的事实,因此,只需说B和C乱序...)
从csexchange交叉发布:
\nLet s = s0\nFor k = 0 through kmax (exclusive):\n T \xe2\x86\x90 temperature( 1 - (k+1)/kmax )\n Pick a random neighbour, snew \xe2\x86\x90 neighbour(s)\n If P(E(s), E(snew), T) \xe2\x89\xa5 random(0, 1):\n s \xe2\x86\x90 snew\nOutput: the final state s\nRun Code Online (Sandbox Code Playgroud)\n我无法理解随着温度冷却该算法如何不会陷入局部最优。如果我们在温度较高时一开始就跳跃,最终在温度冷却时只进行上坡移动,那么找到的解决方案不是高度依赖于我们恰好在搜索空间中作为温度而结束的位置吗?开始变冷了吗?我们可能很早就找到了更好的解决方案,在气温较高时跳出了它,然后随着气温变冷并且我们过渡到爬山,情况变得更糟。
\n对这种方法的一个经常列出的修改是跟踪迄今为止找到的最佳解决方案。我看到这种变化如何减轻在温度较高时“丢弃”在探索阶段找到的更好解决方案的风险,但我不认为这比简单地重复随机爬山来采样有什么更好的地方空间,没有温度戏剧。
\n我想到的另一种方法是将跟踪“迄今为止最好的”的想法与重复的爬山和波束搜索结合起来。对于每个温度,我们可以执行模拟退火并跟踪最佳的\'n\'解决方案。然后对于下一个温度,从每个局部峰值开始。
\npython algorithm optimization combinations simulated-annealing
研究一些2015年的AoC问题以学习clojure ......下面对于第40次迭代来说足够快,但在此之后又停止了很多.我与其他一些人的解决方案进行了比较,对我来说,为什么这么慢,这一点并不明显.我试图使用recur相信它与循环一样高效(并避免堆栈消耗).我不是100%明确的一件事是,如果仅仅使用复发与使用循环复发之间存在明显差异.我测试了两种方式并没有看到任何区别.
(def data "3113322113")
(defn encode-string [data results count]
(let [prev (first data)
curr (second data)]
(cond (empty? data) results
(not= prev curr)
(recur (rest data) (str results count prev) 1)
:else (recur (rest data) results (inc count)))))
(count
(nth (iterate #(encode-string % "" 1) data) 40 #_50))
Run Code Online (Sandbox Code Playgroud)
我对其进行基准测试的解决方案的一个例子是Bruce Hauman,这非常好:
(defn count-encode [x]
(apply str
(mapcat
(juxt count first)
(partition-by identity x))))
Run Code Online (Sandbox Code Playgroud)
我在我的解决方案中意识到我反复迭代非常大的字符串,但是我没有看到Bruce的速度如此快,因为虽然他没有明确迭代,但分区可能在幕后迭代.
python ×6
clojure ×4
algorithm ×1
caching ×1
cider ×1
combinations ×1
decorator ×1
dictionary ×1
figwheel ×1
generator ×1
go ×1
lisp ×1
macros ×1
nrepl ×1
optimization ×1
recursion ×1
reset ×1
scikit-learn ×1
slurp ×1
timer ×1