Tensorflow: Antarmuka Jawa

Bagus!

Memindahkan komentar ini ke sini dari https://github.com/tensorflow/tensorflow/issues/3 :

Ada testsuite dengan konvergensi yang cukup baik, tetapi saat ini sebagian besar Python dengan beberapa tes C++. Ada juga banyak fungsi untuk membuat grafik yang saat ini hanya Python, khususnya fungsi diferensiasi otomatis, meskipun itu tidak masalah untuk evaluasi grafik di Jawa. Ada rencana untuk memindahkan fungsionalitas ini ke C++ yang mendasarinya di masa mendatang, di mana pengikatan Java SWIG akan lebih berguna untuk membuat grafik.

Jika seseorang mengambil tantangan Java SWIG, kami akan dengan senang hati menerimanya sambil menunggu tinjauan hulu, dll., yang pada titik itu akan menjadi bagian dari pengujian berkelanjutan kami. Rincian penerimaan kontribusi sedang berubah saat ini, tetapi itu akan stabil.

Hallo teman-teman
Kami juga tertarik untuk mengadaptasi TensorFlow untuk Java. @ravwojdyla Apakah Anda, kebetulan, mulai mengerjakan Antarmuka Swig untuk Java? Jika sudah, kami dapat bergabung dengan upaya kami dan berkolaborasi dalam hal itu

Halo,
Saya sedang mengerjakan bungkus SWIG dari C++ API utama. Anda dapat melihat kemajuan saya sejauh ini pada garpu saya, tetapi apa yang ada di sana belum selesai; Saat ini saya mengalami masalah di mana #include "tensorflow/core/lib/core/error_codes.pb.h" tidak dapat diselesaikan dan saya tidak dapat menemukan file yang dimaksud di mana pun di dalam file proyek. Masukan dalam bentuk apa pun akan sangat dihargai.

Ada preset javacpp yang tersedia untuk perpustakaan seperti Caffe dan OpenCV. Lihat juga https://github.com/bytedeco/javacpp-presets/issues/111. Java-cpp aktifkan juga IOS dengan RoboVM

@girving Komit awal di https://github.com/bytedeco/javacpp-presets/commit/374e1d5ea3cb4db36144aeec2cac33d32e1a7489

/cc @saudet

@pslam - Saya bisa mengerjakan sedikit tentang ini - pasti bisa menggunakan bantuan!

Hai teman-teman, saya yakin saya memiliki binding yang cukup fungsional untuk JavaCPP: https://github.com/bytedeco/javacpp-presets/tree/master/tensorflow. Beri tahu saya jika Anda melihat sesuatu yang dapat dilakukan dengan SWIG, tetapi bukan JavaCPP. Saya pasti bisa menggunakan umpan balik. (Terima kasih atas ccnya @bhack!)

Dilakukan dengan sangat baik @saudet! Saya hampir menyelesaikan bungkus SWIG, tetapi tampaknya implementasi Anda berfungsi dengan baik. Saya tidak melihat apa pun yang dapat dilakukan oleh bungkus SWIG saya yang tidak dapat dilakukan oleh Anda. JavaCPP tampaknya sangat keren, saya harus menggunakannya untuk proyek-proyek masa depan.

Hai @kylevedder , error_codes.pb.h ?
[Diedit]
Semua file .pb.h dikompilasi dari .proto

@tngan Ya, itulah yang saya temukan juga. Selain itu, file .proto dalam proyek ini memerlukan ProtoBuff3 untuk digunakan. Saya menggunakan Ubuntu 14.04 dan ProtoBuff3 tidak tersedia di manajer paket saya, jadi saya mengkompilasinya dari sumber, yang saya dapatkan dari rilis beta 3.0.0 .

Penghalang jalan saat ini yang saya coba pecahkan adalah bagaimana membuat ProtoBuff berulang di seluruh pohon file dan mengkompilasi file .proto menjadi file .h dan .cc ; melakukan setiap folder sedikit demi sedikit menghasilkan kegagalan karena ketergantungan yang tidak terpenuhi pada file .proto lain yang belum dikompilasi.

@kylevedder Apakah pembungkus SWIG Anda di repositori terpisah atau apakah Anda bekerja di repositori tensorflow? protoc bekerja mirip dengan kompiler lain. Jika Anda bekerja di repositori tensorflow atau menggunakan Bazel, maka Anda perlu menyiapkan target build protobuf dan dependensi di antara mereka.

Jika Anda bekerja di repositori terpisah dan menggunakan sistem build yang berbeda, maka Anda perlu menggunakan plugin protobuf untuk sistem build tersebut.

Saya akan dengan senang hati membantu Anda menyiapkan bangunan jika Anda mau.

@davidzchen Terima kasih atas tawarannya, setiap dan semua bantuan sangat dihargai.

Apa yang saya miliki sejauh ini:

Saya telah menyiapkan Bazel dan membuatnya untuk dikompilasi menjadi file .whl , yang kemudian saya serahkan ke pip dan mengonfirmasi bahwa saya dapat menjalankan program First TensorFlow .

Saya telah membuat file pembungkus SWIG di repositori bercabang saya. Mereka berada di folder di bawah core/javaWrapper . [[link](https://github.com/kylevedder/tensorflow/tree/master/tensorflow/core/javaWrapper)]

Apa yang saya coba lakukan:

Pada akhirnya, tujuan saya adalah menghasilkan file .so yang dapat disebut sebagai perpustakaan asli di Java. Saat ini, saya mencoba menggunakan g++ untuk mengkompilasi seluruh sistem menjadi file .so ; namun, file .proto harus terlebih dahulu diperluas menjadi .h s dan .cc s sebelum kompilasi ini, dan itulah yang saya coba lakukan dengan protoc .

Anda dapat melihat upaya saya pada skrip bungkus di sini untuk berpotensi mendapatkan ide yang lebih baik tentang apa yang saya dapatkan, meskipun sejauh ini semua upaya saya menggunakan protoc telah direktori demi direktori dan, akibatnya, tidak dalam naskah.

Akhirnya, umpan balik apa pun tentang bidang perbaikan akan sangat dihargai. Terima kasih!

@kylevedder Saya sudah memiliki .so build sebagai bagian dari Preset JavaCPP: https://github.com/bytedeco/javacpp-presets/tree/master/tensorflow. Berkat Bazel, ini sangat sederhana. Cukup terapkan tambalan seperti ini:

diff -ruN tensorflow/tensorflow/cc/BUILD tensorflow-patch/tensorflow/cc/BUILD
--- tensorflow/tensorflow/cc/BUILD  2015-11-22 00:00:02.441829192 +0900
+++ tensorflow-patch/tensorflow/cc/BUILD    2015-11-14 11:15:12.689330351 +0900
@@ -75,6 +75,17 @@
     ],
 )

+cc_binary(
+    name = "libtensorflow.so",
+    copts = tf_copts(),
+    linkshared = 1,
+    deps = [
+        ":cc_ops",
+        "//tensorflow/core:kernels",
+        "//tensorflow/core:tensorflow",
+    ],
+)
+
 filegroup(
     name = "all_files",
     srcs = glob(

Dan jalankan Bazel seperti ini, misalnya:

bazel build -c opt //tensorflow/cc:libtensorflow.so

AFAIK, ini harus melahap cukup banyak hal menarik untuk C++ API.

@saudet Apakah ada alasan mengapa Anda menggunakan aturan cc_binary untuk membangun perpustakaan bersama daripada cc_library ? Anda hanya dapat memiliki aturan cc_library dengan nama tensorflow dan target pembangunan akan membangun perpustakaan bersama yang disebut libtensorflow.so .

@kylevedder Jika tujuan Anda adalah menghasilkan file .so , maka sesuatu yang mirip dengan yang disarankan @saudet akan berfungsi.

Jika Anda perlu menggunakan proto TensorFlow dalam kode Java, maka Anda perlu menambahkan dependensi dari target build Bazel java_* ke target proto_library yang menghasilkan kelas Java dari .proto file.

Kami masih memiliki sedikit pekerjaan yang harus dilakukan sebelum kami membuka sumber aturan asli proto_library (lihat bazelbuild/bazel#52), tetapi sementara itu, TensorFlow menggunakan cc_proto_library dan py_proto_library aturan yang disediakan oleh protobuf , dan untuk Java, Anda harus dapat menggunakan aturan Java genproto yang disertakan dengan Bazel . Saya akan memeriksa dengan tim untuk mengetahui apa timeline untuk proto_library dan apakah akan bermanfaat untuk menyatukan aturan yang disediakan oleh Protobuf dengan genproto .

Beberapa umpan balik lainnya:

• Saya pikir akan lebih baik untuk menjaga nama direktori tetap konsisten dan menggunakan java_wrapper daripada javaWrapper
• Mungkin tempat yang lebih baik untuk pembungkus Java adalah //tensorflow/java/wrapper daripada //tensorflow/core/java_wrapper ?
• Secara internal, kami memiliki beberapa aturan build yang mengambil file .swig dan menghasilkan sources. Ini lebih ideal karena kami akan menghindari memeriksa file yang dihasilkan. Saya dapat melihat untuk melihat betapa sulitnya bagi kami untuk menambahkan beberapa aturan pembuatan SWIG untuk Bazel untuk membuat hal-hal seperti ini lebih mudah.

@davidzchen Tidak ada alasan khusus. Saya baru mengenal Bazel dan hanya menggunakan linkshared=1 seperti yang saya lihat disebutkan di milis berfungsi. Jadi terima kasih untuk tipnya! Saya akan memperbarui itu.

@saudet Terima kasih! Saya hanya memeriksa untuk memastikan bahwa itu bukan masalah dengan Bazel. :) Jangan ragu untuk memberi tahu saya atau membuka bug jika Anda mengalami masalah.

@saudet Terima kasih atas info tentang penggunaan Bazel. Saya juga baru mengenalnya dan tidak menyadari bahwa itu mampu menghasilkan .so dengan cara itu.

@davidzchen Terima kasih atas tambahan tentang menggunakan cc_library , saya memodifikasi contoh dari @saudet sesuai ketika saya mengimplementasikan Bazil wrapper build saya . Juga, terima kasih atas masukan mengenai struktur direktori; Saya telah memperbarui struktur folder saya untuk menyelaraskan dengan saran Anda.

Selain itu, saya tidak begitu jelas dalam komentar saya sebelumnya tentang menghasilkan file .so ; sementara tujuan saya adalah menghasilkan file .so dari sumber aslinya, saya juga ingin menyertakan file .cxx yang dihasilkan SWIG di dalam .so untuk memfasilitasi JNI panggilan. Saat ini, saya mengalami masalah di mana saya tidak bisa mendapatkan file .cxx dihasilkan SWIG untuk dikompilasi; itu mencoba merujuk JNI.h , sebuah header yang terletak di $JAVA_HOME/include/ , tapi sepertinya saya tidak bisa membuat Bazel memahami jalur penyertaan eksternal.

@davidzchen Hum, tidak, cc_library tidak berfungsi. Saya tidak melihat cara lain untuk membuat Bazel meneruskan opsi -shared ke kompiler: http://bazel.io/docs/be/c-cpp.html.

@saudet Saya rasa Anda tidak perlu melewati -shared sendiri. cc_library seharusnya membangun .so secara default. Apakah itu berhasil untuk Anda?

@kylevedder Anda tidak akan dapat menambahkan header JNI seperti itu karena berada di luar ruang kerja. Namun, Bazel menyertakan JDK lokal sebagai repositori lokal dan menyediakan sejumlah target bawaan (lihat jdk.WORKSPACE dan terkait jdk.BUILD ) yang dapat Anda gunakan untuk bergantung pada JDK lokal. Ini termasuk dalam setiap ruang kerja Bazel secara default.

Bazel sendiri menggunakan JNI dan berinteraksi dengan JDK lokal dengan cara ini (lihat src/main/native/BUILD ). Dalam file BUILD ini, ada dua genrule s untuk menyalin header JNI dan target cc_library untuk perpustakaan yang sedang dibangun yang menggunakan JNI yang bergantung pada header, dan includes = ["."] agar kode C++ dapat menyertakan header JNI dengan #include <jni.h> . Saat ini tidak didokumentasikan karena kami sedang mengerjakan sejumlah peningkatan pada mekanisme repositori eksternal, dan nama @local-jdk mungkin berubah, tetapi kami dapat menggunakannya untuk TensorFlow dan proyek Bazel lainnya yang menggunakan JNI untuk sementara .

Berikut ini adalah patch untuk file BUILD Anda yang menambahkan target genrule untuk menyalin header JNI yang Anda butuhkan dan beberapa perubahan pada target cc_library untuk menyiapkan dependensi yang tepat, yaitu:

1. Tambahkan jni.h dan jni_md.h , yang disalin ke paket saat ini dengan genrule s ke srcs
2. Tambahkan ketergantungan pada //tensorflow/core sehingga Anda dapat menyertakan header di bawah tensorflow/core/public . Perhatikan bahwa, header atau file sumber apa pun dalam direktori terpisah berada dalam paket terpisah dari sudut pandang Bazel, dan Anda perlu menambahkan ketergantungan pada target build yang berisi file-file tersebut.

diff --git a/tensorflow/core/java/wrapper/BUILD b/tensorflow/core/java/wrapper/BUILD
index 72b4076..04a3394 100644
--- a/tensorflow/core/java/wrapper/BUILD
+++ b/tensorflow/core/java/wrapper/BUILD
@@ -7,10 +7,30 @@ exports_files(["LICENSE"])
 load("/tensorflow/tensorflow", "tf_copts")
 load("/tensorflow/tensorflow", "tf_gen_op_wrappers_cc")

+genrule(
+    name = "copy_link_jni_md_header",
+    srcs = ["//external:jni_md_header-linux"],
+    outs = ["jni_md.h"],
+    cmd = "cp -f $< $@",
+)
+
+genrule(
+    name = "copy_link_jni_header",
+    srcs = ["//external:jni_header"],
+    outs = ["jni.h"],
+    cmd = "cp -f $< $@",
+)
+
 cc_library(
     name = "java_wrapper",
-    srcs = glob(["*.cc","*.cxx","*.h"]),
-    copts = ["-I$$JAVA_HOME/include/", "-I$$JAVA_HOME/include/linux/"],
+    srcs = glob(["*.cc", "*.cxx", "*.h"]) + [
+        ":jni.h",
+        ":jni_md.h",
+    ],
+    includes = ["."],
+    deps = [
+        "//tensorflow/core",
+    ],
     visibility = ["//visibility:public"],
 )

Perhatikan bahwa secara umum, tindakan kompilasi di Bazel dijalankan dari akar pohon sumber, dan Anda perlu mengubah penyertaan dalam file SWIG Anda sebagai berikut dan kemudian membuat ulang file C++ sehingga mereka memiliki penyertaan yang benar sebagai dengan baik:

diff --git a/tensorflow/core/java/wrapper/tensor_c_api.i b/tensorflow/core/java/wrapper/tensor_c_api.i
index d08b571..9ab1fa1 100644
--- a/tensorflow/core/java/wrapper/tensor_c_api.i
+++ b/tensorflow/core/java/wrapper/tensor_c_api.i
@@ -1,8 +1,8 @@
 %module tensor_c_api_module
 %{
-#include "../../public/tensor_c_api.h"
+#include "tensorflow/core/public/tensor_c_api.h"
 %}
-%include "../../public/tensor_c_api.h"
+%include "tensorflow/core/public/tensor_c_api.h"
 %include "stddef.h"

Setelah ini berhasil, Anda akan menyiapkan JNI build untuk Linux karena copy_link_jni_md_header genrule hanya menyalin header khusus Linux. Untuk menyalin header JNI khusus platform yang benar, kita perlu melakukan hal berikut:

1. Siapkan cpu config_setting s untuk platform lain. Saat ini, tensorflow memiliki config_setting untuk --cpu=darwin di tensorflow/python/BUILD . Kita mungkin harus memindahkan paket yang lebih sesuai seperti //tensorflow/core . Pada dasarnya, kita menginginkan set config_setting yang sama dengan Bazel (lihat src/BUILD ).
2. Minta copy_link_jni_md_header menyalin header JNI yang tepat berdasarkan pengaturan konfigurasi yang diatur menggunakan select() , mirip dengan yang ada di Bazel . genrule akan terlihat seperti berikut:

genrule(
    name = "copy_link_jni_md_header",
    srcs = select({
        "//tensorflow/core:darwin": ["//external:jni_md_header-darwin"],
        "//tensorflow/core:darwin_x86_64": ["//external:jni_md_header-darwin"],
        "//tensorflow/core:freebsd": ["//external:jni_md_header-freebsd"],
        "//conditions:default": ["//external:jni_md_header-linux"],
    }),
    outs = ["jni_md.h"],
    cmd = "cp -f $< $@",
)

Saya akan dengan senang hati membantu Anda dalam hal ini jika Anda mengalami masalah apa pun. Beri tahu saya jika ini berhasil untuk Anda.

@davidzchen cc_library menghasilkan banyak file .a, tetapi tidak ada file .so. Saya menggunakan 0.1.0 seperti yang direkomendasikan sebelumnya untuk TensorFlow... Mungkin sudah diperbaiki di 0.1.1? Saya harus mencoba lagi.

@davidzchen Terima kasih banyak atas bantuan Anda. Saya telah mengikuti instruksi Anda dan memperbarui file Java wrapper BUILD serta SWIG .i seperti yang Anda sarankan. Selain itu, saya memindahkan skrip bungkus dari core/java/wrapper ke direktori root dan memperbarui tautan yang sesuai.

Untuk saat ini, saya telah melewatkan generalisasi genrule untuk file jni_md.h , alih-alih berfokus pada mencoba membuat libtensorflow.so dibangun. Sayangnya, bagi saya tampaknya libtensorflow.so tidak sedang dibuat; Saya akhirnya mencari seluruh sistem file saya untuk sesuatu yang bernama beberapa varian "libtensorflow" dan tidak ada yang relevan muncul. Ini mungkin diberi nama yang berbeda atau ini mungkin kasus sederhana dari kesalahan pengguna. Selain itu, ada kemungkinan bahwa ini terkait dengan masalah yang dialami @saudet dengan aturan cc_library untuk pembuatan .so .

Sekali lagi, terima kasih atas semua bantuan Anda, saya sangat menghargainya.

Maaf, ternyata saya salah. Untuk membangun .so yang menyertakan dependensi transitif, apa yang dilakukan @saudet menggunakan cc_binary dengan linkshared = 1 dan name = "libtensorflow.so" adalah benar. Dari dokumentasi cc_binary.linkshared :

Buat perpustakaan bersama. Untuk mengaktifkan atribut ini, sertakan linksshared=1 dalam aturan Anda. Secara default, opsi ini tidak aktif. Jika Anda mengaktifkannya, Anda harus memberi nama biner Anda libfoo.so (atau apa pun konvensi penamaan perpustakaan pada platform target) untuk beberapa nilai foo yang masuk akal.

Perbedaan utama antara .so dibuat oleh target cc_library dan .so dibuat dengan cc_binary menggunakan metode yang dijelaskan di atas adalah bahwa cc_library artefak hanya berisi kode di srcs . Inilah sebabnya mengapa membangun target cc_library tanpa srcs dan hanya deps , seperti //tensorflow/core , tidak menghasilkan artefak apa pun. Di sisi lain, target cc_binary akan terhubung di semua dependensi transitif.

Saya minta maaf atas kebingungan. Mungkin kita harus meningkatkan dokumentasi kita dan menambahkan contoh dalam membangun .so s.

Saya kira Anda harus mengikuti langkah-langkah itu untuk membangun Tensorflow dan semua dependensinya. Kami sedang mengerjakan porting TensorFlow ke node.js, dan saya telah menerapkan skrip shell untuk mengompilasi dan mengambil hanya sumber penting dari seluruh repo:
https://github.com/node-tensorflow/node-tensorflow/blob/1.0.0/tools/install.sh#L233 -L282

@davidzchen Terima kasih atas informasi tentang pembuatan .so . Saya telah memperbarui pengaturan saya dan saya telah membuat tensorflow/core/java/wrapper/example dengan _extremely_ basic tester untuk membuktikan bahwa fungsi JNI memanggil .so berfungsi. Perhatikan bahwa createWrapper.sh harus dijalankan sebelum menjalankan compileAndRun.sh .

Saya akan mencoba meningkatkan pembungkus SWIG dan membuat contoh yang lebih baik, yang saya miliki sekarang hanyalah bukti minimum dari binding yang berfungsi.

Akhirnya, saya ingin mengucapkan terima kasih kepada @davidzchen dan @saudet atas semua bantuannya; Saya tidak akan bisa melakukan ini tanpa mereka.

Bagus! Terima kasih telah mengerjakan ini, @kylevedder!

Jika Anda tertarik, saya dapat mencoba mengintegrasikan skrip createWrapper.sh dan compileAndRun.sh ke dalam build Bazel dengan 1) membuat aturan Skylark SWIG dan 2) menggunakan aturan Java Bazel untuk membuat kode Java.

