-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
List of Tensorboard Plugins and Julia Types #10
Comments
Text modeText mode seems really strong, because it will render markdown. |
I do think that supporting everything in the logger via a function based API, |
Btw, regarding text mode - I want to render textural logs as markdown-formatted text by default at some stage (in |
@c42f, @oxinabox A reflection regarding using Wrapper types to dispatch to the right back-end, as we had briefly discussed in #9
One potential issue I foresee with wrapper types is that when you compose loggers ('a la DemuxLogger or switch from Tensorboard to anything else that is not aware about those wrapper types, you start to introduce unnecessary noise. For example, I recently started composing two loggers, Tensorboard and a very basic dump-to- |
hmm yes, that is annoying. That is a very good point. The alternative is magic names. This could also be used to allow other preprocessing that you only want to do for the TensorBoardLogger, e.g. you might want to so Other loggers would just see the original |
Can you give a concrete example? I still hold to my point that wrappers are the appropriate way to add certain kinds of meaning to key value pairs (eg, "interpret this array as samples drawn from a distribution" => histogram formatting). I do think the idea of adding formatting hints such as Let's step back a bit to the general problem. At a high level I think this is a classic case of the need to separate content (the log events) from presentation (the log sinks), but we haven't figured out how to hook the presentation onto the content yet with some kind of pattern matching. Perhaps it would make sense to consider an analogy with html/css. Primary keys for pattern matching the content in that case are element_name,class,id (I think? I'm no expert whatsoever), plus nesting in the document hierarchy. To continue the analogy, at the content level maybe we have
Currently the log keys are generally used for variable names (or at least, that's how I use them) and there's very little in the way of guidelines for key naming. So one cannot expect them to be consistent between libraries in a way which would allow class-like pattern matching for formatting. But maybe they could or should be somehow? |
I agree with @c42f. Wrappers are elegant solution to the ambiguity problem. Since automatic dispatch is already in place, one can give raw data (without any wrapper) for simple datatypes such as |
I would like to start working on
@PhilipVinc @oxinabox @c42f Please let me know if |
It should handle literally every datatype. |
My current setup involves a If I use a wrapper type
then in my matrix data will be stored wrapped inside the -- |
I suggest instead of making a
then in |
Downside is that |
Thanks, it's great to have a concrete example. Certainly it's less than ideal to have the wrappers be TensorBoard-specific types because other backends then need to depend on Of course we could have some selected wrappers in stdlib Having said that, I think a more idiomatic alternative would be to put some "log key-value matching" functions into a central location (perhaps Relevant prior discussion JuliaLang/julia#29397 |
I agree with the fact that the multimedia display system is related. For example, if all wrapper types were subtypes of some
We could then define a new MIME type "TensorBoard" and put logic relevant for us there. But
|
Agreed, Possibly more relevant is Jameson's comment here: JuliaLang/julia#29397 (comment)? I didn't get around to looking at that yet. |
tensorboardX supports logging a matplotlib object directly. How hard is it to implmenet this feature here? |
Not too hard really, use |
Cool. I will give a try. |
any Plots dep should be hidden behind Requires.jl |
BTW I found the corresponding helper func in tensorboardX: https://github.com/lanpa/tensorboardX/blob/master/tensorboardX/utils.py#L2 |
Huh so we don't. I know i was hesitant before, but now I think we should add lots of deps and visualize for all of them via using Requires.jl |
The new TFBoard also supports a plane called hyperparameters (https://www.tensorflow.org/tensorboard/r2/hyperparameter_tuning_with_hparams). How should one add this? |
Interesting...
Most of the work will be figuring out how to do [4]. To do it, as the documentation is very scarce, you must go through tensor board or tensorboardX's source code. If you'd like to give this a try I'd be happy to guide you. |
I'm very new to protocol buffer. For 1. I found the folder for hyperparameters is https://github.com/tensorflow/tensorboard/tree/master/tensorboard/plugins/hparams. Which files should I try to convert? And how do one use |
Hey @xukai92 I'm sorry I never answered, but I was overwelmed in October/November from my PhD defense. Just for reference, for anyone who attempts this in the future, you should take the |
Relevant crossref to this discussion of dispatch in logging messages is the |
This is a list of all Tensorboard plugins and types that they (potentially) can accept. I want to see the overlap among different types.
<:Number
. NonReal
numbers can be preprocessed (e.g. Complex numbers);Tuple{Vector{Real},Vector{Real}}
for histogram's bin edges and bin heights;Vector
, plot a vector as an histogram by convertingdata
toTuple(1:length(data)-1, data)
;3-Arrays
are naturally 2D images;Matrix
is a grayscale 2D image;Vector
is a grayscale 1D image;String
Vector{String}
orMatrix{String}
are also rendered as lists or tables.Extra:
(This is something I need for myself and is not currently supported by TensorBoard). Eventually I would like to contribute to tensorboard a plugin to show a whole plot/curve at each iteration (very similar to what PR curve does). Tensorboard dev team is also considering this but apparently they don't have the time to work on it ATM.
Tuple{Vector{Real},Vector{Real}}
(this is different from histograms, as the length of the two vectors is the same in this case while for histograms they differ by 1).The text was updated successfully, but these errors were encountered: