diff --git a/previews/PR166/404.html b/previews/PR166/404.html new file mode 100644 index 00000000..945a1cb6 --- /dev/null +++ b/previews/PR166/404.html @@ -0,0 +1 @@ + Flux – Elegant ML

404

Page not found :(

The requested page could not be found.

\ No newline at end of file diff --git a/previews/PR166/LICENSE b/previews/PR166/LICENSE new file mode 100644 index 00000000..e05c9525 --- /dev/null +++ b/previews/PR166/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2021 FluxML and Contributors + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/previews/PR166/Manifest.toml b/previews/PR166/Manifest.toml new file mode 100644 index 00000000..accd492e --- /dev/null +++ b/previews/PR166/Manifest.toml @@ -0,0 +1,309 @@ +# This file is machine-generated - editing it directly is not advised + +julia_version = "1.10.0" +manifest_format = "2.0" +project_hash = "b624ff2117a370fbbc58955a02126cf4545f031e" + +[[deps.ArgTools]] +uuid = "0dad84c5-d112-42e6-8d28-ef12dabb789f" +version = "1.1.1" + +[[deps.Artifacts]] +uuid = "56f22d72-fd6d-98f1-02f0-08ddc0907c33" + +[[deps.Base64]] +uuid = "2a0f44e3-6c83-55bd-87e4-b1978d98bd5f" + +[[deps.BitFlags]] +git-tree-sha1 = "2dc09997850d68179b69dafb58ae806167a32b1b" +uuid = "d1d4a3ce-64b1-5f1a-9ba4-7e7e69966f35" +version = "0.1.8" + +[[deps.CodecZlib]] +deps = ["TranscodingStreams", "Zlib_jll"] +git-tree-sha1 = "59939d8a997469ee05c4b4944560a820f9ba0d73" +uuid = "944b1d66-785c-5afd-91f1-9de20f533193" +version = "0.7.4" + +[[deps.ConcurrentUtilities]] +deps = ["Serialization", "Sockets"] +git-tree-sha1 = "8cfa272e8bdedfa88b6aefbbca7c19f1befac519" +uuid = "f0e56b4a-5159-44fe-b623-3e5288b988bb" +version = "2.3.0" + +[[deps.Dates]] +deps = ["Printf"] +uuid = "ade2ca70-3891-5945-98fb-dc099432e06a" + +[[deps.DelimitedFiles]] +deps = ["Mmap"] +git-tree-sha1 = "9e2f36d3c96a820c678f2f1f1782582fcf685bae" +uuid = "8bb1440f-4735-579b-a4ab-409b98df4dab" +version = "1.9.1" + +[[deps.DocStringExtensions]] +deps = ["LibGit2"] +git-tree-sha1 = "2fb1e02f2b635d0845df5d7c167fec4dd739b00d" +uuid = "ffbed154-4ef7-542d-bbb7-c09d3a79fcae" +version = "0.9.3" + +[[deps.Downloads]] +deps = ["ArgTools", "FileWatching", "LibCURL", "NetworkOptions"] +uuid = "f43a241f-c20a-4ad4-852c-f6b1247861c6" +version = "1.6.0" + +[[deps.ExceptionUnwrapping]] +deps = ["Test"] +git-tree-sha1 = "dcb08a0d93ec0b1cdc4af184b26b591e9695423a" +uuid = "460bff9d-24e4-43bc-9d9f-a8973cb893f4" +version = "0.1.10" + +[[deps.ExprTools]] +git-tree-sha1 = "27415f162e6028e81c72b82ef756bf321213b6ec" +uuid = "e2ba6199-217a-4e67-a87a-7c52f15ade04" +version = "0.1.10" + +[[deps.FileWatching]] +uuid = "7b1f6079-737a-58dc-b8bc-7a2ca5c1b5ee" + +[[deps.Franklin]] +deps = ["Dates", "DelimitedFiles", "DocStringExtensions", "ExprTools", "FranklinTemplates", "HTTP", "Literate", "LiveServer", "Logging", "Markdown", "NodeJS", "OrderedCollections", "Pkg", "REPL", "Random", "TOML"] +git-tree-sha1 = "31e70717e0640d6576fe04d611a33df1c9c312d6" +uuid = "713c75ef-9fc9-4b05-94a9-213340da978e" +version = "0.10.95" + +[[deps.FranklinTemplates]] +deps = ["LiveServer"] +git-tree-sha1 = "c01813a615149ddb3b3d133f33de29d642fbe57b" +uuid = "3a985190-f512-4703-8d38-2a7944ed5916" +version = "0.10.2" + +[[deps.HTTP]] +deps = ["Base64", "CodecZlib", "ConcurrentUtilities", "Dates", "ExceptionUnwrapping", "Logging", "LoggingExtras", "MbedTLS", "NetworkOptions", "OpenSSL", "Random", "SimpleBufferStream", "Sockets", "URIs", "UUIDs"] +git-tree-sha1 = "abbbb9ec3afd783a7cbd82ef01dcd088ea051398" +uuid = "cd3eb016-35fb-5094-929b-558a96fad6f3" +version = "1.10.1" + +[[deps.IOCapture]] +deps = ["Logging", "Random"] +git-tree-sha1 = "8b72179abc660bfab5e28472e019392b97d0985c" +uuid = "b5f81e59-6552-4d32-b1f0-c071b021bf89" +version = "0.2.4" + +[[deps.InteractiveUtils]] +deps = ["Markdown"] +uuid = "b77e0a4c-d291-57a0-90e8-8db25a27a240" + +[[deps.JLLWrappers]] +deps = ["Artifacts", "Preferences"] +git-tree-sha1 = "7e5d6779a1e09a36db2a7b6cff50942a0a7d0fca" +uuid = "692b3bcd-3c85-4b1f-b108-f13ce0eb3210" +version = "1.5.0" + +[[deps.JSON]] +deps = ["Dates", "Mmap", "Parsers", "Unicode"] +git-tree-sha1 = "31e996f0a15c7b280ba9f76636b3ff9e2ae58c9a" +uuid = "682c06a0-de6a-54ab-a142-c8b1cf79cde6" +version = "0.21.4" + +[[deps.LibCURL]] +deps = ["LibCURL_jll", "MozillaCACerts_jll"] +uuid = "b27032c2-a3e7-50c8-80cd-2d36dbcbfd21" +version = "0.6.4" + +[[deps.LibCURL_jll]] +deps = ["Artifacts", "LibSSH2_jll", "Libdl", "MbedTLS_jll", "Zlib_jll", "nghttp2_jll"] +uuid = "deac9b47-8bc7-5906-a0fe-35ac56dc84c0" +version = "8.4.0+0" + +[[deps.LibGit2]] +deps = ["Base64", "LibGit2_jll", "NetworkOptions", "Printf", "SHA"] +uuid = "76f85450-5226-5b5a-8eaa-529ad045b433" + +[[deps.LibGit2_jll]] +deps = ["Artifacts", "LibSSH2_jll", "Libdl", "MbedTLS_jll"] +uuid = "e37daf67-58a4-590a-8e99-b0245dd2ffc5" +version = "1.6.4+0" + +[[deps.LibSSH2_jll]] +deps = ["Artifacts", "Libdl", "MbedTLS_jll"] +uuid = "29816b5a-b9ab-546f-933c-edad1886dfa8" +version = "1.11.0+1" + +[[deps.Libdl]] +uuid = "8f399da3-3557-5675-b5ff-fb832c97cbdb" + +[[deps.Literate]] +deps = ["Base64", "IOCapture", "JSON", "REPL"] +git-tree-sha1 = "bad26f1ccd99c553886ec0725e99a509589dcd11" +uuid = "98b081ad-f1c9-55d3-8b20-4c87d4299306" +version = "2.16.1" + +[[deps.LiveServer]] +deps = ["HTTP", "LoggingExtras", "MIMEs", "Pkg", "Sockets", "Test"] +git-tree-sha1 = "24d05efe53436b22a42bf2ae459f47c48b0c2603" +uuid = "16fef848-5104-11e9-1b77-fb7a48bbb589" +version = "1.2.7" + +[[deps.Logging]] +uuid = "56ddb016-857b-54e1-b83d-db4d58db5568" + +[[deps.LoggingExtras]] +deps = ["Dates", "Logging"] +git-tree-sha1 = "c1dd6d7978c12545b4179fb6153b9250c96b0075" +uuid = "e6f89c97-d47a-5376-807f-9c37f3926c36" +version = "1.0.3" + +[[deps.MIMEs]] +git-tree-sha1 = "65f28ad4b594aebe22157d6fac869786a255b7eb" +uuid = "6c6e2e6c-3030-632d-7369-2d6c69616d65" +version = "0.1.4" + +[[deps.Markdown]] +deps = ["Base64"] +uuid = "d6f4376e-aef5-505a-96c1-9c027394607a" + +[[deps.MbedTLS]] +deps = ["Dates", "MbedTLS_jll", "MozillaCACerts_jll", "NetworkOptions", "Random", "Sockets"] +git-tree-sha1 = "c067a280ddc25f196b5e7df3877c6b226d390aaf" +uuid = "739be429-bea8-5141-9913-cc70e7f3736d" +version = "1.1.9" + +[[deps.MbedTLS_jll]] +deps = ["Artifacts", "Libdl"] +uuid = "c8ffd9c3-330d-5841-b78e-0817d7145fa1" +version = "2.28.2+1" + +[[deps.Mmap]] +uuid = "a63ad114-7e13-5084-954f-fe012c677804" + +[[deps.MozillaCACerts_jll]] +uuid = "14a3606d-f60d-562e-9121-12d972cd8159" +version = "2023.1.10" + +[[deps.NetworkOptions]] +uuid = "ca575930-c2e3-43a9-ace4-1e988b2c1908" +version = "1.2.0" + +[[deps.NodeJS]] +deps = ["Pkg"] +git-tree-sha1 = "bf1f49fd62754064bc42490a8ddc2aa3694a8e7a" +uuid = "2bd173c7-0d6d-553b-b6af-13a54713934c" +version = "2.0.0" + +[[deps.OpenSSL]] +deps = ["BitFlags", "Dates", "MozillaCACerts_jll", "OpenSSL_jll", "Sockets"] +git-tree-sha1 = "51901a49222b09e3743c65b8847687ae5fc78eb2" +uuid = "4d8831e6-92b7-49fb-bdf8-b643e874388c" +version = "1.4.1" + +[[deps.OpenSSL_jll]] +deps = ["Artifacts", "JLLWrappers", "Libdl"] +git-tree-sha1 = "cc6e1927ac521b659af340e0ca45828a3ffc748f" +uuid = "458c3c95-2e84-50aa-8efc-19380b2a3a95" +version = "3.0.12+0" + +[[deps.OrderedCollections]] +git-tree-sha1 = "dfdf5519f235516220579f949664f1bf44e741c5" +uuid = "bac558e1-5e72-5ebc-8fee-abe8a469f55d" +version = "1.6.3" + +[[deps.Parsers]] +deps = ["Dates", "PrecompileTools", "UUIDs"] +git-tree-sha1 = "8489905bcdbcfac64d1daa51ca07c0d8f0283821" +uuid = "69de0a69-1ddd-5017-9359-2bf0b02dc9f0" +version = "2.8.1" + +[[deps.Pkg]] +deps = ["Artifacts", "Dates", "Downloads", "FileWatching", "LibGit2", "Libdl", "Logging", "Markdown", "Printf", "REPL", "Random", "SHA", "Serialization", "TOML", "Tar", "UUIDs", "p7zip_jll"] +uuid = "44cfe95a-1eb2-52ea-b672-e2afdf69b78f" +version = "1.10.0" + +[[deps.PrecompileTools]] +deps = ["Preferences"] +git-tree-sha1 = "03b4c25b43cb84cee5c90aa9b5ea0a78fd848d2f" +uuid = "aea7be01-6a6a-4083-8856-8a6e6704d82a" +version = "1.2.0" + +[[deps.Preferences]] +deps = ["TOML"] +git-tree-sha1 = "00805cd429dcb4870060ff49ef443486c262e38e" +uuid = "21216c6a-2e73-6563-6e65-726566657250" +version = "1.4.1" + +[[deps.Printf]] +deps = ["Unicode"] +uuid = "de0858da-6303-5e67-8744-51eddeeeb8d7" + +[[deps.REPL]] +deps = ["InteractiveUtils", "Markdown", "Sockets", "Unicode"] +uuid = "3fa0cd96-eef1-5676-8a61-b3b8758bbffb" + +[[deps.Random]] +deps = ["SHA"] +uuid = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c" + +[[deps.SHA]] +uuid = "ea8e919c-243c-51af-8825-aaa63cd721ce" +version = "0.7.0" + +[[deps.Serialization]] +uuid = "9e88b42a-f829-5b0c-bbe9-9e923198166b" + +[[deps.SimpleBufferStream]] +git-tree-sha1 = "874e8867b33a00e784c8a7e4b60afe9e037b74e1" +uuid = "777ac1f9-54b0-4bf8-805c-2214025038e7" +version = "1.1.0" + +[[deps.Sockets]] +uuid = "6462fe0b-24de-5631-8697-dd941f90decc" + +[[deps.TOML]] +deps = ["Dates"] +uuid = "fa267f1f-6049-4f14-aa54-33bafae1ed76" +version = "1.0.3" + +[[deps.Tar]] +deps = ["ArgTools", "SHA"] +uuid = "a4e569a6-e804-4fa4-b0f3-eef7a1d5b13e" +version = "1.10.0" + +[[deps.Test]] +deps = ["InteractiveUtils", "Logging", "Random", "Serialization"] +uuid = "8dfed614-e22c-5e08-85e1-65c5234f0b40" + +[[deps.TranscodingStreams]] +git-tree-sha1 = "1fbeaaca45801b4ba17c251dd8603ef24801dd84" +uuid = "3bb67fe8-82b1-5028-8e26-92a6c54297fa" +version = "0.10.2" +weakdeps = ["Random", "Test"] + + [deps.TranscodingStreams.extensions] + TestExt = ["Test", "Random"] + +[[deps.URIs]] +git-tree-sha1 = "67db6cc7b3821e19ebe75791a9dd19c9b1188f2b" +uuid = "5c2747f8-b7ea-4ff2-ba2e-563bfd36b1d4" +version = "1.5.1" + +[[deps.UUIDs]] +deps = ["Random", "SHA"] +uuid = "cf7118a7-6976-5b1a-9a39-7adc72f591a4" + +[[deps.Unicode]] +uuid = "4ec0a83e-493e-50e2-b9ac-8f72acf5a8f5" + +[[deps.Zlib_jll]] +deps = ["Libdl"] +uuid = "83775a58-1f1d-513f-b197-d71354ab007a" +version = "1.2.13+1" + +[[deps.nghttp2_jll]] +deps = ["Artifacts", "Libdl"] +uuid = "8e850ede-7688-5339-a07c-302acd2aaf8d" +version = "1.52.0+1" + +[[deps.p7zip_jll]] +deps = ["Artifacts", "Libdl"] +uuid = "3f19e933-33d8-53b3-aaab-bd5110c3b7a0" +version = "17.4.0+2" diff --git a/previews/PR166/Project.toml b/previews/PR166/Project.toml new file mode 100644 index 00000000..8f357c56 --- /dev/null +++ b/previews/PR166/Project.toml @@ -0,0 +1,3 @@ +[deps] +Franklin = "713c75ef-9fc9-4b05-94a9-213340da978e" +NodeJS = "2bd173c7-0d6d-553b-b6af-13a54713934c" \ No newline at end of file diff --git a/previews/PR166/assets/FluxGitHubPreview.png b/previews/PR166/assets/FluxGitHubPreview.png new file mode 100644 index 00000000..a0e643a9 Binary files /dev/null and b/previews/PR166/assets/FluxGitHubPreview.png differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/bptt.png b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/bptt.png new file mode 100644 index 00000000..d11f1b26 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/bptt.png differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole-flow.png b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole-flow.png new file mode 100644 index 00000000..dcda8ce0 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole-flow.png differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole.gif new file mode 100644 index 00000000..90833bf1 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/cartpole.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-dp.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-dp.gif new file mode 100644 index 00000000..1c22143f Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-dp.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-training.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-training.gif new file mode 100644 index 00000000..dccbf1a8 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/pendulum-training.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-basic.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-basic.gif new file mode 100644 index 00000000..21476ec2 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-basic.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-flow.png b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-flow.png new file mode 100644 index 00000000..e577bc91 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-flow.png differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-hit.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-hit.gif new file mode 100644 index 00000000..cf453f1f Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-hit.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-miss.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-miss.gif new file mode 100644 index 00000000..b6c97ab9 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-miss.gif differ diff --git a/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-wind.gif b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-wind.gif new file mode 100644 index 00000000..fb838e15 Binary files /dev/null and b/previews/PR166/assets/blogposts/2019-03-05-dp-vs-rl/trebuchet-wind.gif differ diff --git a/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/combined_benchmarks_2.png b/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/combined_benchmarks_2.png new file mode 100644 index 00000000..17d0a0b3 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/combined_benchmarks_2.png differ diff --git a/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/resnet101.png b/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/resnet101.png new file mode 100644 index 00000000..2a27e6ea Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-06-29-acclerating-flux-torch/resnet101.png differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_metrics.png b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_metrics.png new file mode 100644 index 00000000..1a878528 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_metrics.png differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_pcloud.png b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_pcloud.png new file mode 100644 index 00000000..6d4d0cec Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_pcloud.png differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_trimesh.png b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_trimesh.png new file mode 100644 index 00000000..5f2ffe21 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/bm_trimesh.png differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/fitmesh_anim.gif b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/fitmesh_anim.gif new file mode 100644 index 00000000..ba01ece5 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/fitmesh_anim.gif differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize.png b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize.png new file mode 100644 index 00000000..1c1ae731 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize.png differ diff --git a/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize_anim.gif b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize_anim.gif new file mode 100644 index 00000000..b86a0525 Binary files /dev/null and b/previews/PR166/assets/blogposts/2020-12-20-Flux3D/visualize_anim.gif differ diff --git a/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux.png b/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux.png new file mode 100644 index 00000000..c54befa0 Binary files /dev/null and b/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux.png differ diff --git a/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux_numfocus.png b/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux_numfocus.png new file mode 100644 index 00000000..e43b32a7 Binary files /dev/null and b/previews/PR166/assets/blogposts/2021-12-1-flux-numfocus/flux_numfocus.png differ diff --git a/previews/PR166/assets/favicon_io/android-chrome-192x192.png b/previews/PR166/assets/favicon_io/android-chrome-192x192.png new file mode 100644 index 00000000..7aafc3b7 Binary files /dev/null and b/previews/PR166/assets/favicon_io/android-chrome-192x192.png differ diff --git a/previews/PR166/assets/favicon_io/android-chrome-512x512.png b/previews/PR166/assets/favicon_io/android-chrome-512x512.png new file mode 100644 index 00000000..349452ad Binary files /dev/null and b/previews/PR166/assets/favicon_io/android-chrome-512x512.png differ diff --git a/previews/PR166/assets/favicon_io/apple-touch-icon.png b/previews/PR166/assets/favicon_io/apple-touch-icon.png new file mode 100644 index 00000000..0600206d Binary files /dev/null and b/previews/PR166/assets/favicon_io/apple-touch-icon.png differ diff --git a/previews/PR166/assets/favicon_io/favicon-16x16.png b/previews/PR166/assets/favicon_io/favicon-16x16.png new file mode 100644 index 00000000..d1f35ba6 Binary files /dev/null and b/previews/PR166/assets/favicon_io/favicon-16x16.png differ diff --git a/previews/PR166/assets/favicon_io/favicon-32x32.png b/previews/PR166/assets/favicon_io/favicon-32x32.png new file mode 100644 index 00000000..f6c1630b Binary files /dev/null and b/previews/PR166/assets/favicon_io/favicon-32x32.png differ diff --git a/previews/PR166/assets/favicon_io/favicon.ico b/previews/PR166/assets/favicon_io/favicon.ico new file mode 100644 index 00000000..5fa3624d Binary files /dev/null and b/previews/PR166/assets/favicon_io/favicon.ico differ diff --git a/previews/PR166/assets/favicon_io/site.webmanifest b/previews/PR166/assets/favicon_io/site.webmanifest new file mode 100644 index 00000000..45dc8a20 --- /dev/null +++ b/previews/PR166/assets/favicon_io/site.webmanifest @@ -0,0 +1 @@ +{"name":"","short_name":"","icons":[{"src":"/android-chrome-192x192.png","sizes":"192x192","type":"image/png"},{"src":"/android-chrome-512x512.png","sizes":"512x512","type":"image/png"}],"theme_color":"#ffffff","background_color":"#ffffff","display":"standalone"} \ No newline at end of file diff --git a/previews/PR166/assets/friends/FluxGitHubPreview.png b/previews/PR166/assets/friends/FluxGitHubPreview.png new file mode 100644 index 00000000..a0e643a9 Binary files /dev/null and b/previews/PR166/assets/friends/FluxGitHubPreview.png differ diff --git a/previews/PR166/assets/friends/alan-turing.jpg b/previews/PR166/assets/friends/alan-turing.jpg new file mode 100644 index 00000000..78063fc8 Binary files /dev/null and b/previews/PR166/assets/friends/alan-turing.jpg differ diff --git a/previews/PR166/assets/friends/amd-logo.png b/previews/PR166/assets/friends/amd-logo.png new file mode 100644 index 00000000..cb80abf7 Binary files /dev/null and b/previews/PR166/assets/friends/amd-logo.png differ diff --git a/previews/PR166/assets/friends/beacon_biosignals.jpg b/previews/PR166/assets/friends/beacon_biosignals.jpg new file mode 100644 index 00000000..694acdb9 Binary files /dev/null and b/previews/PR166/assets/friends/beacon_biosignals.jpg differ diff --git a/previews/PR166/assets/friends/cambridge.jpg b/previews/PR166/assets/friends/cambridge.jpg new file mode 100644 index 00000000..350a489a Binary files /dev/null and b/previews/PR166/assets/friends/cambridge.jpg differ diff --git a/previews/PR166/assets/friends/cmu-logo.png b/previews/PR166/assets/friends/cmu-logo.png new file mode 100644 index 00000000..8b538fa7 Binary files /dev/null and b/previews/PR166/assets/friends/cmu-logo.png differ diff --git a/previews/PR166/assets/friends/edinburgh.png b/previews/PR166/assets/friends/edinburgh.png new file mode 100644 index 00000000..67fcdd4a Binary files /dev/null and b/previews/PR166/assets/friends/edinburgh.png differ diff --git a/previews/PR166/assets/friends/invenia-logo.png b/previews/PR166/assets/friends/invenia-logo.png new file mode 100644 index 00000000..3f81642f Binary files /dev/null and b/previews/PR166/assets/friends/invenia-logo.png differ diff --git a/previews/PR166/assets/friends/juliac-logo.png b/previews/PR166/assets/friends/juliac-logo.png new file mode 100644 index 00000000..e2e5afed Binary files /dev/null and b/previews/PR166/assets/friends/juliac-logo.png differ diff --git a/previews/PR166/assets/friends/mit-logo.png b/previews/PR166/assets/friends/mit-logo.png new file mode 100644 index 00000000..0ef6357b Binary files /dev/null and b/previews/PR166/assets/friends/mit-logo.png differ diff --git a/previews/PR166/assets/friends/rai-logo.png b/previews/PR166/assets/friends/rai-logo.png new file mode 100644 index 00000000..98bb1004 Binary files /dev/null and b/previews/PR166/assets/friends/rai-logo.png differ diff --git a/previews/PR166/assets/friends/ucl-logo.png b/previews/PR166/assets/friends/ucl-logo.png new file mode 100644 index 00000000..2e06ae5d Binary files /dev/null and b/previews/PR166/assets/friends/ucl-logo.png differ diff --git a/previews/PR166/assets/friends/uoft_logo.png b/previews/PR166/assets/friends/uoft_logo.png new file mode 100644 index 00000000..c6ebd4ad Binary files /dev/null and b/previews/PR166/assets/friends/uoft_logo.png differ diff --git a/previews/PR166/assets/friends/washington.jpg b/previews/PR166/assets/friends/washington.jpg new file mode 100644 index 00000000..c97b36bc Binary files /dev/null and b/previews/PR166/assets/friends/washington.jpg differ diff --git a/previews/PR166/assets/logo-small.png b/previews/PR166/assets/logo-small.png new file mode 100644 index 00000000..e0a825a5 Binary files /dev/null and b/previews/PR166/assets/logo-small.png differ diff --git a/previews/PR166/assets/logo.png b/previews/PR166/assets/logo.png new file mode 100644 index 00000000..c54befa0 Binary files /dev/null and b/previews/PR166/assets/logo.png differ diff --git a/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/cat_gan.png b/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/cat_gan.png new file mode 100644 index 00000000..a3b59c5a Binary files /dev/null and b/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/cat_gan.png differ diff --git a/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/output.gif b/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/output.gif new file mode 100644 index 00000000..33435edb Binary files /dev/null and b/previews/PR166/assets/tutorialposts/2021-10-08-dcgan-mnist/output.gif differ diff --git a/previews/PR166/blog/index.html b/previews/PR166/blog/index.html new file mode 100644 index 00000000..4af033fe --- /dev/null +++ b/previews/PR166/blog/index.html @@ -0,0 +1 @@ + Flux – Elegant ML
\ No newline at end of file diff --git a/previews/PR166/blogposts/2017-08-24-generic-gpu/index.html b/previews/PR166/blogposts/2017-08-24-generic-gpu/index.html new file mode 100644 index 00000000..30eb7a8b --- /dev/null +++ b/previews/PR166/blogposts/2017-08-24-generic-gpu/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Generic GPU Kernels

– FluxML

\ No newline at end of file diff --git a/previews/PR166/blogposts/2017-12-06-ml-pl/index.html b/previews/PR166/blogposts/2017-12-06-ml-pl/index.html new file mode 100644 index 00000000..f684b0cf --- /dev/null +++ b/previews/PR166/blogposts/2017-12-06-ml-pl/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

On Machine Learning & Programming Languages

– FluxML

\ No newline at end of file diff --git a/previews/PR166/blogposts/2018-12-03-ml-language-compiler/index.html b/previews/PR166/blogposts/2018-12-03-ml-language-compiler/index.html new file mode 100644 index 00000000..bf9f10fc --- /dev/null +++ b/previews/PR166/blogposts/2018-12-03-ml-language-compiler/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Building a Language and Compiler for Machine Learning

– FluxML

\ No newline at end of file diff --git a/previews/PR166/blogposts/2019-02-07-what-is-differentiable-programming/index.html b/previews/PR166/blogposts/2019-02-07-what-is-differentiable-programming/index.html new file mode 100644 index 00000000..bfd8f0d2 --- /dev/null +++ b/previews/PR166/blogposts/2019-02-07-what-is-differentiable-programming/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

What Is Differentiable Programming?

With four parameters I can fit an elephant, and with five I can make him wiggle his trunk.

– John Von Neumann

The idea of "differentiable programming" is coming up a lot in the machine learning world. To many, it's not clear if this term reflects a real shift in how researchers think about machine learning, or is just (another) rebranding of "deep learning". This post clarifies what new things differentiable programming (or ∂P) brings to the machine learning table.

Most importantly, differentiable programming is actually a shift opposite from the direction taken by deep learning; from increasingly heavily parameterised models to simpler ones that take more advantage of problem structure.

Brute Force with Benefits

Differentiability is the core idea that makes deep learning so successful. Where a brute force search over even a few hundred model parameters would be far too expensive, gradients mean that we can take a pseudo-random walk around interesting parts of parameter space and find a good set. Doing the next-dumbest thing to brute force gives up surprisingly little generality; it's far from obvious that we can come up with a differentiable objective when, say, working with sequences in language translation, but it turns out to be straightforward with a little ingenuity.

What about biological neurons and \(y = σ(W \times x + b)\)? There's nothing particularly special about this formula; it's just a simple and flexible example of a highly-parameterised non-linear function. In fact, it's probably the worst such function in most cases. A single neural net layer can, in principle, classify cat pictures, but only by the relatively uninteresting trick of acting as a lookup table. It's guaranteed to work! – but the small print warns that you may need more parameters than there are atoms in the universe. To actually make it work you need to encode problem structure in the model – which is where it starts to look a lot more like traditional programming.

For example, ConvNets have a huge advantage over the perceptron because they re-use image kernels, which are long known to exploit translational invariance. An edge is an edge whether it shows up in the top left of an image or the centre, but where a perceptron would have to learn this case by case, a kernel can respond to any part of the image at once. It's hard to analyse convolutional nets in statistical terms, but much easier to see them as an auto-tuned version of what image processing experts used to write by hand. The image kernel is the first and simplest differentiable program.

Encoding Structure, Redux

ML toolkits increasingly support algorithmic differentiation (AD), allowing us to differentiate models with for loops, branches and recursion – or any program built on a set of differentiable mathematical primitives. This has led to more complex architectures: NLP models increasingly look more like classical grammar parsers with stack-augmented models, and one can even implement a Turing machine analog or a programming language interpreter in a differentiable way.

The final step taken by differentiable programming is to no longer see matrix multiplies, convolutions and RNNs as the fundamental building blocks of deep learning, but instead as mere special cases. We can apply the techniques of deep learning to any parameterised, differentiable function \(f(x)\). \(f\) could be a matrix multiply, but functions as complex as physics simulators or ray tracers can be differentiated and optimised just as well. Even quantum computation can fit into this framework.

Scientists have long used mechanistic models that sit between explicit programming and machine learning. Differential equations fit to data via sensitivities – as in physics, epidemiology or pharmacodynamics – are equivalent in all but terminology to neural networks. They are just far more constrained in what functions they can represent, making it easier to get a good result.

The really powerful advance is this: pervasive differentiability means all these techniques snap together like lego bricks. Rather than always writing new programs for ML, we can incorporate existing ones, enabling physics engines inside deep learning-based robotics models. Where current reinforcement learning algorithms need to build a detailed model of the external world from only a coarse-grained reward signal (which sounds like a brute force problem if anything does), we can instead just drop in detailed, precise knowledge of physical systems before training even begins.

Even the most mature areas of deep learning are not left out; after the convolution kernel, a natural next step for image models is the differentiable ray tracer. A 3D renderer contains a lot of structural knowledge about how scenes map to pixels, and this, too, can go in our melting pot. Say a model makes decisions in a simulated environment, rendered as pixels that the model uses as input. In principle we can now make the whole loop differentiable, letting us directly see the influence of the environment on the model's decisions and vice versa. This could greatly increase the power of realistic simulated environments for training models like self-driving cars.

As in the sciences, hybrid models can both be more effective and resolve some of the tradeoffs between deep learning and explicit programming. For example, a drone's flight-path planner might have a neural network component that can only make provably small adjustments to a reliable explicit program, making its overall behaviour analysable while still adapting to empirical data. This is also good for interpretability: parameters of mechanistic models and simulations typically have clear physical interpretations, so if a model estimates parameters internally, it's making a clear statement about what it thinks is happening outside.

If this is all so wonderful, why isn't everybody doing it already? Unfortunately, limitations of current frameworks make it difficult to build models of this complexity, and impossible to reuse the wealth of knowledge embedded in existing scientific code. The need to re-implement physics engines from scratch, in a constrained modelling language – usually with significant limitations – turns what should be a ten-line script into a multi-year research project. But advances in language and compiler technology, especially automatic differentiation, are bringing us closer to the holy grail: "just differentiate my game engine, please."

So, what is differentiable programming?

Differentiable programming applies the techniques of deep learning to complex existing programs, taking advantage of the huge amount of knowledge embedded within them. Deep learning, statistics, programming and the sciences all have something to say about modelling the world around us, and it's time to put these fields into a particle collider. This will both improve current models and enable ML to be applied in areas where its current limitations – either interpretability or its computational and data requirements – make it infeasible alone.

Thanks to Hannah Lepper and James Bradbury for feedback on this post.

– Mike Innes

\ No newline at end of file diff --git a/previews/PR166/blogposts/2019-03-05-dp-vs-rl/index.html b/previews/PR166/blogposts/2019-03-05-dp-vs-rl/index.html new file mode 100644 index 00000000..1c5c0ae1 --- /dev/null +++ b/previews/PR166/blogposts/2019-03-05-dp-vs-rl/index.html @@ -0,0 +1,5 @@ + Flux – Elegant ML

Differentiable Control Problems

We've discussed the idea of differentiable programming, where we incorporate existing programs into deep learning models. This article shows what ∂P can bring to some simple but classic control problems, where we would normally use black-box Reinforcement Learning (RL). ∂P-based models not only learn far more effective control strategies, but also train orders of magnitude faster. The code is all available to run for yourself – they will mostly train in a few seconds on any laptop.

Follow the Gradient

Differentiation is what makes deep learning tick; given a function \(y = f(x)\) we use the gradient \(\frac{dy}{dx}\) to figure out how a change in \(x\) will affect \(y\). Despite the mathematical clothing, gradients are actually a very general and intuitive concept. Forget the formulas you had to stare at in school; let's do something more fun, like throwing stuff.

When we throw things with a trebuchet, our \(x\) represents a setting (say, the size of the counterweight, or the angle of release), and \(y\) is the distance the projectile travels before landing. If you're trying to aim, the gradient tells you something very useful – whether a change in aim will increase or decrease the distance. To maximise distance, just follow the gradient.

Alright, but how can we get this magical number? The trick is a process called algorithmic differentiation, which is able to differentiate not only simple formulas like you learned in school, but also programs of any complexity – like our trebuchet simulator. The upshot is that we can take a simple simulator, written in Julia and DiffEq with no deep learning in mind, and get gradients for it in a single function call.

# what you did in school
+gradient(x -> 3x^2 + 2x + 1, 5) # (32,)
+# something a little more advanced
+gradient((wind, angle, weight) -> Trebuchet.shoot(wind, angle, weight),
+         -2, 45, 200) # (4.02, -0.99, 0.051)

Now we have that, let's do something interesting with it.

Throwing Stuff

A simple way to use this is to aim the trebuchet at a target, using gradients to fine-tune the angle of release; this kind of thing is common under the name of parameter estimation, and we've covered examples like it before. We can make things more interesting by going meta: instead of aiming the trebuchet given a single target, we'll optimise a neural network that can aim it given any target. Here's how it works: the neural net takes two inputs, the target distance in metres and the current wind speed. The network spits out trebuchet settings (the mass of the counterweight and the angle of release) that get fed into the simulator, which calculates the achieved distance. We then compare to our target, and backpropagate through the entire chain, end to end, to adjust the weights of the network. Our "dataset" is a randomly chosen set of targets and wind speeds.

A nice property of this simple model is that training it is fast, because we've expressed exactly what we want from the model in a fully differentiable way. Initially it looks like this:

After about five minutes of training (on a single core of my laptop's CPU), it looks like this:

If you want to try pushing it, turn up the wind speed:

It's only off by 16cm, or about 0.3%.

What about just aiming the trebuchet directly? It is easy to do this by gradient descent given that we have gradients. However, this is a slow iterative process that takes around 100ms each time. In contrast, running the neural network takes 5μs (twenty thousand times faster) with only a small loss in accuracy. This "approximate function inversion via gradients" trick is a very general one that can not only be used with dynamical systems, but also lies behind the fast style transfer algorithm.

This is about the simplest possible control problem, which we use mainly for illustrative purposes. But we can apply the same techniques, in more advanced ways, to classic RL problems as well.

Cart, meet Pole

A more recognisable control problem is CartPole, the "hello world" for reinforcement learning. The task is to learn to balance an upright pole by nudging its base left or right. Our setup is broadly similar to the trebuchet case: a Julia implementation means we can directly treat the reward produced by the environment as a loss. ∂P allows us to switch seamlessly from model-free to model-based RL.

The astute reader may notice a snag. The action space for cartpole – nudge left or right – is discrete, and therefore not differentiable. We solve this by introducing a differentiable discretisation, defined like so:

\[ \begin{aligned} f(x) &= \begin{cases} 1 & x \ge 0 \\\ -1 & x < 0 \end{cases} \\\ \frac{df}{dx} &= 1 \end{aligned} \]

In other words, we force the gradient to behave as if \(f\) were the identity function. Given how much the mathematical idea of differentiability already gets abused in ML, it's perhaps not surprising that we can just cheat here; for training all we need is a signal to inform our pseudo-random walk around parameter space, and the rest is details.

The results speak for themselves. Where RL methods need to train for hundreds of episodes before solving the problem, the ∂P model only needs around 5 episodes to win conclusively.

The Pendulum & Backprop through Time

An important aim for RL is to handle delayed reward, when an action doesn't help us until several steps in the future. ∂P allows this too, and in a very familiar way: when the environment is differentiable, we can actually train the agent using backpropagation through time, just like a recurrent net! In this case the environmental state becomes the "hidden state" that changes between time steps.

To demonstrate this technique we looked at the pendulum environment, where the task is to swing a pendulum until it stands upright, keeping it balanced with minimal effort. This is hard for RL models; after around 20 episodes of training the problem is solved, but often the route to a solution is visibly sub-optimal. In contrast, BPTT can beat the RL leaderboard in a single episode of training. It's instructive to actually watch this episode unfold; at the beginning of the recording the strategy is random, and the model improves over time. The pace of learning is almost alarming.

Despite only experiencing a single episode, the model generalises well to handle any initial angle, and has something pretty close to the optimal strategy. When restarted the model looks more like this.

This is just the beginning; we'll get the real wins applying DP to environments that are too hard for RL to work with at all, where rich simulations and models already exist (as in much of engineering and the sciences), and where interpretability is an important factor (as in medicine).

The Map Is Not The Territory

The limitation of these toy models is that they equate the simulated training environment with the test environment; of course, the real world is not differentiable. In a more realistic model the simulation gives us a coarse outline of behaviour that is refined with data. That data informs (say) the simulated effect of wind, in turn improving the quality of gradients the simulator passes to the controller. Models can even form part of a controller's forward pass, enabling it to refine its predictions without having to learn system dynamics from scratch. Exploring these new architectures will make for exciting future work.

Coda

The core idea is that differentiable programming, where we simply write an arbitrary numerical program and optimise it via gradients, is a powerful way to come up with better deep learning-like models and architectures – especially when we have a large library of differentiable code to hand. The toy models described are really only previews, but we hope they give an intuition for how these ideas can be applied in more realistic ways.

Just as functional programming involves reasoning about and expressing algorithms using functional patterns, differentiable programming involves expressing algorithms using differentiable patterns. Many such design patterns have already been developed by the deep learning community, such as for handling control problems or sequence and tree structured data. As the field matures, many more will be invented, and the resulting programs are likely to make even the most advanced current deep learning architectures look crude by comparison.

– Mike Innes, Neethu Maria Joy, Tejan Karmali

\ No newline at end of file diff --git a/previews/PR166/blogposts/2019-05-30-JSoC-Cohort/index.html b/previews/PR166/blogposts/2019-05-30-JSoC-Cohort/index.html new file mode 100644 index 00000000..7284e549 --- /dev/null +++ b/previews/PR166/blogposts/2019-05-30-JSoC-Cohort/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

JSoC Cohort

We are excited to introduce our JSoC students accepted this year! Flux is hosting 6 JSoC students this time. They are a mix of students funded by Google Summer of Code and Julia Season of Contributions, which is run by the community, thanks to the generous support from NumFOCUS. Large parts of Flux ecosystem were created or improved by the students accepted through JSoC, many of whom have gone on to become long time contributors to FluxML. This year, we are proud to have students who will be working on a variety of sub-domains of Machine Learning, ranging from Differentiable Programming and Reinforcement Learning to GAN and Ray Tracing; to demonstrate a fresh approach to these paradigms using Julia.

Shreyas Kowshik: Addition Of Baseline Models To Flux.jl

The current state of the art algorithms in terms of reinforcement learning and generative models are not yet available in Flux. This project aims to add the following models with explicit documentation in the form of blog and code :

  • CycleGAN

  • pix2pix

  • Proximal Policy Optimization

  • Trust Region Policy Optimization

  • Neural Image Captioning

  • Deep Recurrent Q Networks

  • Super Resolution GAN

Kartikey Gupta: Reinforcement Learning Environments for Julia

This project aims at providing a collection of Reinforcement Learning environments, to facilitate research and experimentation in RL, in spirit of the OpenAI Gym. This includes the classic control environments, algorithmic environments, toy text examples, 2D game environments, Atari 2600 based game environments and a major part of the MuJoCo based robotic environments, along with their documentation and working examples. A differentiable NES (Nintendo Entertainment System) emulator will also added and available to this collection. Progress can be tracked here. Link to Project Blog

Manjunath Bhat: Enriching Model Zoo with Deep Learning Models

The aim of this project is to enrich Flux Model Zoo with unsupervised deep learning models, in particular variants of Generative Adversarial Networks. This project proposes to add the following models:

  • Spatial Transformer Networks

  • StarGAN for facial expression synthesis

  • VAE-GAN

  • Energy Based GAN

  • Gated Recurrent Convolutional Neural Network

Link to Project Blog

Raghvendra Gupta: Sparsifying Neural Networks using Sensitivity Driven Regularization

This project aims to quantify the output sensitivity to the parameters i.e. their relevance to network output and introduce a regularization term that gradually lowers the absolute value of sub-sensitive parameters. Thus a very large fraction of parameters approach zero and are eventually set to zero by simple thresholding. The models on which the sparsification experiment would be carried out are:

  • VGG16

  • VGG19

  • MobileNet

  • ResNet

  • RL models (extended goal)

The success of the experiment would be measured using Memory Footprint of the parameters, Compression Ratio and Runtime Performance of the models. Link to Project Blog

Avik Pal: Differentiable Ray Tracing

Ray Tracing is a rendering technique which allows us to create photorealistic images given the scene information. However, at times given an image, we want to infer the state of the scene, i.e., the light sources, materials of the objects, the orientation of the camera, etc. Being able to incorporate the ability to differentiate through the ray tracer allows us to calculate gradients wrt arbitrary scene parameters and in turn, optimize them to obtain their exact values. Apart from this, the ray tracer can be used to train a self-driving car using BPTT (Back Propagation through Time). The package is available at here.

Tejan Karmali: Differentiable Duckietown

Duckietown is an environment for autonomous vehicles research. It is a miniature town through which a car (or bot) needs to be navigated through. The town has multiple maps, which are different tasks the bot has to perform. The maps vary from a simple straight road to full fledged town. Over the summer I’ll be building this environment in julia, integrating it with the differentiable ray tracer to render the scene, and training the the bot for different tasks mentioned above. The package and progress can be tracked here

– Tejan Karmali, Shreyas Kowshik, Kartikey Gupta, Manjunath Bhat, Avik Pal, Raghvendra Gupta

\ No newline at end of file diff --git a/previews/PR166/blogposts/2019-09-11-simulating-the-motion-of-charges/index.html b/previews/PR166/blogposts/2019-09-11-simulating-the-motion-of-charges/index.html new file mode 100644 index 00000000..7957bac9 --- /dev/null +++ b/previews/PR166/blogposts/2019-09-11-simulating-the-motion-of-charges/index.html @@ -0,0 +1,91 @@ + Flux – Elegant ML

Simulating the Motion of Charged Bodies

“We demand rigidly defined areas of doubt and uncertainty!” – Douglas Adams, The Hitchhiker's Guide To The Galaxy

What do charges like doing?

The answer is quite simple: like charges like to move apart and unlike charges like to move closer. If I were to place a 100 charges in a circle of radius 5cm and tell them to do their thing they would contentedly move around so that they attain the most stable state – where the total potential energy of the system is minimum. The problem is that even though charges know what their purpose is in life, and we know more or less what they’d tend to do, it’s quite difficult to predict their exact movements. Most of us can predict the movement of 3 or 4 charged bodies, but when it comes to accounting for the interactions of a 100 charges, the teachings of H.C. Verma and Resnick Halliday aren’t enough to help us.

The Main Idea

What is the objective of my system of 100 charges? To minimise the total value of this potential energy. (Coincidentally this is the objective of the entire universe as well) What is the objective of a typical machine learning model? To minimise the total cost/loss. Hmm…

I’m going to see if I can predict the behaviour of a system of a 100 charges by differentiating the total potential energy and performing gradient descent on the x and y coordinates of each charge. What should happen is that the x and y coordinates start changing themselves to minimise the total potential energy. Therefore, the charges start moving to minimise the total potential energy, mimicking what would happen in the real world.

The Obvious Approach vs My Approach

The Obvious Approach

The solution to this problem that immediately comes to mind is to use the amazing computing power we possess to resolve the vector components of the 99 forces on each of the 100 charges we have, use that net force to predict the acceleration of the charges, use that acceleration to produce movement in the charges, and repeat the process within a very short time interval to produce as continuous and as accurate a movement as possible.

My Approach

Why do charges move? Due to acceleration. Where does acceleration come from? Force. Why is force applied? To lower potential energy. Therefore, it’s potential energy that’s really pulling the strings. What I’ve done is cut out the middleman that is force. I’ve changed my objective from simulating the effect that force has on charged bodies to directly simulating the effect that potential energy has on it. (This may seem like the same thing, and the fact that it does is why I can do it) The main advantage to doing so is that potential energy is a scalar quantity whereas force is a vector. Calculating the net potential energy of a system of 100 charges is a lot easier than calculating the net force on each charge in a 100-charge system.

The Science Part of It

Let’s look at our classic formula to calculate potential energy

\[U = \frac{1}{4 \pi \epsilon_0}\frac{q_1q_2}{r}\]

It quantifies the potential energy \(U\) of a system of two point-charges with magnitudes q1 and q2, separated by a distance r in free space (vacuum).

If we want the total potential energy of a system of \(n\) charges, we just apply this formula \(^nC_2\) times.

Let's Begin

I’m going to create a system of 100 charged bodies and initialise them with random charge values. I’m sampling from a Gaussian Distribution since I’d like there to be a few slightly larger charges in the mix to make things interesting.

struct Vertex            # represents the charged body
+  charge::Float64
+  pos::Vector{Float64} # x,y coordinates
+end
+
+# Create the req no. of charges with random positions and amplitudes
+function create_env(no_ch)
+  [Vertex(randn(), rand(-5:0.001:5, 2)) for _ in 1:no_ch]
+end

I’m also going to place these charges randomly in a circle of radius 5cm centred at the origin.

Later on, I’ll make sure that these charges never leave this circle. Why is this important? If I happen to get a couple of large charges with the same sign and these charges were allowed to go anywhere they wanted to, they would simply move apart to infinity, dragging all the smaller charges with them, and we wouldn’t get to see much.

I’m also going to create a simple function to calculate potential.

function potential(a::Vertex, b::Vertex) # classic potential formula
+  return (8.9e9)*a.charge*b.charge/(sqrt(sum(abs2.(a.pos .- b.pos))))
+end
+
+function potential(a::Vector) # potential for a system of charges
+  pot = 0
+  for i in 1:length(a) # nC2
+    for j in i+1:length(a)
+      pot = pot+potential(a[i],a[j])
+    end
+  end
+  return pot
+end

Now I’m going to define my loss function. Why can’t I just use my potential function? The reason is that I want to constrain my charges to a circle. The way I do that is by applying a high penalty(loss) every time a charge tries to move out of the circle.

function loss(env::Vector)
+  s = 0
+  for i in 1: length(env)
+    # if charge moves outside circle of radius 5 centred at origin,
+    # give it a high penalty
+    # this is to constrain it otherwise large like charges would
+    # just go to infinity and we wouldn't see much
+    if distance(env[i], [0,0])-5>0          
+      s = s+100*(distance(env[i],[0,0])-5)        
+    end
+  end
+  # scaling potential so the distance moved is acceptably small
+  l =  s + 1.0e-9*potential(env)                      
+  return l
+end

Since the potential function gives a very high value of the order of 10<sup>9</sup> we need to scale it so that the loss is a low enough value to produce an acceptable movement in my charges.

Let’s create the environment of charges

env = create_env(100)
+

I’m using 2 main machine learning libraries. Zygote, for its AD capabilities, and Flux, for its optimisers.

+
using Zygote
+using Flux
+

Let’s start moving these charges around

+
opt = ADAM(0.01)
+for i in 1:200
+  gs = Zygote.gradient(loss, env)
+  for j in 1: length(gs[1]) # each j is a charge
+    # making sure we update only the positions not the charge value
+    Flux.Optimise.update!(opt, env[j].pos, gs[1][j].pos)
+  end
+end
+

Using some basic plotting functions, I graphed my charges at every training iteration and put them all together in a gif.

+

+

Red charges are positive, Blue charges are negative and size of the dot is proportional to the absolute value of charge.

+

The Big Question. It looks cool, but does it work?

+

A high-level observation shows that the like charges tend to move apart and the unlike charges tend to move closer. We can take a step further and notice that as time progresses, the charges tend to move less and less since they are more or less in a stable position. A sure sign of convergence.

+

Let’s prove this.

+

Let’s take a trivial case and define a system of two charges: one positive and one negative. Let’s place them diametrically opposite with respect to the origin.

+

+

What do we expect to happen? The charges should move together.

+

+

And they do!

+

(What’s interesting is that they seem to have overshot and actually crossed each other at one point, only to get drawn to each other once more. An apt parallel is charges overshooting due to inertia of motion)

+

Let’s go back to that system of 100 charges and plot the potential energy at every training iteration.

+

It’s safe to say that the system has converged at a value of approximately -1360 .

+

You’re probably wondering why the graph is so bumpy and what these extreme minimas are. The minimas are simply the points in the training loop when the charges got a bit overconfident and tried to escape the constraining circle. They are then immediately brought back to valid positions by the loss function. They may also occur when a positive and a negative charge briefly overlap with each other giving a potential of negative infinity. Of course, such a situation is impossible in the real world.

+

Conclusion

+

It works! I created this simulation because it’s an interesting and very visual way to get a real feel of how charges move around when affected by almost a 100 different forces. It also shows how it’s possible to solve a problem more easily by reframing the question being asked. ~~Simulate the effect of force on charged bodies?~~ Simulate the effect of potential energy on charged bodies? Most of all it shows the power of gradient descent in solving a problem that would be unwieldy to solve using classic approaches.

+ +

– Sudhanshu Agrawal sudhanshuagr27@ucla.edu

+ + + +
+ + +
+
+ + + + + + + + + + + + \ No newline at end of file diff --git a/previews/PR166/blogposts/2020-06-29-acclerating-flux-torch/index.html b/previews/PR166/blogposts/2020-06-29-acclerating-flux-torch/index.html new file mode 100644 index 00000000..ae265dcd --- /dev/null +++ b/previews/PR166/blogposts/2020-06-29-acclerating-flux-torch/index.html @@ -0,0 +1,51 @@ + Flux – Elegant ML

Accelerating Flux.jl with PyTorch kernels

Julia and Flux provide a flexible differentiable programming system. Flux does not trade flexibility and abstraction for performance, and in fact strives to achieve both in the same package. For example, Flux is able to target multiple hardware accelerators such as GPUs and TPUs. As a result, it is one of the pillars of Julia's deep learning ecosystem, with almost 40 packages leveraging it.

Here, we introduce Torch.jl, a package that wraps optimised kernels from PyTorch. Even though Julia's GPU compiler is already pretty good for general use and under heavy development, we provide Torch.jl to leverage well-debugged high performance kernels that have been built by the PyTorch community, much in the same way we use BLAS and LAPACK for Linear Algebra.

For popular object detection models - ResNet50, ResNet101 and VGG19 - we compare inference times for Flux using Torch.jl with our native tooling, and find Flux+Torch to be 2-3x faster. On larger batch sizes, the difference is much higher, since Julia's GPU stack needs further development in the area of memory management and GC.

All runs are with a Tesla K40 (12 GB), julia v1.4.2, Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz and 32 GB of DDR3 Memory.

This project achieves two things. It brings state of the art performance to Julia users who need it today with no fuss, while simulatneously providing benchmarks to identify areas of improvement in the Julia GPU compiler stack, and track them.

Usage

Adding Torch.jl is easy. It assumes the presence of a CUDA enabled GPU on the device it is being added to, and assumes a linux system.

Moving models over to PyTorch kernels; introducing torch

Users of Flux are familiar with calling the gpu(model) API to accelerate their models with GPUs. The API for Torch.jl is just as simple - torch(model).

julia> using Metalhead
+
+julia> resnet = ResNet()
+
+julia> torch_resnet = resnet |> torch

Of course this is not just limited to ResNet. Many architectures would benefit from this - such as VGG, DenseNet, Inception etc. Check out Metalhead.jl for some common computer vision models. It also helps improve performance in models such as YOLO via ObjectDetector.jl. In addition, large hard to train models like RCNNs also benefit from these kernels.

Installation

# Type `]` to enter Pkg mode in the Julia REPL.
+pkg> add Torch
+[...] # Note that this downloads the Torch artifact, which is quite large
+
+julia> using Torch

Simple, intuitive API

Our APIs make the PyTorch Tensors mimic Julia arrays closely, in order to provide a Julian experience to Flux users. Torch.jl provides the Tensor type which closely follows the semantics of a regular Julia array, albeit while being managed by PyTorch. One can create a tensor with an API similar to rand or zeros.

julia> z = Tensor(3,3)
+3×3 Tensor{Float32,2} :
+ 0.0  0.0  0.0
+ 0.0  0.0  0.0
+ 0.0  0.0  0.0

Controlling the device the tensor is loaded on (the default being on CPU) is done via the dev keyword, available in most functions.

julia> z = Tensor(3,3, dev = 0)
+3×3 Tensor{Float32,2} :
+ 0.0  0.0  0.0
+ 0.0  0.0  0.0
+ 0.0  0.0  0.0

Note that setting dev to -1 implies the CPU, and [0,...] represents the ID of the GPU we intend to load the tensor on. The default GPU is assumed to be 0. Torch.jl also defines the torch function which behaves like the gpu function already in Flux, moving over structs to Torch instead of CUDA.jl.

julia> using Flux, Metalhead, Torch
+
+julia> using Torch: torch
+
+julia> resnet = ResNet() # from Metalhead
+ResNet()
+
+julia> tresnet = resnet |> torch
+ResNet()

We can verify that that we have moved the model parameters to Torch.jl by checking out params.

julia> typeof.(Flux.params(tresnet))
+212-element Array{DataType,1}:
+ Tensor{Float32,4}
+ Tensor{Float32,1}
+[...]

It is also possible to move regular Julia arrays back and forth from Torch.jl using the tensor helper function.

julia> r = rand(Float32, 3,3)
+3×3 Array{Float32,2}:
+ 0.435017  0.287086  0.105608
+ 0.636305  0.398222  0.0682819
+ 0.74551   0.944293  0.387852
+
+julia> tr = tensor(r, dev = 0) # 0 => GPU:0
+3×3 Tensor {Float32,2}:
+ 0.435017  0.287086  0.105608
+ 0.636305  0.398222  0.0682819
+ 0.74551   0.944293  0.387852
+
+julia> collect(tr)
+3×3 Array{Float32,2}:
+ 0.435017  0.287086  0.105608
+ 0.636305  0.398222  0.0682819
+ 0.74551   0.944293  0.387852

Taking gradients

We can use the Zygote.jl reverse mode AD to differentiate the models using Torch.jl tensors, just like we would with regular Julia Arrays.

julia> ip = rand(Float32, 224, 224, 3, 1);
+
+julia> tip = tensor(ip, dev = 0);
+
+julia> gs = gradient(Flux.params(tresnet)) do
+         sum(tresnet(tip))
+       end;

We can now use this gradient to train our models.

Additional Remarks

In Torch.jl, our aim is also to change as little user code as possible, making it easy to get started with. We invite the community to contribute more kernels and provide features from PyTorch that Julia users might be interested in. For feature requests and issues that you might run into with Torch.jl, please open issues on our GitHub issue tracker. Contributions via pull requests are highly encouraged!

We look forward to seeing folks try it out and let us know on discourse about their experiences. Cheers!

– Dhairya Gandhi, Mike Innes

\ No newline at end of file diff --git a/previews/PR166/blogposts/2020-12-20-Flux3D/index.html b/previews/PR166/blogposts/2020-12-20-Flux3D/index.html new file mode 100644 index 00000000..24ebc903 --- /dev/null +++ b/previews/PR166/blogposts/2020-12-20-Flux3D/index.html @@ -0,0 +1,82 @@ + Flux – Elegant ML

Flux3D.jl, 3D Vision Library in Julia

3D computer vision involves various computer vision techniques like classification, segmentation, object detection, super-resolution and many more. Modeling these problems becomes significantly easier when there is a general purpose differentiation library available, alongside the litany of tools needed to solve a train ML model, which FluxML already supports.

Performing 3D vision tasks involve preparing datasets to fit a certain representation and applying transforms to them. Further, Flux3D exports common 3D metrics for use in designing the loss objective and various 3D layers, which have been optimised for performance for large datasets, typical in vision-based tasks.

What is Flux3D.jl

Flux3D.jl is a 3D vision library, written completely in Julia. This package utilizes Flux.jl and Zygote.jl as its building blocks for training 3D vision models and for supporting differentiation. This package also has the support of CUDA GPU acceleration with CUDA.jl. Some of the roles of Flux3D are:

  • 3D Structures - Accelerated Batched Data structure for PointCloud, VoxelGrid and TriMesh for storing and computation.

  • Transforms - Multiple transforms for PointCloud, VoxelGrid and TriMesh

  • Metrics - metrics like chamfer_distance, laplacian loss and edge loss for defining loss objectives.

  • Dataset - ModelNet10/40 (in multiple variants like pointcloud, mesh, voxel) and a Minimal Custom Dataset wrapper.

  • Conversions - Interconversion between different 3D structure (this also help in building different variants of the dataset)

  • Visualize - visualizing PointCloud, TriMesh and VoxelGrid

  • 3D Deep Learning - Implementations of some commonly used 3D layers and models.

Flux3D.jl : github.com/FluxML/Flux3D.jl

Docs : fluxml.ai/Flux3D.jl/stable

Benchmarks for Flux3D.jl

Kaolin is a popular 3D vision library based on PyTorch. Flux3D.jl is overall faster than Kaolin in terms of applying transforms on PointCloud/TriMesh and comparable with Kaolin in terms of applying metrics. However, there must be work done to improve the back pass in laplacian loss which uses SparseArrays. From the benchmarks, we can tell that Flux3D can outperform Kaolin. Some key-differences between the two are discussed later in this post.

Short Walkthrough of the Flux3D.jl

A basic training pipeline requires preparing the datasets, defining the model, the loss function and finally training it. Let's go through each step along with visualising and evaluating the results.

  1. Handling 3D DataPoint

Pointcloud, triangle mesh and voxels are three widely used representation for 3D data and most of the 3D vision work is also based on these structures. To apply transforms to our data, we need to initialise it.

julia> using Flux3D
+
+julia> m = load_trimesh("airplane.off", "teapot.obj") |> gpu
+TriMesh{Float32, UInt32, CUDA.CuArray} Structure:
+    Batch size: 2
+    Max verts: 17443
+    Max faces: 17116
+    offset: -1
+    Storage type: CuArray
+
+julia> p = PointCloud(m)
+PointCloud{Float32} Structure:
+    Batch size: 2
+    Points: 3000
+    Normals: 0
+    Storage type: CuArray{Float32,3}
+
+julia> v = VoxelGrid(m)
+VoxelGrid{Float32} Structure:
+    Batch size: 2
+    Voxels features: 64
+    Storage type: CuArray{Float32,4}
+
+julia> t = NormalizeTriMesh(inplace=false)
+NormalizeTriMesh(;inplace=false)
+
+julia> m2 = t(m)
+TriMesh{Float32, UInt32, CUDA.CuArray} Structure:
+    Batch size: 2
+    Max verts: 17443
+    Max faces: 17116
+    offset: -1
+    Storage type: CuArray
+
+julia> save_trimesh("normalize_aiplane.obj",m2,1)

  1. Preparing Dataset

ModelNet10/40 is one of the widely used 3D dataset, and we can easily access and preprocess this dataset for use in various vision-based tasks using Flux3D. We can also use conversion transforms for using ModelNet10/40 in multiple representations like PointCloud, TriMesh, VoxelGrid.

julia> using Flux3D, Makie
+
+julia> dset = ModelNet10(categories=["monitor","chair"])
+ModelNet Dataset:
+    root: /root/.julia/packages/Flux3D/9bMbc/datasets/
+    train: true
+    length: 1354
+    transform: nothing
+    categories: 2
+
+julia> dset[1]
+DataPoint:
+    idx: 1
+    data: TriMesh{Float32,UInt32,Array}
+    ground_truth: 1
+    category_name: monitor

We can use conversion transforms to convert the dataset to VoxelGrid. Similarily we can convert VoxelGrid, TriMesh and PointCloud to any 3D structure either using transforms or simply using the regular constructor.

julia> t = Chain(NormalizeTriMesh(), TriMeshToVoxelGrid(64))
+Chain(NormalizeTriMesh(;inplace=true), TriMeshToVoxelGrid(resolution=64))
+
+julia> dset2 = ModelNet10(train=false, transform=t)
+dset2 = ModelNet Dataset:
+    root: /root/.julia/packages/Flux3D/9bMbc/datasets/
+    train: false
+    length: 908
+    transform: Chain(NormalizeTriMesh(;inplace=true), TriMeshToVoxelGrid(resolution=64))
+    categories: 10
+
+julia> dset2[1]
+DataPoint:
+    idx: 1
+    data: VoxelGrid{Float32}
+    ground_truth: 1
+    category_name: bathtub

  1. Defining Model/Loss

Loss objectives and designing model solely depend upon the requirement of tasks, and with the help of FLuxML ecosystem, we can define any custom model as well as loss. There are some commonly used metrics and predefined 3D models which can assist in 3D specific tasks like chamferdistance, laplacianloss and edge_loss.

julia> chamfer_distance(p,p)
+1.58147f-5
+
+julia> laplacian_loss(m)
+6.72288
+
+julia> edge_loss(m)
+2110.6

  1. Training

Flux and Zygote takes care of everything here :)

Additonally, 3D structures and all relevant transforms, as well as metrics, are compatible with Zygote for supporting differentiation.

  1. Visualization and Evaluation

Flux3D provides a function visualize for visualizing 3D structures. This function uses Makie for plotting. We can use this same function for visualizing all three 3D structures PointCloud, TriMesh, and VoxelGrid

julia> using Makie
+
+julia> vbox(
+    hbox(
+        visualize(m,1),visualize(p,1,markersize=25)
+        ),
+    hbox(
+        visualize(v,1), visualize(v,1,algo=:MarchingCubes)
+        ),
+    )

Why use Julia and FluxML ecosystem

Kaolin is written majorly in the lower language C++ and uses CUDA-C for using GPU which is integrated with python for API interface. But with Flux3D, it is written purely in Julia and with the help of CUDA.jl we are also able to leverage GPU acceleration with the same code. This surely emphasizes the benefit of using Julia Language for intense computation like 3D vision while using high-level functions like any other modern language.

FluxML ecosystem uses Zygote as the AD engine which doesn't require the input and variable to be present in any special form (like Tensors in PyTorch), instead, we can simply define a function without doing mutation and Zygote will calculate gradients for us. Therefore we can make this package compatible with FluxML ecosystem without doing any extra work and even with many other packages like SciML differential equations ecosystem.

There are various Julia packages (thanks to awesome Julia community!) which make Flux3D.jl possible. With the help of Makie ecosystem, we can easily interact, visualize 3D structures, save the plots and gifs. NearestNeighbors.jl which is high performance nearest neighbour search library also makes it possible to perform intense computation metrics like chamfer distance even on CPU.

Conclusion

As all the batched structure for PointCloud, TriMesh, and VoxelGrid are stable enough, we can easily define any arbitrary or custom functions on top of it and using Zygote we can easily differentiate through it. There are a lot of interesting applications of Flux3D.jl along with other interesting packages in Julia like DiffEqFlux, worth exploring.

Some of the things which would be interesting to have in future releases are:-

  • Cache-based Custom dataset wrapper, as 3D data are expensive in terms of space and computation (especially in VoxelGrid).

  • Some more metrics for 3D data like normalconsistency, cloudtosurfacedistance and some more loss.

  • Add support for textures in case of TriMesh which will open a lot more applications.

  • Integration with Differentiable Graphics Frameworks (like RayTracer.jl)

Any suggestions, issues and pull requests are most appreciated. Cheers!

– Nirmal Suthar, Avik Pal, Dhairya Gandhi

\ No newline at end of file diff --git a/previews/PR166/blogposts/2021-12-1-flux-numfocus/index.html b/previews/PR166/blogposts/2021-12-1-flux-numfocus/index.html new file mode 100644 index 00000000..e7791310 --- /dev/null +++ b/previews/PR166/blogposts/2021-12-1-flux-numfocus/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Flux <3 NumFOCUS

We are very excited to announce that FluxML is partnering with NumFOCUS as an affiliated project to further the cause of open and reproducible science and growing the adoption of the FluxML ecosystem. Flux has always had the mission of being a simple, hackable and performant approach to machine learning, which is extended to a number of domains in science by means of differentiable programming.

This milestone is the result of the coming together of the Julia community to support the vision of producing high performance machine learning tools which are flexible towards the needs of novel use cases such as: graph neural networks, scientific machine learning, and differentiable programming. The support of the community as well as the contributions made to that end have helped catapult Flux to this stage, so we want to take this moment to thank the Julia community for their continued support, guidance, and encouragement.

This partnership will help us in growing the community, bringing new contributors into the ecosystem, and help us manage the funds from future grants we raise for a number of upcoming projects - be they compiler related tools for our AD, or support for low precision math on GPUs in a flexible and generic manner.

We hope to announce a lot more exciting news in the times to come and thank you all so much once again for helping us reach this exciting milestone in our journey! There is a lot more that we want to do, and this is definitely only the start.

Cheers

About NumFOCUS: The mission of NumFOCUS is to promote open practices in research, data, and scientific computing by serving as a fiscal sponsor for open source projects and organizing community-driven educational programs. NumFOCUS is a 501(c)(3) public charity in the United States.

– Dhairya Gandhi, Logan Kilpatrick

\ No newline at end of file diff --git a/previews/PR166/blogposts/2023-06-07-metalhead-v0.8/index.html b/previews/PR166/blogposts/2023-06-07-metalhead-v0.8/index.html new file mode 100644 index 00000000..9c246156 --- /dev/null +++ b/previews/PR166/blogposts/2023-06-07-metalhead-v0.8/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

What's new in Metalhead 0.8.0

Metalhead v0.8.0 is one of the largest releases of the library in recent times. Here's a list of all the improvements that have been accumulated in the library over the last few months:

More models

Metalhead v0.8.0 ships with more exported models than any other previous Metalhead release. In particular, support for the following models was added:

In Metalhead v0.7, support was added for pre-trained models for VGG and ResNets. v0.8.0 takes this further by adding support for Wide ResNets (an architecture previously not supported by Metalhead), certain configurations of ResNeXt, and SqueezeNet. This makes it easier for users to get started with transfer learning tasks. We also now export the backbone and classifier functions, which return the feature extractor and classifier head portions of the model respectively. This should make it easier for users to hit the ground running.

Metalhead is always looking for contributors to help with adding pre-trained weights for the models. To know how you can help with this effort, please check out the contributor’s guide in the documentation. We will be happy to help you work through any issues you may encounter!

A Layers module to make it easier to build custom models

Previously, Metalhead v0.7 introduced the Layers module but it was not publicly documented as the internals were still being polished. With Metalhead v0.8.0, it has reached a point of stability. The Layers module exposes functionality that allows users to build custom neural network models very easily. Some notable improvements are:

  1. Stochastic Depth and DropBlock layers were added, and are now fully featured (https://github.com/FluxML/Metalhead.jl/pull/174, https://github.com/FluxML/Metalhead.jl/pull/200). In particular, Stochastic Depth adds support for batch mode. Note that v0.7 used the term DropPath – however, this term was changed to StochasticDepth to remove any ambiguity over what the layer was used for.

  2. The create_classifier function now adds a distinction between no Dropout and Dropout of rate 0; moreover, it also now supports an expanded classifier with an additional Dense layer in between (https://github.com/FluxML/Metalhead.jl/pull/198).

  3. A new pooling layer, AdaptiveMeanMaxPool was added (https://github.com/FluxML/Metalhead.jl/pull/174).

  4. Squeeze-and-excitation layers were added, including an efficient squeeze-and-excite layer for future usage (https://github.com/FluxML/Metalhead.jl/pull/174).

  5. conv_bn has now become conv_norm, with support for changing the normalisation layer (https://github.com/FluxML/Metalhead.jl/pull/174). It also has changed default behaviour, with the bias for the convolution layer being set to false if the normalisation layers is enabled – this reflects the most common usage in most neural network models and so makes the user's job a little easier. There is also a basic_conv_bn layer that derives from the conv_norm layer which replicates the convolution-batch norm combination used in TensorFlow by default. In particular, the momentum value for BatchNorm is set to 3e-3.

  6. Inverted residual bottleneck blocks have been added, most notably mbconv and fused_mbconv, two commonly used variants in models like MobileNets and EfficientNets. (https://github.com/FluxML/Metalhead.jl/pull/198)

While the Layers API has stabilised reasonably, we expect some breaking changes over the next few releases as we iron out some issues and add features. While any breaking changes will be handled with the appropriate deprecations, the Layers API should be treated as experimental.

A more hackable interface

One of the biggest changes to Metalhead has been to its API structure. Prior to v0.8, model functions were classified into one of two categories – functions for users requiring more configuration and functions catering to users requiring less configuration and who preferred a convenient mechanism for loading pre-trained weights. This was a convenient interface but had fallen behind due to recent advancements in research.

v0.8 takes this to the next level by separating out the model interfaces into three distinct interfaces. For the purpose of this article, we’ll call these the “high-level”, “mid-level” and “low-level” interfaces – and there have been improvements to all three of these.

Uniformity at the higher level interface

The “high-level” interface caters to users who want a quick start and usually want to work with pre-trained models, either as feature extractors or to fine tune for transfer learning tasks. The notable improvement here has been that all of these functions now expose three keyword arguments mandatorily – inchannels, nclasses, and pretrain. The other big change is that there are no more default model configurations, doing away with ambiguous notation like ResNet(), which meant ResNet-50 in Metalhead v0.7. This work landed in https://github.com/FluxML/Metalhead.jl/pull/190.

Modern training techniques at the mid level interface

The “mid-level” interface allows users looking for more advanced options to start working with models that offer a little more out of the box, without compromising on user ease. In particular, the ResNet family of models has undergone a huge revamp, with support for many new modifications added in https://github.com/FluxML/Metalhead.jl/pull/174. These modifications include a large number of recent advancements from papers such as Bag of Tricks:

  1. Stochastic Depth and DropBlock are now supported by the underlying resnet function.

  2. The resnet function also now takes an attention-layer argument, which allows us to design SE-ResNets and SE-ResNeXts. The Layers module also exports an efficient_squeeze_excite function for any users who want a computationally efficient attention function.

  3. The stem of the resnet can now be modified to be optionally deeper to match the InceptionResNet-v2 stem. An experimental option from the timm library in Python to make the deeper stem have a larger width in the second convolution is also supported since this shows improvements over the regular deeper stem in certain cases.

  4. Three types of downsampling layers are now supported. In addition to the identity and convolutional projections for skip connection downsampling, a max pooling+convolution based downsampling projection is also supported now.

  5. The model supports a revnorm option, which places the normalisation layers before the convolutional layers.

The documentation for ResNet in Metalhead goes over these options in detail, and there is also a guide on how to use some of these. Head there to check out even more cool features!

Reducing code duplication and making the low-level interface more powerful

The “low-level” interface allows engineers and researchers to iterate on model design quickly without thinking too much about the building blocks. In particular, multiple dispatch means that functions that need to be re-written again and again in Python libraries can simply be unified under one function in Julia.

One of the major changes Metalhead v0.8 introduces is the concept of builders. These are functions that return closures over the stage and block indices. These two numbers together index into a block completely (the stage index represents which stage of the large model is being referred to, and the block index finds the specific block inside the stage). Builders have allowed writing functions that construct blocks purely based on the stage and block indices, abstracting away construction of the layers as well as details like calculations for strides, output feature maps or probabilities for stochastic depth/DropBlock. These builders have been used to rewrite the underlying implementations of the three largest CNN families supported by Metalhead and that are used commonly – ResNets, MobileNets and EfficientNets.

The biggest beneficiary of this has been the MobileNet and EfficientNet model families, which are constructed from a single function using nothing but a uniform configuration dictionary format. Yep, you read that right. That’s six different models expressed using a single underlying function which is just about sixty lines of code. As a user, all you need to do is change the configuration dictionary and watch the magic happen. This means that conceptualising new models has become as simple as visualising the model structure as a dictionary of configurations (in short, just the novelties), and then watching the function take your configurations and produce the model.

There were improvements for the ResNet family of models as well: the stride and feature map calculations through the ResNet block builders are now callbacks, and can thus be easily modified by users if they wish to define custom stride/feature map calculations. To know more about builders and how they work for the different model families, check out the documentation! We are still working on adding documentation for all of the features, so if you find something that's unexplained, open an issue and we will be happy to assist you as well as to improve the documentation!

Model correctness and other bugs

Apart from this, there have also been some corrections in model implementations. In particular,

  1. The Inception family of models now mimics default TensorFlow behaviour, with momentum for the BatchNorm set to 0.003 and bias disabled in the convolution layers. This should help gradient times by a fair bit. (https://github.com/FluxML/Metalhead.jl/pull/198)

  2. The EfficientNet models (b0 through b7) had changes pushed to them that fix their model structure and match the parameter count with PyTorch. They also now have Stochastic Depth with probability 0.2 built in by default as described in the paper. (https://github.com/FluxML/Metalhead.jl/pull/198)

  3. MobileNetv2 and MobileNetv3 use pad=1 in their first convolutional layer now, matching the descriptions of the models in the paper. (https://github.com/FluxML/Metalhead.jl/pull/179)

  4. MobileNetv1 now removes the extra Dense layer in its classifier head, matching the implementation described in the paper. (https://github.com/FluxML/Metalhead.jl/pull/189)

Future plans

We plan to keep improving and iterating on the design of the models in Metalhead throughout the 0.8 series of patch releases. Apart from this, v0.9 should bring with it substantially improved support for vision transformer-based architectures, which have been at the forefront of computer vision research over the last two years. Features like convolution and batch normalisation fusion at inference time are also in the works to make Metalhead keep pace with the advancements in computer vision research over the last few years. One of the major inspirations for this overhaul has been the success of the timm library in Python, which has allowed researchers and engineers to start experimentation very easily with PyTorch. We hope to move towards something similar for Flux.jl in the long term for Metalhead. Thanks for reading this, and don't forget to check out Metalhead!

– Abhirath Anand (@theabhirath)

\ No newline at end of file diff --git a/previews/PR166/css/script_default.css b/previews/PR166/css/script_default.css new file mode 100644 index 00000000..5c97c4fb --- /dev/null +++ b/previews/PR166/css/script_default.css @@ -0,0 +1 @@ +@charset "utf-8"; .hljs{display:block;overflow-x:auto;padding:.5em;background:#F0F0F0}.hljs,.hljs-subst{color:#444}.hljs-comment{color:#888}.hljs-keyword,.hljs-attribute,.hljs-selector-tag,.hljs-meta-keyword,.hljs-doctag,.hljs-name{font-weight:bold}.hljs-type,.hljs-string,.hljs-number,.hljs-selector-id,.hljs-selector-class,.hljs-quote,.hljs-template-tag,.hljs-deletion{color:#800}.hljs-title,.hljs-section{color:#800;font-weight:bold}.hljs-regexp,.hljs-symbol,.hljs-variable,.hljs-template-variable,.hljs-link,.hljs-selector-attr,.hljs-selector-pseudo{color:#BC6060}.hljs-literal{color:#78A960}.hljs-built_in,.hljs-bullet,.hljs-code,.hljs-addition{color:#397300}.hljs-meta{color:#1f7199}.hljs-meta-string{color:#4d99bf}.hljs-emphasis{font-style:italic}.hljs-strong{font-weight:bold} \ No newline at end of file diff --git a/previews/PR166/css/site.css b/previews/PR166/css/site.css new file mode 100644 index 00000000..22af83a5 --- /dev/null +++ b/previews/PR166/css/site.css @@ -0,0 +1 @@ +@charset "utf-8";@import url(https://fonts.googleapis.com/css?family=Lato:400,400i);.octicon{display:inline-block;vertical-align:text-bottom;fill:currentColor}body{background:#143c3c;font-family:Lato,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif;line-height:1.7}.logo{font-style:italic}.navbar .logo{text-shadow:2px 2px 5px rgba(0,0,0,0.1)}.content{background:#f0fafa}.content .container{background:white;padding-top:2em;padding-bottom:2em}.content h1{font-size:20pt;padding-bottom:.2em;border-bottom:3px solid #ebf5eb;text-align:center;font-weight:bold;margin-bottom:1em}.content h2{font-size:18pt;text-align:right;margin-top:2em}.content h3{font-size:14pt;font-weight:bold;margin-top:2em}.content h4{font-size:13pt;margin-top:2em}.content h5{font-size:13pt;font-style:italic;margin-top:2em}.content blockquote{font-style:italic;border-left:5px solid #ebf5eb;padding-left:1em;margin-left:1em}.content .author{text-align:right;font-style:italic;color:#009696}.content .attrib{font-style:italic;color:#003232}.container img{max-width:100%}.container h1,.container h2,.container h3,.container h4,.container h5,.container p,.container blockquote,.container .hljs,.container ul :not(.navbar-nav){max-width:650px;margin-left:auto;margin-right:auto}.container p{text-align:justify}.container p.p-image{max-width:100%;text-align:center}.lighter{font-weight:300;letter-spacing:1px}p a:hover,p a:visited:hover{color:#006464;text-decoration:none}p a,p a:visited{color:#006464;border-bottom:2px solid #b4dcdc}p a:hover{border-bottom:2px solid #0aa}.feature a:hover,.feature a:visited:hover{color:#006464;text-decoration:none}.feature a,.feature a:visited{color:#006464;border-bottom:2px solid #b4dcdc}.feature a:hover{border-bottom:2px solid #0aa}.call{padding-top:2em;padding-bottom:2em;text-align:center}.call p:last-child{margin:0}.footer{margin-top:1.5rem;margin-bottom:3rem;color:white}pre{margin:0}pre code.hljs{background:#f5ffff;border:2px solid #c8f0f0;border-radius:5px;padding-left:1em;padding-right:1em;margin-bottom:1em}.navbar-collapse.collapse.in{display:block !important}.jumbotron{margin-bottom:0;position:relative;border-bottom:1px thick}.jumbotron .container{max-width:750px;box-shadow:2px;position:relative;padding:none;text-align:center}.jumbotron .buttons{padding:10px}@media (min-width:576px){.jumbotron .container{padding:calc(1rem + 30px) 15px}}.jumbotron hr{border-top:1px solid #649696}.jumbotron h1{font-family:lato;font-style:italic}.jumbotron{padding:0}.jumbotron p{font-size:1.1em;margin-bottom:1.5rem}.btn-primary{color:#1e3232;border-color:#96c8c8;background:none;border-width:2px}.jumbotron .btn-primary:hover{color:#000;border-color:#1e5050;background:none;border-width:2px}.features{background:white;padding-top:2em}.feature{padding-top:1em;padding-bottom:2rem;letter-spacing:.1px}.feature-title{text-align:center;color:#648282}.paper{padding:1em}.feature h5,.paper h5{font-style:italic;padding-bottom:.5em}.friends{background:#fff}.friends *{text-align:center;padding:10px}.friends h3{margin-top:50px}.friends ul{display:flex;-webkit-justify-content:space-evenly;justify-content:space-evenly;flex-wrap:wrap;list-style:none;align-items:center}.friends ul li img{max-width:200px;max-height:100px;height:auto}.tight-list p{margin-bottom:0} \ No newline at end of file diff --git a/previews/PR166/getting_started/index.html b/previews/PR166/getting_started/index.html new file mode 100644 index 00000000..ef54208b --- /dev/null +++ b/previews/PR166/getting_started/index.html @@ -0,0 +1 @@ + Flux – Elegant ML
\ No newline at end of file diff --git a/previews/PR166/governance/index.html b/previews/PR166/governance/index.html new file mode 100644 index 00000000..321f813f --- /dev/null +++ b/previews/PR166/governance/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

FluxML Governance

The following contains the formal governance structure of the FluxML project. This document clarifies how decisions are made with respect to community interactions, including the relationship between open source development and work that may be funded by for-profit and non-profit entities.

Code of Conduct

The FluxML community strongly values inclusivity and diversity. Everyone should treat others with the utmost respect. Everyone in the community must adhere to the NumFOCUS Code of Conduct which reflects the values of our community. Violations of the code should be reported to members of the steering council, where the offenses will be handled on a case-by-case basis.

Current Leadership

Current Steering Council

Advisory Committee

Former Steering Council

Governing Rules and Duties

Steering Council

The Project has a Steering Council that consists of Project Contributors who have produced contributions that are substantial in quality and quantity, and sustained over at least one year. The role of the Council is to provide active leadership for the Project in making everyday decisions on technical and administrative issues, through working with and taking input from the Community.

During the everyday project activities, Council Members participate in all discussions, code review and other project activities as peers with all other Contributors and the Community. In these everyday activities, Council Members do not have any special power or privilege through their membership on the Council. However, it is expected that because of the quality and quantity of their contributions and their expert knowledge of the Project Software and Services that Council Members will provide useful guidance, both technical and in terms of project direction, to potentially less experienced Contributors.

The Steering Council and its Members play a special role in certain situations. In particular, the Council may:

  • Make decisions about the overall scope, vision and direction of the project.

  • Make decisions about strategic collaborations with other organizations or individuals.

  • Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests.

  • Make decisions about the Services that are run by the Project and manage those Services for the benefit of the Project and Community.

  • Make decisions when regular community discussion does not produce consensus on an issue in a reasonable time frame.

Steering Council decisions are taken by simple majority, with the exception of changes to the Governance Documents which follow the procedure in the section 'Changing the Governance Documents'.

Steering Council membership

To become eligible for being a Steering Council Member, an individual must be a Project Contributor who has produced contributions that are substantial in quality and quantity, and sustained over at least one year. Potential Council Members are nominated by existing Council Members or by the Community and voted upon by the existing Council after asking if the potential Member is interested and willing to serve in that capacity.

When considering potential Members, the Council will look at candidates with a comprehensive view of their contributions. This will include but is not limited to code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, design work, etc. We deliberately do not set arbitrary quantitative metrics to avoid encouraging behavior that plays to the metrics rather than the project's overall well-being. We want to encourage a diverse array of backgrounds, viewpoints and talents in our team, which is why we explicitly do not define code as the sole metric on which Council membership will be evaluated.

If a Council Member becomes inactive in the project for a period of one year, they will be considered for removal from the Council. Before removal, the inactive Member will be approached by another Council member to ask if they plan on returning to active participation. If not they will be removed immediately upon a Council vote. If they plan on returning to active participation soon, they will be given a grace period of one year. If they do not return to active participation within that time period they will be removed by vote of the Council without further grace period. All former Council members can be considered for membership again at any time in the future, like any other Project Contributor. Retired Council members will be listed on the project website, acknowledging the period during which they were active in the Council.

The Council reserves the right to eject current Members if they are deemed to be actively harmful to the Project's well-being, and attempts at communication and conflict resolution have failed.

Fiscal Decisions

All fiscal decisions are made by the steering council to ensure any funds are spent in a manner that furthers the mission of the Project. Fiscal decisions require majority approval by acting steering council members.

Advisory Committee

The Project has an Advisory Committee that works to ensure the long-term well-being of the Project. The Committee advises the Steering Council and may be called upon to break deadlocks or serious disagreements in the Council. The Community can ask the Committee to review actions taken by the Council, and the Committee will meet annually to review Project activities. Committee decisions are taken in consensus. Members of the Advisory Committee are appointed by the Steering Council.

Conflict of interest

It is expected that Steering Council and Advisory Committee Members will be employed at a wide range of companies, universities and non-profit organizations. Because of this, it is possible that Members will have conflicts of interest. Such conflicts of interest include, but are not limited to:

  • Financial interests, such as investments, employment or contracting work, outside of the Project that may influence their work on the Project.

  • Access to proprietary information of their employer that could potentially leak into their work with the Project.

All members of the Council and Committee shall disclose any conflict of interest they may have. Members with a conflict of interest in a particular issue may participate in Council discussions on that issue, but must recuse themselves from voting on the issue. When a member fails to disclose a conflict of interest, any Contributor can raise this concern to the Council. The Council will discuss the issue and vote on whether the accused member should be removed. The member will have the opportunity to speak for their actions, but they will not participate in Council discussion or voting.

\ No newline at end of file diff --git a/previews/PR166/gsoc/index.html b/previews/PR166/gsoc/index.html new file mode 100644 index 00000000..32bcff5a --- /dev/null +++ b/previews/PR166/gsoc/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

FluxML Projects - Summer of Code

Flux usually takes part in Google Summer of Code as a NumFocus organization. We follow the same rules and application guidelines as Julia, so please check there for more information on applying. Below are a set of ideas for potential projects (though you are welcome to explore anything you are interested in). Please note the year by the ideas list below. Project ideas from a previous year will not always carry over to a new year.

Flux projects are typically very competitive; we encourage you to get started early, as successful contributors typically have early PRs or working prototypes as part of the application. It is a good idea to simply start contributing via issue discussion and PRs and let a project grow from there; you can take a look at this list of issues for some starter contributions. Please see the contributing guide for help first.

FluxML GSoC 2024 Ideas List

Writing Julia-native kernels for common NN operations

Implement optimized kernels for common neural network operations for which we don't already have Julia-native implementations. This project will require experience with GPU kernel writing and performance optimizations.

Difficulty. Hard. Duration. 350 hours

Description

Many ML frameworks are making the move away from vendor-specific libraries (like CUBLAS, CUDNN, etc.) towards more generic, JIT-compiled implementations of ML-related kernels, like BLAS, softmax, ReLU, etc. The reasons for this move are many-fold:

  • Vendor-provided libraries often only work on that vendor's hardware and software

  • These libraries only support certain element types, tensor shapes/sizes, and limited array view/stride/transpose support

  • These libraries often expect to be executed from the host, without a device-side launchable equivalent

  • These libraries have unreliable build systems or are binary blobs

Improving this state of affairs for Flux will involve using Julia's existing GPU and compute kernel libraries (e.g KernelAbstractions.jl) to implement various accelerated, cross-vendor routines. These kernels should be both composable and performance competitive with Flux's current generic code paths. Examples of routines specifically useful for implementing Neural Networks include:

  • GEMM and GEMV

  • Softmax

  • Batchnorm and Layernorm

  • ReLU

  • Convolution/correlation

The ideal candidate should have experience with what operations are used in popular ML models and how they are commonly implemented on GPU. This includes experience writing and benchmarking high performance GPU kernels. Because kernels will be required for both training and inference, an understanding of automatic differentiation (AD) is also highly recommended.

Mentors. Julian Samaroo, Kyle Daruwalla, Brian Chen

Prerequisites

  • Julia language fluency is essential.

  • Experience with low-level GPU kernel programming is strongly recommended.

  • Experience with common primitive machine learning ops (forwards and backwards passes) and their interaction is recommended.

  • Familiarity with existing prior art such as tiny-cuda-nn is preferred.

Your contributions

  • A new package containing the optimized kernels and any supporting code for integration into Flux/Flux's operation library NNlib.jl.

  • Tests on CI and a simple benchmark harness for the new NN kernel library.

  • A proof-of-concept example showing the kernels being used with kernel fusion on device (GPU).

Creating runnable training and testing workflows for computer vision models

Write a suite of scripts that demonstrate how to use Metalhead.jl models for a variety of computer vision tasks and allow for ongoing verification of model correctness.

Difficulty. Moderate. Duration. 350 hours

Description

Metalhead.jl is Flux's computer vision library and contains a wide range of models along with pre-trained weights. However, it currently lacks a set of examples showcasing how to use the library in complete computer vision workflows. This includes aspects such as integrating data augmentation, manipulating hyperparameters, tracking metrics and evaluating trained models. Simultaneously, Metalhead does not have a comprehensive set of end-to-end tests to ensure all models can be trained to convergence and to catch less obvious performance or correctness regressions. This project will help fill both needs by creating a set of self-contained, runnable scripts which exercise the functionality of Metalhead models across a number of tasks. The choice of models and tasks may vary, but the top priority will be commonly-used ones such as ResNet and image classification.

The ideal candidate should have practical experience with training deep learning models for computer vision tasks, as well as sufficient familiarity with Julia to work independently with complex libraries (e.g. Flux) on a medium-sized codebase. Direct experience using Metalhead.jl is not required but highly recommended.

Mentors. Brian Chen, Kyle Daruwalla

Prerequisites

  • Julia language fluency is essential.

  • Github CI and experience with GH Actions is strongly suggested.

  • Experience with more than one ML task (e.g. image classification, autoregressive language modeling, etc.).

  • Familiarity with prior art is preferred:

Your contributions

  • A new FluxML package, FluxBenchmarks.jl, that will perform configurable benchmarking across our ML stack.

  • Github Actions integration for FluxBenchmarks.jl to invoke the tool from PRs.

  • A benchmarking suite that will build your experience with different types of ML models and operations across the stack.

\ No newline at end of file diff --git a/previews/PR166/gsod/index.html b/previews/PR166/gsod/index.html new file mode 100644 index 00000000..45b14cb5 --- /dev/null +++ b/previews/PR166/gsod/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

FluxML Projects - Season of Docs

The Flux project is a participant in Google Season of Docs. In 2020, we had a technical writer work on our website. The project was a success and we have since then build out various projects specifically for interested technical writers.

Flux.jl is an elegant approach to machine learning in Julia. It is designed to be hackable and flexible, extendable, and exposes powerful AD tools. It also provides abstractions over the popular layers and optimizers used in neural networks. It is built with differentiable programming in mind. The mentors for this project are Dhairya Gandhi.

Tutorials

Flux is in dire need of complete tutorials in the model-zoo as well as on the website. We can take inspiration from many existing projects that publish their tutorials, that take a look at common design patterns. This includes writing custom adjoints, new optimizers, transfer learning, and writing performance-sensitive code for many common kinds of networks that many people would be interested in writing. This could also include cases that help users write custom loss functions, and even putting Flux models behind a web server.

Updated Documentation and DocTests

Flux documentation needs a lot of rework since our generic approach to development means there are many general use cases that we support but might be a bit subtle to discover. So in that case, we need to highlight such common cases and make them known in the documentation. We would like to use doc tests to also increase our coverage of and documentation of many of the common patterns we see in differentiating Julia code.

Potential Impact

Flux is an innovative approach to machine learning. This also means that not all the same patterns and assumptions truly hold when translating from a different framework. It also needs a way to communicate a compelling description of how to implement many of the user-facing niceties that one might need in the course of completing an ML project. Through this, we want to also find areas of improvement where we could offer a better user experience.

This would also greatly benefit the adoption of Flux in the larger ML ecosystem, which we feel is currently held back due to not having enough of these simple patterns documented in an approachable form. We want to see an increase in the number of contributors to the various packages too since that would help us improve our stack better. Flux also utilizes simple to understand and performant code, made possible by Julia, and through this, we also want to bring awareness to how our ecosystem has matured, and increase its adoption in research and industry.

\ No newline at end of file diff --git a/previews/PR166/icon.png b/previews/PR166/icon.png new file mode 100644 index 00000000..07b713d6 Binary files /dev/null and b/previews/PR166/icon.png differ diff --git a/previews/PR166/index.html b/previews/PR166/index.html new file mode 100644 index 00000000..e40f4e90 --- /dev/null +++ b/previews/PR166/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

The Elegant Machine Learning Stack

Flux is a 100% pure-Julia stack and provides lightweight abstractions on top of Julia's native GPU and AD support. It makes the easy things easy while remaining fully hackable.

Features

Flux has features that sets it apart among ML systems.
Compiled Eager Code
Flux provides a single, intuitive way to define models, just like mathematical notation. Julia transparently compiles your code, optimising and fusing kernels for the GPU, for the best performance.
Differentiable Programming
Existing Julia libraries are differentiable and can be incorporated directly into Flux models. Cutting edge models such as Neural ODEs are first class, and Zygote enables overhead-free gradients.
First-class GPU support
GPU kernels can be written directly in Julia via CUDA.jl. Flux is uniquely hackable and any part can be tweaked, from GPU code to custom gradients and layers.

Ecosystem

Flux has a diverse ecosystem that includes models available for reuse and other useful packages.
Probabilistic Programming
The Turing.jl and Stheno.jl libraries enable probabilistic programming, Bayesian inference and Gaussian processes on top of Flux.
Graph Neural Networks
GraphNeuralNetworks.jl is a graph neural network library for Flux and supports CUDA GPU acceleration.
Computer Vision
Metalhead.jl includes many state-of-the-art computer vision models with pre-trained weights.
SciML
The SciML ecosystem uses the FluxML stack to mix neural nets with differential equations, to get the best of black box and mechanistic modelling.
Natural Language Processing
Transformers.jl provides components for transformer architectures for language modeling, as well as providing several trained models out of the box.

Community

Get in touch with the Flux community.
Community team
Flux is maintained by community team (see our governance model). Join us or talk to us on Zulip! 👉
Slack
Official Julia Slack for casual conversation. See #flux-bridged and #machine-learning.
Zulip
Zulip server for the Julia programming language community. See #ml-contributors and #machine-learning.
Discourse forum
Machine Learning in Julia community.
Stack Overflow
Ask questions about Flux.jl.
Contribute!
Help us by contributing code!

Why Flux?

Researchers, users, and developers of Flux

\ No newline at end of file diff --git a/previews/PR166/libs/highlight.pack.js b/previews/PR166/libs/highlight.pack.js new file mode 100644 index 00000000..f9d410c2 --- /dev/null +++ b/previews/PR166/libs/highlight.pack.js @@ -0,0 +1,2 @@ +/*! highlight.js v9.12.0 | BSD3 License | git.io/hljslicense */ +!function(e){var n="object"==typeof window&&window||"object"==typeof self&&self;"undefined"!=typeof exports?e(exports):n&&(n.hljs=e({}),"function"==typeof define&&define.amd&&define([],function(){return n.hljs}))}(function(e){function n(e){return e.replace(/&/g,"&").replace(//g,">")}function t(e){return e.nodeName.toLowerCase()}function r(e,n){var t=e&&e.exec(n);return t&&0===t.index}function a(e){return k.test(e)}function i(e){var n,t,r,i,o=e.className+" ";if(o+=e.parentNode?e.parentNode.className:"",t=B.exec(o))return w(t[1])?t[1]:"no-highlight";for(o=o.split(/\s+/),n=0,r=o.length;r>n;n++)if(i=o[n],a(i)||w(i))return i}function o(e){var n,t={},r=Array.prototype.slice.call(arguments,1);for(n in e)t[n]=e[n];return r.forEach(function(e){for(n in e)t[n]=e[n]}),t}function u(e){var n=[];return function r(e,a){for(var i=e.firstChild;i;i=i.nextSibling)3===i.nodeType?a+=i.nodeValue.length:1===i.nodeType&&(n.push({event:"start",offset:a,node:i}),a=r(i,a),t(i).match(/br|hr|img|input/)||n.push({event:"stop",offset:a,node:i}));return a}(e,0),n}function c(e,r,a){function i(){return e.length&&r.length?e[0].offset!==r[0].offset?e[0].offset"}function u(e){s+=""}function c(e){("start"===e.event?o:u)(e.node)}for(var l=0,s="",f=[];e.length||r.length;){var g=i();if(s+=n(a.substring(l,g[0].offset)),l=g[0].offset,g===e){f.reverse().forEach(u);do c(g.splice(0,1)[0]),g=i();while(g===e&&g.length&&g[0].offset===l);f.reverse().forEach(o)}else"start"===g[0].event?f.push(g[0].node):f.pop(),c(g.splice(0,1)[0])}return s+n(a.substr(l))}function l(e){return e.v&&!e.cached_variants&&(e.cached_variants=e.v.map(function(n){return o(e,{v:null},n)})),e.cached_variants||e.eW&&[o(e)]||[e]}function s(e){function n(e){return e&&e.source||e}function t(t,r){return new RegExp(n(t),"m"+(e.cI?"i":"")+(r?"g":""))}function r(a,i){if(!a.compiled){if(a.compiled=!0,a.k=a.k||a.bK,a.k){var o={},u=function(n,t){e.cI&&(t=t.toLowerCase()),t.split(" ").forEach(function(e){var t=e.split("|");o[t[0]]=[n,t[1]?Number(t[1]):1]})};"string"==typeof a.k?u("keyword",a.k):x(a.k).forEach(function(e){u(e,a.k[e])}),a.k=o}a.lR=t(a.l||/\w+/,!0),i&&(a.bK&&(a.b="\\b("+a.bK.split(" ").join("|")+")\\b"),a.b||(a.b=/\B|\b/),a.bR=t(a.b),a.e||a.eW||(a.e=/\B|\b/),a.e&&(a.eR=t(a.e)),a.tE=n(a.e)||"",a.eW&&i.tE&&(a.tE+=(a.e?"|":"")+i.tE)),a.i&&(a.iR=t(a.i)),null==a.r&&(a.r=1),a.c||(a.c=[]),a.c=Array.prototype.concat.apply([],a.c.map(function(e){return l("self"===e?a:e)})),a.c.forEach(function(e){r(e,a)}),a.starts&&r(a.starts,i);var c=a.c.map(function(e){return e.bK?"\\.?("+e.b+")\\.?":e.b}).concat([a.tE,a.i]).map(n).filter(Boolean);a.t=c.length?t(c.join("|"),!0):{exec:function(){return null}}}}r(e)}function f(e,t,a,i){function o(e,n){var t,a;for(t=0,a=n.c.length;a>t;t++)if(r(n.c[t].bR,e))return n.c[t]}function u(e,n){if(r(e.eR,n)){for(;e.endsParent&&e.parent;)e=e.parent;return e}return e.eW?u(e.parent,n):void 0}function c(e,n){return!a&&r(n.iR,e)}function l(e,n){var t=N.cI?n[0].toLowerCase():n[0];return e.k.hasOwnProperty(t)&&e.k[t]}function p(e,n,t,r){var a=r?"":I.classPrefix,i='',i+n+o}function h(){var e,t,r,a;if(!E.k)return n(k);for(a="",t=0,E.lR.lastIndex=0,r=E.lR.exec(k);r;)a+=n(k.substring(t,r.index)),e=l(E,r),e?(B+=e[1],a+=p(e[0],n(r[0]))):a+=n(r[0]),t=E.lR.lastIndex,r=E.lR.exec(k);return a+n(k.substr(t))}function d(){var e="string"==typeof E.sL;if(e&&!y[E.sL])return n(k);var t=e?f(E.sL,k,!0,x[E.sL]):g(k,E.sL.length?E.sL:void 0);return E.r>0&&(B+=t.r),e&&(x[E.sL]=t.top),p(t.language,t.value,!1,!0)}function b(){L+=null!=E.sL?d():h(),k=""}function v(e){L+=e.cN?p(e.cN,"",!0):"",E=Object.create(e,{parent:{value:E}})}function m(e,n){if(k+=e,null==n)return b(),0;var t=o(n,E);if(t)return t.skip?k+=n:(t.eB&&(k+=n),b(),t.rB||t.eB||(k=n)),v(t,n),t.rB?0:n.length;var r=u(E,n);if(r){var a=E;a.skip?k+=n:(a.rE||a.eE||(k+=n),b(),a.eE&&(k=n));do E.cN&&(L+=C),E.skip||(B+=E.r),E=E.parent;while(E!==r.parent);return r.starts&&v(r.starts,""),a.rE?0:n.length}if(c(n,E))throw new Error('Illegal lexeme "'+n+'" for mode "'+(E.cN||"")+'"');return k+=n,n.length||1}var N=w(e);if(!N)throw new Error('Unknown language: "'+e+'"');s(N);var R,E=i||N,x={},L="";for(R=E;R!==N;R=R.parent)R.cN&&(L=p(R.cN,"",!0)+L);var k="",B=0;try{for(var M,j,O=0;;){if(E.t.lastIndex=O,M=E.t.exec(t),!M)break;j=m(t.substring(O,M.index),M[0]),O=M.index+j}for(m(t.substr(O)),R=E;R.parent;R=R.parent)R.cN&&(L+=C);return{r:B,value:L,language:e,top:E}}catch(T){if(T.message&&-1!==T.message.indexOf("Illegal"))return{r:0,value:n(t)};throw T}}function g(e,t){t=t||I.languages||x(y);var r={r:0,value:n(e)},a=r;return t.filter(w).forEach(function(n){var t=f(n,e,!1);t.language=n,t.r>a.r&&(a=t),t.r>r.r&&(a=r,r=t)}),a.language&&(r.second_best=a),r}function p(e){return I.tabReplace||I.useBR?e.replace(M,function(e,n){return I.useBR&&"\n"===e?"
":I.tabReplace?n.replace(/\t/g,I.tabReplace):""}):e}function h(e,n,t){var r=n?L[n]:t,a=[e.trim()];return e.match(/\bhljs\b/)||a.push("hljs"),-1===e.indexOf(r)&&a.push(r),a.join(" ").trim()}function d(e){var n,t,r,o,l,s=i(e);a(s)||(I.useBR?(n=document.createElementNS("http://www.w3.org/1999/xhtml","div"),n.innerHTML=e.innerHTML.replace(/\n/g,"").replace(//g,"\n")):n=e,l=n.textContent,r=s?f(s,l,!0):g(l),t=u(n),t.length&&(o=document.createElementNS("http://www.w3.org/1999/xhtml","div"),o.innerHTML=r.value,r.value=c(t,u(o),l)),r.value=p(r.value),e.innerHTML=r.value,e.className=h(e.className,s,r.language),e.result={language:r.language,re:r.r},r.second_best&&(e.second_best={language:r.second_best.language,re:r.second_best.r}))}function b(e){I=o(I,e)}function v(){if(!v.called){v.called=!0;var e=document.querySelectorAll("pre code");E.forEach.call(e,d)}}function m(){addEventListener("DOMContentLoaded",v,!1),addEventListener("load",v,!1)}function N(n,t){var r=y[n]=t(e);r.aliases&&r.aliases.forEach(function(e){L[e]=n})}function R(){return x(y)}function w(e){return e=(e||"").toLowerCase(),y[e]||y[L[e]]}var E=[],x=Object.keys,y={},L={},k=/^(no-?highlight|plain|text)$/i,B=/\blang(?:uage)?-([\w-]+)\b/i,M=/((^(<[^>]+>|\t|)+|(?:\n)))/gm,C="
",I={classPrefix:"hljs-",tabReplace:null,useBR:!1,languages:void 0};return e.highlight=f,e.highlightAuto=g,e.fixMarkup=p,e.highlightBlock=d,e.configure=b,e.initHighlighting=v,e.initHighlightingOnLoad=m,e.registerLanguage=N,e.listLanguages=R,e.getLanguage=w,e.inherit=o,e.IR="[a-zA-Z]\\w*",e.UIR="[a-zA-Z_]\\w*",e.NR="\\b\\d+(\\.\\d+)?",e.CNR="(-?)(\\b0[xX][a-fA-F0-9]+|(\\b\\d+(\\.\\d*)?|\\.\\d+)([eE][-+]?\\d+)?)",e.BNR="\\b(0b[01]+)",e.RSR="!|!=|!==|%|%=|&|&&|&=|\\*|\\*=|\\+|\\+=|,|-|-=|/=|/|:|;|<<|<<=|<=|<|===|==|=|>>>=|>>=|>=|>>>|>>|>|\\?|\\[|\\{|\\(|\\^|\\^=|\\||\\|=|\\|\\||~",e.BE={b:"\\\\[\\s\\S]",r:0},e.ASM={cN:"string",b:"'",e:"'",i:"\\n",c:[e.BE]},e.QSM={cN:"string",b:'"',e:'"',i:"\\n",c:[e.BE]},e.PWM={b:/\b(a|an|the|are|I'm|isn't|don't|doesn't|won't|but|just|should|pretty|simply|enough|gonna|going|wtf|so|such|will|you|your|they|like|more)\b/},e.C=function(n,t,r){var a=e.inherit({cN:"comment",b:n,e:t,c:[]},r||{});return a.c.push(e.PWM),a.c.push({cN:"doctag",b:"(?:TODO|FIXME|NOTE|BUG|XXX):",r:0}),a},e.CLCM=e.C("//","$"),e.CBCM=e.C("/\\*","\\*/"),e.HCM=e.C("#","$"),e.NM={cN:"number",b:e.NR,r:0},e.CNM={cN:"number",b:e.CNR,r:0},e.BNM={cN:"number",b:e.BNR,r:0},e.CSSNM={cN:"number",b:e.NR+"(%|em|ex|ch|rem|vw|vh|vmin|vmax|cm|mm|in|pt|pc|px|deg|grad|rad|turn|s|ms|Hz|kHz|dpi|dpcm|dppx)?",r:0},e.RM={cN:"regexp",b:/\//,e:/\/[gimuy]*/,i:/\n/,c:[e.BE,{b:/\[/,e:/\]/,r:0,c:[e.BE]}]},e.TM={cN:"title",b:e.IR,r:0},e.UTM={cN:"title",b:e.UIR,r:0},e.METHOD_GUARD={b:"\\.\\s*"+e.UIR,r:0},e});hljs.registerLanguage("julia",function(e){var r={keyword:"in isa where baremodule begin break catch ccall const continue do else elseif end export false finally for function global if import importall let local macro module quote return true try using while type immutable abstract bitstype typealias ",literal:"true false ARGS C_NULL DevNull ENDIAN_BOM ENV I Inf Inf16 Inf32 Inf64 InsertionSort JULIA_HOME LOAD_PATH MergeSort NaN NaN16 NaN32 NaN64 PROGRAM_FILE QuickSort RoundDown RoundFromZero RoundNearest RoundNearestTiesAway RoundNearestTiesUp RoundToZero RoundUp STDERR STDIN STDOUT VERSION catalan e|0 eu|0 eulergamma golden im nothing pi γ π φ ",built_in:"ANY AbstractArray AbstractChannel AbstractFloat AbstractMatrix AbstractRNG AbstractSerializer AbstractSet AbstractSparseArray AbstractSparseMatrix AbstractSparseVector AbstractString AbstractUnitRange AbstractVecOrMat AbstractVector Any ArgumentError Array AssertionError Associative Base64DecodePipe Base64EncodePipe Bidiagonal BigFloat BigInt BitArray BitMatrix BitVector Bool BoundsError BufferStream CachingPool CapturedException CartesianIndex CartesianRange Cchar Cdouble Cfloat Channel Char Cint Cintmax_t Clong Clonglong ClusterManager Cmd CodeInfo Colon Complex Complex128 Complex32 Complex64 CompositeException Condition ConjArray ConjMatrix ConjVector Cptrdiff_t Cshort Csize_t Cssize_t Cstring Cuchar Cuint Cuintmax_t Culong Culonglong Cushort Cwchar_t Cwstring DataType Date DateFormat DateTime DenseArray DenseMatrix DenseVecOrMat DenseVector Diagonal Dict DimensionMismatch Dims DirectIndexString Display DivideError DomainError EOFError EachLine Enum Enumerate ErrorException Exception ExponentialBackOff Expr Factorization FileMonitor Float16 Float32 Float64 Function Future GlobalRef GotoNode HTML Hermitian IO IOBuffer IOContext IOStream IPAddr IPv4 IPv6 IndexCartesian IndexLinear IndexStyle InexactError InitError Int Int128 Int16 Int32 Int64 Int8 IntSet Integer InterruptException InvalidStateException Irrational KeyError LabelNode LinSpace LineNumberNode LoadError LowerTriangular MIME Matrix MersenneTwister Method MethodError MethodTable Module NTuple NewvarNode NullException Nullable Number ObjectIdDict OrdinalRange OutOfMemoryError OverflowError Pair ParseError PartialQuickSort PermutedDimsArray Pipe PollingFileWatcher ProcessExitedException Ptr QuoteNode RandomDevice Range RangeIndex Rational RawFD ReadOnlyMemoryError Real ReentrantLock Ref Regex RegexMatch RemoteChannel RemoteException RevString RoundingMode RowVector SSAValue SegmentationFault SerializationState Set SharedArray SharedMatrix SharedVector Signed SimpleVector Slot SlotNumber SparseMatrixCSC SparseVector StackFrame StackOverflowError StackTrace StepRange StepRangeLen StridedArray StridedMatrix StridedVecOrMat StridedVector String SubArray SubString SymTridiagonal Symbol Symmetric SystemError TCPSocket Task Text TextDisplay Timer Tridiagonal Tuple Type TypeError TypeMapEntry TypeMapLevel TypeName TypeVar TypedSlot UDPSocket UInt UInt128 UInt16 UInt32 UInt64 UInt8 UndefRefError UndefVarError UnicodeError UniformScaling Union UnionAll UnitRange Unsigned UpperTriangular Val Vararg VecElement VecOrMat Vector VersionNumber Void WeakKeyDict WeakRef WorkerConfig WorkerPool "},t="[A-Za-z_\\u00A1-\\uFFFF][A-Za-z_0-9\\u00A1-\\uFFFF]*",a={l:t,k:r,i:/<\//},n={cN:"number",b:/(\b0x[\d_]*(\.[\d_]*)?|0x\.\d[\d_]*)p[-+]?\d+|\b0[box][a-fA-F0-9][a-fA-F0-9_]*|(\b\d[\d_]*(\.[\d_]*)?|\.\d[\d_]*)([eEfF][-+]?\d+)?/,r:0},o={cN:"string",b:/'(.|\\[xXuU][a-zA-Z0-9]+)'/},i={cN:"subst",b:/\$\(/,e:/\)/,k:r},l={cN:"variable",b:"\\$"+t},c={cN:"string",c:[e.BE,i,l],v:[{b:/\w*"""/,e:/"""\w*/,r:10},{b:/\w*"/,e:/"\w*/}]},s={cN:"string",c:[e.BE,i,l],b:"`",e:"`"},d={cN:"meta",b:"@"+t},u={cN:"comment",v:[{b:"#=",e:"=#",r:10},{b:"#",e:"$"}]};return a.c=[n,o,c,s,d,u,e.HCM,{cN:"keyword",b:"\\b(((abstract|primitive)\\s+)type|(mutable\\s+)?struct)\\b"},{b:/<:/}],i.c=a.c,a}); diff --git a/previews/PR166/logo.png b/previews/PR166/logo.png new file mode 100644 index 00000000..c54befa0 Binary files /dev/null and b/previews/PR166/logo.png differ diff --git a/previews/PR166/models/index.html b/previews/PR166/models/index.html new file mode 100644 index 00000000..232b35ab --- /dev/null +++ b/previews/PR166/models/index.html @@ -0,0 +1 @@ + Flux – Elegant ML


layout: blog title: Ecosystem –-

This page lists models available for reuse in Flux, as well other useful projects in the ecosystem. To add your project please send a PR.

Modelling packages

There are a number of packages in the Flux ecosystem designed to help with creating different kinds of models.

  • Transformers.jl provides components for Transformer models for NLP, as well as providing several trained models out of the box.

  • DiffEqFlux provides tools for creating Neural Differential Equations.

  • GeometricFlux makes it easy to build fast neural networks over graphs.

  • Flux3D.jl shows off machine learning on 3D data.

  • AdversarialPrediction.jl provides a way to easily optimize generic performance metrics in supervised learning settings using the Adversarial Prediction framework.

  • Metalhead.jl includes many state-of-the-art computer vision models which can easily be used for transfer learning.

  • Augmentor.jl is a real-time library augmentation library for increasing the number of training images.

  • MLDataUtils.jl is a utility package for generating, loading, partitioning, and processing Machine Learning datasets.

  • UNet.jl is a generic UNet implentation.

  • FluxArchitectures is a collection of slightly more advanced network achitectures.

Projects using Flux

Other projects use Flux under the hood to provide machine learning capabilities, or to combine Machine Learning with another domain.

  • The Yao project uses Flux and Zygote for Quantum Differentiable Programming.

  • The SciML ecosystem uses Flux and Zygote to mix neural nets with differential equations, to get the best of black box and mechanistic modelling.

  • ObjectDetector.jl provides ready-to-go image analysis via YOLO.

  • TextAnalysis.jl provides several NLP algorithms that use Flux models under the hood.

  • RayTracer.jl combines ML with computer vision via a differentiable renderer.

  • Turing.jl extends Flux's differentiable programming capabilities to probabilistic programming.

  • Stheno provides flexible Gaussian processes.

  • Omega is a research project aimed at causal, higher-order probabilistic programming.

  • Mill helps to prototype flexible multi-instance learning models.

  • Torch.jl exposes torch in Julia.

See also academic work citing Flux or Zygote.

\ No newline at end of file diff --git a/previews/PR166/package-lock.json b/previews/PR166/package-lock.json new file mode 100644 index 00000000..f032591f --- /dev/null +++ b/previews/PR166/package-lock.json @@ -0,0 +1,20 @@ +{ + "name": "fluxml.github.io", + "lockfileVersion": 3, + "requires": true, + "packages": { + "": { + "dependencies": { + "highlight.js": "^11.9.0" + } + }, + "node_modules/highlight.js": { + "version": "11.9.0", + "resolved": "https://registry.npmjs.org/highlight.js/-/highlight.js-11.9.0.tgz", + "integrity": "sha512-fJ7cW7fQGCYAkgv4CPfwFHrfd/cLS4Hau96JuJ+ZTOWhjnhoeN1ub1tFmALm/+lW5z4WCAuAV9bm05AP0mS6Gw==", + "engines": { + "node": ">=12.0.0" + } + } + } +} diff --git a/previews/PR166/package.json b/previews/PR166/package.json new file mode 100644 index 00000000..c849f52b --- /dev/null +++ b/previews/PR166/package.json @@ -0,0 +1,5 @@ +{ + "dependencies": { + "highlight.js": "^11.9.0" + } +} diff --git a/previews/PR166/robots.txt b/previews/PR166/robots.txt new file mode 100644 index 00000000..7ef4f4f1 --- /dev/null +++ b/previews/PR166/robots.txt @@ -0,0 +1,4 @@ +Sitemap: fluxml.ai/sitemap.xml + +User-agent: * +Disallow: diff --git a/previews/PR166/sitemap.xml b/previews/PR166/sitemap.xml new file mode 100644 index 00000000..898d4d2c --- /dev/null +++ b/previews/PR166/sitemap.xml @@ -0,0 +1,160 @@ + + + + + fluxml.ai/blogposts/2017-12-06-ml-pl/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2019-09-11-simulating-the-motion-of-charges/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/governance/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2019-05-30-JSoC-Cohort/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/getting_started/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/gsod/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2020-06-29-acclerating-flux-torch/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2021-10-14-vanilla-gan/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/gsoc/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorials/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2020-09-15-deep-learning-flux/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2020-10-18-transfer-learning/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blog/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/models/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2018-12-03-ml-language-compiler/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2017-08-24-generic-gpu/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2019-02-07-what-is-differentiable-programming/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2021-01-26-mlp/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2021-12-1-flux-numfocus/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2021-02-07-convnet/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2023-06-07-metalhead-v0.8/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2019-03-05-dp-vs-rl/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2021-01-21-data-loader/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/blogposts/2020-12-20-Flux3D/index.html + 2024-01-31 + monthly + 0.5 + + + fluxml.ai/tutorialposts/2021-10-08-dcgan-mnist/index.html + 2024-01-31 + monthly + 0.5 + + diff --git a/previews/PR166/tutorialposts/2020-09-15-deep-learning-flux/index.html b/previews/PR166/tutorialposts/2020-09-15-deep-learning-flux/index.html new file mode 100644 index 00000000..bffb1540 --- /dev/null +++ b/previews/PR166/tutorialposts/2020-09-15-deep-learning-flux/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Deep Learning with Flux - A 60 Minute Blitz

– Saswat Das, Mike Innes, Andrew Dinhobl, Ygor Canalli, Sudhanshu Agrawal, João Felipe Santos

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2020-10-18-transfer-learning/index.html b/previews/PR166/tutorialposts/2020-10-18-transfer-learning/index.html new file mode 100644 index 00000000..842c1d2a --- /dev/null +++ b/previews/PR166/tutorialposts/2020-10-18-transfer-learning/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Transfer Learning with Flux

– Dhairya Gandhi

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2021-01-21-data-loader/index.html b/previews/PR166/tutorialposts/2021-01-21-data-loader/index.html new file mode 100644 index 00000000..2cde9ce5 --- /dev/null +++ b/previews/PR166/tutorialposts/2021-01-21-data-loader/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Using Flux DataLoader

– Liliana Badillo, Dhairya Gandhi

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2021-01-26-mlp/index.html b/previews/PR166/tutorialposts/2021-01-26-mlp/index.html new file mode 100644 index 00000000..c6afdcab --- /dev/null +++ b/previews/PR166/tutorialposts/2021-01-26-mlp/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Simple multi-layer perceptron

– Adarsh Kumar, Mike J Innes, Andrew Dinhobl, Jerry Ling, natema, Zhang Shitian, Liliana Badillo, Dhairya Gandhi

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2021-02-07-convnet/index.html b/previews/PR166/tutorialposts/2021-02-07-convnet/index.html new file mode 100644 index 00000000..23672113 --- /dev/null +++ b/previews/PR166/tutorialposts/2021-02-07-convnet/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Simple ConvNet

– Elliot Saba, Adarsh Kumar, Mike J Innes, Dhairya Gandhi, Sudhanshu Agrawal, Sambit Kumar Dash, fps.io, Carlo Lucibello, Andrew Dinhobl, Liliana Badillo

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2021-10-08-dcgan-mnist/index.html b/previews/PR166/tutorialposts/2021-10-08-dcgan-mnist/index.html new file mode 100644 index 00000000..3ea19043 --- /dev/null +++ b/previews/PR166/tutorialposts/2021-10-08-dcgan-mnist/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Deep Convolutional Generative Adversarial Network (DCGAN)

– Deeptendu Santra

\ No newline at end of file diff --git a/previews/PR166/tutorialposts/2021-10-14-vanilla-gan/index.html b/previews/PR166/tutorialposts/2021-10-14-vanilla-gan/index.html new file mode 100644 index 00000000..e6afa5cc --- /dev/null +++ b/previews/PR166/tutorialposts/2021-10-14-vanilla-gan/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

Generative Adversarial Networks

– Ralph Kube

\ No newline at end of file diff --git a/previews/PR166/tutorials/index.html b/previews/PR166/tutorials/index.html new file mode 100644 index 00000000..5941f5a0 --- /dev/null +++ b/previews/PR166/tutorials/index.html @@ -0,0 +1 @@ + Flux – Elegant ML

This section contains tutorials contributed by the Flux community and examples from the The Model Zoo.

Generative Adversarial Networks (October 2021)

Deep Convolutional Generative Adversarial Network (DCGAN) (October 2021)

Simple ConvNet (February 2021)

Simple multi-layer perceptron (January 2021)

Using Flux DataLoader (January 2021)

Deep Learning with Flux - A 60 Minute Blitz (November 2020)

Transfer Learning with Flux (October 2020)

\ No newline at end of file