@davidzchen Itu akan sangat bagus! Saya akan memperbaiki pembungkus SWIG dan contoh dasarnya.

Saya telah menyelesaikan preset untuk JavaCPP dan mem-porting sampel example_trainer.cc :
https://github.com/bytedeco/javacpp-presets/tree/master/tensorflow
Menantikan untuk membandingkan ini dengan pembungkus yang setara menggunakan SWIG!

Sepertinya tautan API rusak: http://bytedeco.org/javacpp-presets/tensorflow/apidocs/

@verdiyanto Maaf, saya belum memiliki CI, tetapi mengunggah dokumen API cukup mudah, jadi setidaknya saya sudah melakukannya. Menikmati!

@saudet Kerja bagus di preset JavaCPP!

Pembaruan pada pekerjaan saya: Saya telah melakukan beberapa pekerjaan lagi pada pembungkus SWIG, dan Anda dapat melihat pekerjaan yang telah saya lakukan di sini . Namun, saya berada di persimpangan jalan dan saya tidak yakin cara terbaik untuk melanjutkan.

Saya agak baru di SWIG, mengingat ini adalah proyek besar pertama saya yang menggunakannya, jadi saya membaca dokumentasi SWIG di SWIG Basics dan di SWIG dan Java yang membahas cara kerja SWIG dan cara membungkus C/C++ dengan pembungkus SWIG Java.

