Issue 1:
The segment reduction ops are currently inconsistent, they include different ops for sorted/unsorted/ and sparse/dense tensors.

I guess it would make sense to provide the same reduction ops for these - I'd be happy to work on this and build on nikste's work.

For similar previous issues @andydavis1, @drpngx were responsible for reviewing, so I link you here.

Things to possibly consider:

Replace the sorted segment options by the more general unsorted options. I did a quick, non-extensive benchmark for unsorted_segment_max vs segment_max, the processing time is about the same (with the unsorted op even being a bit faster sometimes).

The drawback would be, that num_segments needs to be specified or needs to be computed before the reduction.

Include the feature request "Extend tf.unsorted_segment_sum to allow 'rejecting' entries" #478

Address the ToDo in UnsortedSegmentMax: // todo: Remove duplicate code in UnsortedSegmentSumFunctor and UnsortedSegmentMaxFunctor.

To sum up, I'd suggest to replace and extend the currently provided functions

tf.segment_sum(data, segment_ids, name=None)
tf.segment_prod(data, segment_ids, name=None)
tf.segment_min(data, segment_ids, name=None)
tf.segment_max(data, segment_ids, name=None)
tf.segment_mean(data, segment_ids, name=None)
tf.unsorted_segment_sum(data, segment_ids, num_segments, name=None)
tf.sparse_segment_sum(data, indices, segment_ids, name=None)
tf.sparse_segment_mean(data, indices, segment_ids, name=None)
tf.sparse_segment_sqrt_n(data, indices, segment_ids, name=None)

with

# all dense/sparse ops support unsorted segments
tf.segment_sum(data, segment_ids, num_segements=None, name=None)
tf.segment_prod(data, segment_ids, num_segements=None, name=None)
tf.segment_min(data, segment_ids, num_segements=None, name=None)
tf.segment_max(data, segment_ids, num_segements=None, name=None)
tf.segment_mean(data, segment_ids, num_segements=None, name=None)
tf.segment_sqrt_n(data, segment_ids, num_segements=None, name=None) # new

tf.sparse_segment_sum(data, indices, segment_ids, name=None)
tf.sparse_segment_prod(data, indices, segment_ids, name=None) # new
tf.sparse_segment_min(data, indices, segment_ids, name=None) # new
tf.sparse_segment_max(data, indices, segment_ids, name=None) # new
tf.sparse_segment_mean(data, indices, segment_ids, name=None)
tf.sparse_segment_sqrt_n(data, indices, segment_ids, name=None)

(Or tf.unsorted_segment_reduce_op instead of tf.segement_reduceop to not break backward compability)

Issue 2:
System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04

Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device: n/a

TensorFlow installed from (source or binary): binary

TensorFlow version (use command below): v1.9.0-rc0-35-g17d6639b55 1.9.0-rc1

Python version: 3.5.2

Bazel version (if compiling from source): n/a

GCC/Compiler version (if compiling from source): n/a

CUDA/cuDNN version: n/a

GPU model and memory: n/a

Exact command to reproduce: n/a

Describe the problem

I wanted to call attention to an issue and a PR on the keras-team/keras project so that TF could track and integrate with TF-core Keras. I believe these issues are of high importance to the community; for my project at least they are just short of critical. In summary:

PR: Keras Callbacks should be able to access predictions made during training in on_batch_end() and on_epoch_end() to eliminate expensive duplicate calls to predict() in Callbacks that require prediction results -- keras-team/keras#10513

Writing a Keras metric should not require a graph -- keras-team/keras#4506 (comment)

The reason these are related is because a viable solution to the second issue depends on the first; in particular, if you wanted to write a "fancy" metric function that did calcs in Python, for example, you could leverage already-made predictions from the API described in issue 1 and circumvent having to predict() all over again, which is prohibitively expensive in all but the simplest models.