Dokumentasi menjelaskan bagaimana SWIG mengonversi pointer di C/C++ menjadi objek Java yang buram, itulah sebabnya Anda mendapatkan kelas seperti SWIGTYPE_p_void dihasilkan oleh SWIG. Masalahnya adalah tidak ada cara mudah untuk mengubah POJO menjadi kelas SWIG ini.

Jadi, misalnya, dalam tensor_c_api.h , metode C TF_CreateTensor() mengambil void* yang menunjuk ke data input dan parameter size untuk menentukan ukuran data masukan dalam byte. Ini adalah pola desain yang sangat masuk akal untuk C/C++, tetapi sama sekali tidak masuk akal di Java. Metode Java yang dihasilkan SWIG TF_CreateTensor() mengambil objek SWIGTYPE_p_void sebagai datanya, bersama dengan size , tetapi tidak ada cara untuk mengonversi POJO seperti String menjadi SWIGTYPE_p_void tanpa menulis banyak kode.

Dan ini adalah persimpangan di mana saya saat ini berbohong: Saya menulis banyak metode konversi C/C++ yang mengambil jenis apa pun yang ditentukan dalam TF_DataType dan mengonversi ke void* , atau menulis banyak SWIG typemaps untuk melakukan hal yang sama. Dokumentasi SWIG tampaknya tidak mendukung salah satu solusi, karena keduanya tampaknya saling bergantian.

Jadi, pertanyaannya adalah, fungsi konversi C/C++ atau peta tipe SWIG?

@kylevedder Saya melihat Anda mulai mengerti mengapa saya membuat JavaCPP di tempat pertama. :)

Saya telah menggunakan JavaCPP preset @saudet 's, sangat berguna, terima kasih! Saya menggunakannya untuk membangun antarmuka Clojure ke tensorflow.

Beberapa komentar:

a) Ada peluang untuk penyederhanaan / lapisan tingkat yang lebih tinggi

Banyak api JavaCPP mereplikasi fungsionalitas protobuf yang dapat langsung dicapai pada JVM, tanpa jembatan. Butuh sedikit waktu bagi saya untuk menyadari hal ini, tetapi yang satu hanya membangun objek protobuf menggunakan binding JavaCPP, menghasilkan representasi platform-independen ini menggunakan interop, dan kemudian memasukkannya ke dalam Sesi.

Saya akhirnya hanya menggunakan protobuf berbasis jvm untuk membuat grafik secara langsung, melewati fungsi konstruktor JavaCPP. Ini memiliki beberapa keuntungan -- api yang lebih sederhana untuk diprogram, dan juga format .toString yang bagus yang menunjukkan protobuf yang dapat dibaca manusia.

Khususnya untuk Clojure, jauh lebih mudah untuk menggambarkan grafik tensorflow dalam hal struktur data dan kemudian mengubahnya secara langsung menjadi protobuf, daripada mencari dan menjalankan fungsi konstruktor untuk setiap node dalam struktur data saya.

b) Peningkatan bangunan dan paket

Saya tidak ahli dalam membuat kode asli, atau dalam alat pembuatan yang digunakan dalam proyek ini. Akan sangat bagus untuk memiliki artefak yang dibuat oleh pakar; khususnya jika mereka juga menyertakan kelas protobuf Java yang dihasilkan. Butuh waktu yang memalukan bagi saya untuk mencari tahu bagaimana melakukan ini.

c) Akan berguna untuk memiliki sejumlah kecil kasus uji grafik untuk ditargetkan.

Saat ini metodologi saya agak rumit: Gunakan fungsi konstruktor JavaCPP untuk menghasilkan grafik, campurkan ke dalam protobuf JVM saya dan lihat formulir yang dapat dibaca manusia, dan cari tahu cara membuat konstruktor saya sendiri untuk membuat formulir yang sama.

Akan berguna untuk memiliki kumpulan kecil grafik yang sangat sederhana yang menjalankan fungsi inti TensorFlow, sehingga orang-orang seperti saya memiliki serangkaian kasus uji yang masuk akal untuk menargetkan interop ke bahasa yang berbeda.

Pokoknya terima kasih atas upaya semua orang dan terus bekerja dengan baik!

@kovasb Terima kasih atas umpan baliknya! Jelas, ada banyak yang harus dilakukan untuk membuat antarmuka lebih alami ke Java, Scala, Clojure, dll.

Jika Anda memiliki kelas pembantu untuk mengintegrasikan C++ API dengan Java protobuf API, jangan ragu untuk memasukkan semua itu ke dalam paket berikut, termasuk kelas protobuf Java yang dihasilkan itu sendiri, dan kirim PR:
https://github.com/bytedeco/javacpp-presets/tree/master/tensorflow/src/main/Java/org/bytedeco/javacpp/helper
Untuk itulah ia dimaksudkan, dan itu akan secara otomatis dikemas dalam artefak Maven, sesuatu yang tampaknya tidak didukung oleh Bazel. Bagaimanapun, terima kasih telah melihat ini!

@kovasb Antarmuka clojure terdengar sangat menarik. Sudah punya kode untuk dibagikan?

Terima kasih!

Jadi orang-orang di utas ini juga sadar, di https://github.com/tensorflow/tensorflow/issues/3 telah diangkat: diferensiasi otomatis saat ini tidak berfungsi kecuali Anda menggunakan TF dari python api. Ini tampak seperti showstopper yang menunggu fungsionalitas porting ke C++.

Saya tidak begitu mengerti aliran data tetapi mungkin mungkin untuk meluncurkan hal-hal pembantu python bersama dengan lib C++?

Solusi lain yang saya cari adalah hanya menggunakan Jpy atau salah satu jembatan lain (ada yang punya rekomendasi?) JyNi juga terlihat cukup menarik tetapi cukup jauh dari primetime (meskipun akan lebih bagus untuk melihat lebih banyak momentum/komunitas di belakangnya)

Jika JyNi diselesaikan, itu + jython akan memberi JVM cerita yang sangat mengagumkan tentang interop ekosistem python. Seseorang bisa bermimpi.

+1 untuk antarmuka Java!

jika kita bisa menggunakan javaCPP, apakah SWIG masih diperlukan? akankah kita berkolaborasi untuk mengimplementasikan antarmuka SWIG?

@maxiwu Saya suka berpikir bahwa JavaCPP melakukan pekerjaan yang lebih baik daripada SWIG, tapi saya semua membandingkannya untuk benar-benar membuktikannya :)

@kovasb Saya akan sangat tertarik untuk membantu/berkontribusi ke antarmuka Clojure.

@sorenmacbeth email saya di nama depan dot nama belakang saya di gmail, senang memandu Anda melalui apa yang saya miliki ...

Tampaknya kita memiliki preset Javacpp yang cukup lengkap. Apakah ini solusi yang dapat diterima untuk "tim"?

@saudet Saya mencoba membuat salinan pembungkus JavaCPP, tetapi tampaknya karena laju perubahan yang cepat dari sumber tensorflow mereka tidak kompatibel dengan rilis 0.6.0 atau cabang master hari ini. Apakah mungkin untuk memperbaruinya dengan penunjuk ke komit/versi tensorflow yang tepat yang mereka uji?

@nikitakit Saya baru saja membuat pembaruan untuk cabang master di sini: https://github.com/bytedeco/javacpp-presets/commit/43bdcdf03beaaddb4bd5badf5d4f79669e9e78dd

Tidak seperti Caffe, TensorFlow tampaknya mendapatkan rilis setiap bulan atau lebih, jadi saya rasa saya akan mulai menstabilkan ikatan pada titik-titik itu, dimulai dengan rilis berikutnya (0.7.0?)

@martinwicke Bagaimana menurutmu?

Ketika ada Java binding yang stabil, saya senang bekerja di Scala API.

/ cc @databricks

@kovasb saya pikir saya melewatkan ini pertama kali. Apakah Anda mengatakan bahwa semua keajaiban diferensiasi otomatis yang kami dapatkan dari penggunaan TensorFlow melalui python diimplementasikan di dalam python, bukan di dalam c++ libs? Jadi dalam praktiknya, Java API perlu mengimplementasikan kembali semua ini, atau hanya pustaka numerik lainnya? Saya tidak cukup akrab dengan bagian dalam TensorFlow atau lem python untuk memahami dengan tepat apa pengangkatan berat yang dilakukan di mana.

@drdozer itulah pemahaman saya, berdasarkan komentar oleh @girving dan kemudian mencari sumbernya sendiri. Mengimplementasikan kembali hal-hal di Jawa sepertinya bukan pemula. Saya sarankan melihat komentar di # 3

Jika seseorang benar-benar tertarik, saya hanya akan merekomendasikan mencoba melakukan beberapa contoh pelatihan menggunakan api Java (sejauh ini saya baru saja melihat/melakukan jalur maju).

Saya ingin tahu seberapa jauh kita akan menjalankan kode Python dengan Jython...

Saya percaya lapisan Python API memiliki banyak logika yang tidak diekspos oleh API lapisan C++.
Saya mencoba mengikuti jalur JavaCpp tetapi pada akhirnya akan ada banyak kode duplikasi dan akan sulit untuk mempertahankan konsistensi ketika ada perubahan dalam implementasi Python.

Mungkin jalur yang lebih mudah adalah menggunakan Jython seperti yang telah disebutkan @saudet sebelumnya ...

Itu ditugaskan di https://github.com/tensorflow/tensorflow/issues/476 ke @ josh11b. Jika dia sedang mengerjakan ini, tidak masuk akal untuk menggunakan Jython.

Jika kita menggunakan jython apakah kode c++ masih berfungsi? Saya ingin menggunakan ini untuk server yang ada di Java tetapi saya terjebak antara mencoba rute Java secara langsung atau hanya mengirim data melalui soket ke proses Python

Saya ingin menyebutkan bahwa meskipun Java API tidak menyertakan banyak fitur seperti diferensiasi otomatis, saya belum menemukan ini sebagai penghalang untuk pekerjaan saya sendiri. Saya telah sukses besar menghasilkan model di python, serialisasi ke file .proto, dan kemudian membukanya melalui pembungkus Java untuk pelatihan. Hal yang sama dapat dilakukan untuk waktu pengujian, karena saya yakin fungsionalitas Saver tersedia melalui C++ dan Java API.

+1

@saude
Terima kasih telah membuat javacpp dan preset untuk tensorflow. Saya berhasil membuat ulang grafik Python di Java, tetapi saya terjebak mencoba memulihkan dari file model yang disimpan. Baris ini tidak berfungsi:

Tensor fn = new Tensor(tensorflow.DT_STRING, new TensorShape(1));
Penyangga CharBuffer = fn.createBuffer();
buffer.put("modelfile.tf");
sesi.Jalankan(...);

tetapi CharBuffer ternyata NULL. Jika saya mengubah DT_STRING menjadi DT_FLOAT, saya mendapatkan FloatBuffer, tetapi DT_STRING sepertinya tidak berfungsi.

@nikitakit kamu bilang kamu berhasil. dapatkah Anda membagikan kode Anda?

@lakshmanok

EDIT: maaf, salah membaca apa yang Anda katakan di sini. Saya tidak dapat memberikan bantuan apa pun untuk menggunakan penghemat eksternal dari Java

Untuk referensi, bagian dari kode saya yang mengimpor grafik tensorflow ada di sini: https://Gist.github.com/nikitakit/d3ec270aee9d930267cec3efa844d5aa

Ada di Scala, tetapi porting ke Java/bahasa JVM lainnya harus mudah.

Kode saya untuk benar-benar menjalankan node dalam grafik sayangnya sangat terikat dengan kerangka Scala yang saya gunakan, jadi Anda harus bergantung pada dokumen API tensorflow untuk bagian ini.

Adakah yang punya tempat dengan menyematkan lingkungan python tensorflow di jvm? Katakan dengan jython + JyNI? Atau apakah ini semua terlalu eksperimental untuk bekerja dengan andal?

Saat ini saya sedang bekerja untuk memperluas C API untuk menambahkan dukungan untuk definisi grafik. Tidak yakin kapan itu akan dilakukan, tetapi itu adalah salah satu tujuan kami sebelum 1.0.

Saya sedang bekerja menggunakan aliran tensor dari Java. Saya mendekati masalah dengan menggunakan jython dan memodifikasi pustaka cpython aliran tensor untuk mengakomodasi juru bahasa python lain. cpython harus tetap bekerja dengan sempurna dan kode saya mendeteksi jika penerjemahnya adalah Jython dan memodifikasi impor/modul untuk memungkinkannya berfungsi. Di bawahnya menggunakan binding javacpp untuk libtensorflow_cc.so. Apakah ini sesuatu yang terbuka untuk dimiliki oleh tim google dalam repo resmi? @vrv

Itu sepertinya bukti konsep yang bagus tapi saya pikir pengikatan resmi mungkin ingin mengikat lebih asli daripada melalui Python :(

tidak, alih-alih memanggil pembungkus c-python, kita memanggil pembungkus javaccp. Jadi itu akan sama dengan aliran tensor cpython tetapi dievaluasi dari JVM menggunakan Jython. Menerapkan kembali seluruh logika python dalam bahasa lain tampaknya terlalu banyak, Anda berakhir dengan API lain. binding javacpp memungkinkan Anda untuk menjalankan Inferensi tanpa masalah tetapi model harus dibangun/dilatih dari skrip cpython saat ini.

Adakah yang pernah melihat cara membuat tensorflow bekerja dengan Kotlin? Tampaknya lebih cocok secara alami dan pada akhirnya masih 100% java. Saya menemukan bahasa Kotlin sebagai jalan tengah yang sangat bagus antara python dan Java murni.

Pembaruan: Saya berhasil menyelesaikan semuanya dengan javacpp (terima kasih kepada @saudet ) dan membuat program Java membaca/mengeksekusi model TensorFlow.

https://medium.com/google-cloud/how-to-invoke-a-trained-tensorflow-model-from-java-programs-27ed5f4f502d#.tx8nyds5v

Terima kasih @lakshmanok dan @saudet . Proyek javacpp tampaknya mengimplementasikan sebagian besar API TensorFlow. Kami mencoba menjalankan tensorflow/serving di Java.

API sederhana dan ditentukan oleh protobuf . Sekarang kami telah mengimplementasikan server dan ingin mengimplementasikan klien di Jawa. Itu hanya perlu membangun TensorProto di Java dan memanggil panggilan gRPC . TensorFlow telah menyediakan fungsi pembantu untuk mengonversi array multidimensi untuk Python dan C++, tetapi tidak untuk Java.

Bisakah Anda memberi tahu cara menggunakan javacpp atau menerapkan sendiri untuk ini?

Apa yang Anda cari mungkin sudah ada di https://github.com/bytedeco/javacpp-presets/blob/master/tensorflow/src/main/Java/org/bytedeco/javacpp/helper/tensorflow.java tapi beri tahu saya jika ada yang kurang disana. Terima kasih!

ini masih diusahakan? apakah ada repo github resmi untuk proyek port ini? Saya melihat beberapa repo acak, tetapi tidak tahu.

Ya, tapi mungkin sekitar bulan Oktober/November. Kami menggunakan C API alih-alih SWIGing ke C++ API. Sementara itu, Anda dapat menggunakan binding yang disebutkan saudet.

bagaimana Anda sampai pada kesimpulan untuk menggunakan C API? kami sedang mengerjakan
antarmuka ruby ​​​​menggunakan swig:
http://github.com/somaticio/tensorflow.rb

Pada Selasa, 13 Sep 2016 pukul 18.22, Jonathan Hseu [email protected]
menulis:

Ya, tapi mungkin sekitar bulan Oktober/November. Kami menggunakan C API
alih-alih SWIG ke C++ API. Sementara itu, Anda dapat menggunakan
ikatan yang disebutkan saudet.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/5#issuecomment -246844192,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAA5v3g86Z6D1rz-aTGdMyMWnQZhrZUYks5qpyIJgaJpZM4Getd8
.

Ke depannya, kami lebih suka semua binding bahasa menggunakan C API. Seorang dokter akan datang.

Anda dapat melihat contoh penggunaan di sini:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/go

Namun, tidak ada urgensi, dan membangun di atas SWIG baik-baik saja untuk saat ini.

@jhseu Apakah itu berarti bahwa C API akan diperluas untuk mencakup semua yang saat ini dapat diakses oleh binding Python?

Wah, perubahan besar. Berharap ini diputuskan sebelumnya. Pokoknya untuk melihat dokumen
lebih cepat?

Pada hari Rabu, 14 Sep 2016 jam 17:56, Samuel Audet [email protected]
menulis:

@jhseu https://github.com/jhseu Apakah itu berarti bahwa C API akan
diperluas untuk mencakup semua yang saat ini dapat diakses oleh binding Python?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/5#issuecomment -247167887,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAA5vwfBJoZC2s33_7E9Xy6-NYNUjHjnks5qqG2FgaJpZM4Getd8
.

@saudet Sebagian besar fungsionalitas, kecuali dalam jangka pendek, beberapa hal akan hilang (seperti gradien, pengoptimal).
@jtoy Tidak ada urgensi bagi Anda untuk bermigrasi. SWIG akan terus bekerja untuk sementara waktu.

Dokumen hanya menjelaskan cara melakukannya dan konvensi penamaan. Anda dapat mulai bermigrasi ke C API tanpa mereka, meskipun:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/c/c_api.h

Terima kasih @saudet . Saya telah menemukan ini di stackoverflow tentang menghasilkan TensorProto dengan API protobuf murni. Dan berikut adalah contoh kode TensorFlow yang melayani klien Java gRPC.

@tobegit3hub Bagus, jika Anda dapat membuat ini bekerja dengan C++ API, silakan tambahkan ke paket pembantu Preset JavaCPP dan kirim permintaan tarik! Orang ini akan tertarik pada sesuatu seperti itu: https://github.com/bytedeco/javacpp-presets/issues/240

@girving Apakah javacpp sudah menyelesaikan masalah?
Saya ingin berkontribusi pada tensorflow Java api , saya lebih suka mengimplementasikannya seperti python.

Hai teman-teman, apakah seseorang sudah mulai mengerjakan binding bahasa Java/Scala menggunakan C API?
(Alih-alih membangun di atas SWIG)

Saya memiliki antarmuka Java/Scala yang berfungsi ke tensorflow hanya menggunakan C API melalui JNR . Sayangnya, saya belum memiliki izin untuk membukanya. Saya akan memposting di sini jika dan ketika saya merilisnya. Ini masih dalam proses, tetapi sangat fungsional.

@jdolson Apakah API yang Anda ekspos menerima objek buffering protokol TensorFlow? Salah satu masalah terbesar yang saya alami saat menggunakan preset javacpp dari @saudet adalah ketika Anda memanipulasi objek tensor dalam kode klien Java, Anda berurusan dengan org.tensorflow.framework.TensorProto yang dihasilkan oleh compiler buffer protokol ketika dikonfigurasi untuk menghasilkan Java. Tetapi dalam pembungkus TensorFlow API Anda berurusan dengan org.bytedeco.javacpp.tensorflow.TensorProto.TensorProto yang dihasilkan oleh javacpp ketika diarahkan ke kode c yang dihasilkan oleh kompiler buffering protokol saat dikonfigurasi untuk menghasilkan C. Karena jenisnya tidak ' sama halnya Anda tidak dapat langsung menggunakan tensor kode Java saat memanggil API TensorFlow yang dibungkus.

@Intropy Ya, saya mengkompilasi semua sumber tensorflow *.proto ke kode sumber Java dengan protoc dan menggunakan kelas-kelas itu di API.

@jhseu Apakah antarmuka C API masih di jalur yang akan dirilis dalam bulan November? Jika tidak, bagaimana statusnya saat ini?

@eaplatanios : API C sebagian besar stabil (dan akan secara resmi demikian pada 1.0) dan dapat digunakan meskipun tidak lengkap (masih kehilangan kemampuan untuk menghitung gradien secara otomatis ke grafik). Dokumen yang menjelaskan bagaimana C API dapat digunakan untuk membangun ikatan bahasa ada di https://www.tensorflow.org/how_tos/language_bindings/index.html

Go API diimplementasikan menggunakan C API sebagai contoh pertama mengikuti dokumen di atas.

Kami berharap Java binding juga dibangun di atas ini (menggunakan JNI) dan sudah mulai sedikit mengeksplorasinya. Setiap komentar / pembelajaran orang telah didasarkan pada menggunakan @saudet 's karya indah dengan mendapatkan JavaCPP kerja akan menyenangkan untuk mengetahui tentang.

Saya punya beberapa saran berdasarkan penggunaan JavaCPP binding.

Pertama, karena buffer protokol dikompilasi langsung ke java, versi java harus digunakan. Lebih disukai menurut saya buffer protokol yang mengambil bagian dalam API harus tersedia secara terpisah sebagai modul maven dan harus disertai dengan definisi proto sehingga orang-orang di tumpukan Java memiliki cara mudah untuk mendapatkan definisi sebagai biner serta mudah cara untuk mendapatkan definisi proto untuk dimasukkan dalam definisi proto lainnya.

Kedua, akan sangat membantu untuk menemukan versi minimum libc yang dibutuhkan TensorFlow dan membangunnya.

Ketiga, jauh lebih mudah untuk menggunakan API yang dirancang dengan cermat daripada yang dibuat secara otomatis. Saya tahu itu jelas dan terdengar seperti tembakan di JavaCPP. Saya tidak bermaksud demikian. Saya sangat senang antarmuka yang dibuat secara otomatis ada. Ini _is_ dapat digunakan. Tapi itu membutuhkan percakapan yang aneh, memiliki banyak kutil, dan cukup sulit untuk membaca kode untuk mengetahui bagaimana melakukan apa yang Anda coba lakukan. Saya berharap saran ini lebih bermanfaat daripada "Anda harus membuatnya bagus", tetapi saya kira intinya adalah terlihat betapa berbedanya C++ API dan python API. Keduanya mudah karena sesuai dengan lingkungannya sehingga kode yang dikonversi secara otomatis tidak mungkin cocok.

Mungkin lebih baik untuk mendukung C backend dari Swig dan menghasilkan TF C API melalui Swig juga: https://github.com/swig/swig/issues/800 sehingga bahasa lain seperti Go, Ruby, R dapat menggunakan C api untuk menulis binding mereka sendiri.

Kami memiliki API C yang ada untuk menambahkan dukungan untuk bahasa apa pun dengan C FFI:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/c/c_api.h

(Dan itulah yang digunakan untuk membangun binding Go, Java, Rust, dll. untuk TensorFlow)

Bisakah C API diakses menggunakan JNA ?

@jhseu Maksud saya, itu mungkin dihasilkan dari C++ API sebelumnya, sebelum mengimplementasikan C API secara manual.

@ Quantum64, di sini adalah Scala mengikat tensorflow yang menggunakan JNA.

Karena masalah ini masih terbuka, bagaimana
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/java
sedang dilaksanakan dan apa PR untuk komit?

@hsaputra : Bisakah Anda menjelaskan apa yang Anda cari? Ada beberapa komit yang berkontribusi pada kode di tensorflow/java , yang sebagian besar dirujuk dalam masalah ini (seperti 2b1cd28, d73a266 dan banyak lainnya di antaranya)

HI @asimshankar , terima kasih atas jawabannya.

Saya hanya ingin tahu apa jalur yang tensorflow/java ambil untuk mengimplementasikan Java API karena tiket ini tidak ditutup.
Ada diskusi tentang menggunakan JavaCPP vs SWIG vs panggilan melalui Jython.

Sepertinya tensorflow/java diimplementasikan dengan JNI langsung untuk memanggil C API?

Benar.

Hai,

Saya baru saja membuat binding Swig ini berfungsi kemarin. Saya memiliki permintaan untuk perubahan API. Saat ini untuk menghasilkan refleksi Tensor diperlukan dan format arraynya agak berat, karena memerlukan penggunaan array Java asli n-dimensi. Bisakah kita mempertahankan antarmuka ini, tetapi juga menambahkan beberapa metode untuk membuat tensor yang memerlukan array 1 dimensi dan menentukan bentuknya menggunakan array panjang lainnya? Saya membayangkan itu bisa terlihat seperti ini:

double[] matrix = {1.414, 2.718, 3.1415, 3.4, 56.7, 89.0};
long[] shape = {2, 3};

// add a method for each primitive type
org.tensorflow.Tensor tensor = org.tensorflow.Tensor.createDouble(matrix, shape);

Ini juga akan mengarah pada kemungkinan membuat tensor int8, int16, uint8, uint16, uint32 juga, yang akan membantu kompatibilitas.

Haruskah saya menjadikan ini masalah? Atau di sini baik-baik saja?

Juga, lebih dari senang untuk mencoba membangun metode ini.

@hollinwilkins : Saya berharap PR #6577 mengatasi ini, hanya dengan sedikit perubahan pada metode pabrik yang Anda usulkan:

Tensor tensor = Tensor.create(shape, DoubleBuffer.wrap(matrix));

@asimshankar Ini bagus! Terima kasih atas balasan cepatnya. Sepertinya cukup dekat untuk digabungkan juga :+1:

Saya mencoba menggunakan Java API baru, dan saya menemukan beberapa hal yang membuatnya lebih sulit untuk digunakan daripada yang saya kira seharusnya:

1. Java API harus menerima objek GraphDef. Saat ini hanya menerima array byte yang mewakili biner serial dari buffer protokol GraphDef. Aneh untuk memerlukan langkah serialisasi/deserialisasi di batas perpustakaan.
2. Session.Runner.feed harus dapat menerima org.tensorflow.framework.TensorProto atau harus ada cara yang baik untuk membuat org.tensorflow.Tensor dari org.tensorflow.framework.TensorProto.
3. Session.Runner.run mengembalikan daftar objek Tensor. Mirip dengan di atas seharusnya ada cara mudah untuk mendapatkan output TensorProto baik secara langsung atau dengan memberikan org.tensorflow.Tensor cara yang baik untuk mengonversi ke TensorProto.
4. Session.Runner.run menelan Status. Seharusnya ada cara untuk mendapatkan informasi tentang kegagalan itu, mungkin dengan melemparkan pengecualian.

Juga, mungkin saya melewatkan cara untuk menangani ini, tetapi bagi saya sepertinya saya tidak bisa mendapatkan semua jenis tensor yang didukung dalam output dari run. Misalnya jika tensor keluaran saya adalah dtype INT16, maka tidak ada cara untuk mengekstrak nilai darinya. Tidak ada Tensor.shortValue atau sejenisnya, dan Tensor.intValue tampaknya memerlukan kecocokan yang sama persis. Saya mendasarkan ini pada membaca DEFINE_GET_SCALAR_METHOD di tensor_jni.cc.

@Intropy : Terima kasih atas komentar Anda dan itu pasti masuk akal. Untuk saat ini saya dapat berbagi beberapa pemikiran singkat dengan Anda:

RE: protobufs: Pada titik ini kami mencoba untuk menjaga API inti independen dari protobuf karena sejumlah alasan (termasuk penggunaan pada sistem yang dibatasi sumber daya di mana sesuatu seperti nanproto mungkin lebih tepat). Jadi, itulah alasan mengapa kami ragu-ragu, tetapi itu adalah sesuatu yang kami pikirkan dan saran sangat kami hargai. Salah satu kemungkinannya adalah memiliki semua fungsionalitas terkait protobuf dalam paket terpisah sehingga ada pemisahan yang jelas.

Jadi, kembali ke poin Anda:

1. Lihat di atas. Padahal, saya bertaruh bahwa ada banyak kasus di mana byte[] lebih masuk akal (seperti membaca grafik dari file atau saluran jaringan)

2. Poin diambil

3. Lihat di atas.

4. Session.runner.run tidak boleh menelan status. Jika ada kesalahan, pengecualian akan dilemparkan ( session_jni.cc:166 ). Jika itu tidak terjadi, silakan ajukan bug.

Anda benar, belum semua jenis didukung, tetapi seharusnya cukup mudah untuk ditambahkan. Jika Anda memiliki kebutuhan mendesak untuk jenis yang hilang, jangan ragu untuk mengajukan masalah dan/atau mengirimkan PR. Kontribusi dipersilahkan :)

@asimshankar Terima kasih atas pemikiran Anda.

Mengenai poin pertama, sebenarnya bukan masalah besar. Seperti yang Anda katakan ada saat-saat di mana byte[] paling masuk akal. Dalam kasus penggunaan saya sendiri, saya memiliki InputStream, yang sepele untuk dikonversi ke byte[]. API buffering protokol membuat konversi menjadi mudah. Saya hanya menganggap byte[] sebagai kutil pada API karena Anda tetap harus melakukan deserialize (dalam TF_GraphImportGraphDef) dan dengan cara ini Anda kehilangan beberapa jenis keamanan. Ada juga serialisasi json proto3 yang perlu dipertimbangkan.

Pada status menelan, Anda benar. Saya melewatkan pengecualian yang tidak dicentang.

Cara paling jelas untuk menangani 2 dan 3 adalah dengan memberi org.tensorflow.Tensor sebuah pabrik yang mengonversi dari TensorProto dan beberapa toTensorProto(). Jika kasus penggunaan terbatas sumber daya adalah masalah dengan buffer protokol, maka orang-orang dalam keadaan seperti itu tidak dapat menggunakan fungsi-fungsi itu. Masalahnya adalah bahwa orang yang menggunakan fungsi tersebut akan membayar biaya konversi yang kemungkinan dapat dihindari dengan meminta Tensor menyimpan datanya secara langsung di protobuff. Saya belum pernah bekerja dengan jni sebelumnya, jadi saya mengalami kesulitan mengikuti cara data disimpan, tetapi sepertinya itu pada dasarnya memperlakukan nativeHandle seperti penunjuk ke TF_Tensor yang memiliki TensorBuffer yang pada dasarnya diperlakukan seperti ukuran kosong*.

Bisakah kami memecahkan masalah ini dan mengajukan masalah terpisah untuk setiap fitur di antarmuka Java? Ini akan membuat lebih mudah untuk melacak/mengurai, maka kita bisa menutup masalah ini.

@drpngx : Niat saya adalah untuk mendapatkan beberapa perubahan lagi (membaca tensor dari buffer) sebelum menutup ini seperti yang kami lakukan untuk Go dan meminta fitur/bug diajukan satu per satu. Jadi semoga segera.

Kedengarannya bagus, terima kasih!

Baiklah, sepertinya kami memiliki cukup dasar untuk membangun (misalnya, cukup untuk membuat contoh LabelImage dan orang-orang mengajukan permintaan bug/fitur yang lebih spesifik.

Saya akan menutup masalah ini. Masih banyak yang harus dilakukan di Java API, tetapi mari kita bahas/lacak hal itu dalam masalah terpisah. Terima kasih!

@asimshankar kami sedang dalam proses memilih kerangka kerja pembelajaran mendalam (mxnet/tf) dan etl/api kami didasarkan pada aliran percikan/akka...Apakah ada rencana untuk menambahkan dukungan distributed_runtime ke Java API untuk menjalankan model pelatihan paralel menggunakan ps node ? ps node sangat penting bagi kami untuk banyak kasus penggunaan... preset javacpp mungkin lebih mudah diekspor untuk potongan pertama karena C API itu sendiri tampaknya tidak memiliki distributed_runtime di dalamnya...

@debasish83 : Termasuk runtime terdistribusi dengan sendirinya adalah sepele, tetapi ada banyak konstruksi tingkat yang lebih tinggi di API Python seperti kelas Estimator yang menangani banyak hal (pemeriksaan, penyimpanan ringkasan, dll. membuat visualisasi melalui TensorBoard sepele) yang mungkin membuatnya lebih cocok untuk menjalankan pekerjaan pelatihan dengan Python.

Semua ini dapat dibangun menggunakan primitif yang ada di Java API, tetapi pendekatan yang tepat akan bergantung pada kebutuhan Anda yang tepat.

Mungkin kita harus menyinkronkan utas?

@asimshankar Apakah sudah ada cara dari pengikatan Java tensorflow untuk mengambil informasi dari graphDef (dibangun dari file .pb grafik pada disk) seperti daftar node, format input dan output atau itu fitur yang masuk? Terima kasih!

@asimshankar Saya tidak yakin untuk memahami apa yang hilang untuk melakukan pelatihan dengan TF Java. Apakah ini masalah perpustakaan numerik (numpy hilang)? Maksud saya jika Anda tidak menarik dalam dataviz TensorBoard, tetapi hanya pelatihan, menggunakan perpustakaan numerik Java asli, mengapa menggunakan python hanya untuk pelatihan (seperti yang Anda sarankan tentang kelas Estimator )?

Terima kasih.

Bagaimana keadaan model pelatihan di Jawa? Saya telah berpikir untuk menulis plugin ImageJ (suite analisis gambar populer dan gratis) untuk menerapkan pendekatan seperti https://arxiv.org/pdf/1505.04597.pdf (baru-baru ini sangat populer dalam segmentasi gambar untuk pelacakan sel dan aplikasi biomedis). Saya pikir akan berguna untuk menyediakan berbagai model pra-terlatih dan memungkinkan pengguna untuk memperbaiki ini untuk kasus penggunaan khusus mereka. Saya telah melihat ke DL4J untuk tujuan ini. Apakah ada rencana konkret untuk memungkinkan pemasangan di TF Java binding?

@bergwerf : Pelatihan di Jawa tentu saja mungkin, jika tidak terlalu nyaman.
Anda dapat menemukan sampel di https://github.com/tensorflow/models/tree/master/samples/languages/Java/training

(Juga, saya yakin Anda sadar, tetapi lihat juga https://imagej.net/TensorFlow)

Luar biasa! Informasi saya harus sudah ketinggalan zaman ;-). Saya pikir saya telah membaca
di suatu tempat Java API hanya dimaksudkan untuk memprediksi dengan pra-terlatih
model. Saya akan melihat ke dalam contoh.

Pada Rabu, 28 Maret 2018, 22:01 Asim Shankar [email protected] menulis:

@bergwerf https://github.com/bergwerf : Pelatihan di Jawa tentu saja
mungkin, jika tidak terlalu nyaman.
Anda dapat menemukan sampel di
https://github.com/tensorflow/models/tree/master/samples/languages/Java/training

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/tensorflow/tensorflow/issues/5#issuecomment-377015867 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEQJ1UD9-xACQAII5996ees_UFJ_NzL-ks5ti-wSgaJpZM4Getd8
.

@asimshankar itu luar biasa 👍 , saya akan menambahkan repo saya https://github.com/loretoparisi/tensorflow-java