Before, the following two models had the following behavior differences:
```
regular_sequential = Sequential([
Dense(2, activation='relu', input_shape=(3,)),
Dense(4),
]
deferred_sequential = Sequential([
Dense(2, activation='relu'),
Dense(4),
])
deferred_sequential(tf.zeros((1, 3))) # Builds the deferred sequential
```
1) The regular sequential is inspectable: its `.summary()` displays intermediate output shapes. The deferred sequential does not display output shapes.
2) The regular sequential has `inputs` and `outputs` attributes, and its intermediate layers can be used to do feature extraction (see example below), etc. The deferred sequential can't do this.
Feature extraction example:
```
model = Sequential(...)
extractor = keras.Model(inputs=model.inputs,
outputs=[layer.output for layer in model.layers])
features = extractor(data)
```
After this CL, the two models behave exactly the same once the deferred sequential has been built (whether by `__call__`ing it, by calling `fit`/`evaluate`/`predict`, or by calling `build` directly). The input shape used is the most restrictive shape compatible with all shapes previously seen by the model (i.e. the set of invariants among all shapes).
The behavior unification is not applied for TF V1, since we don't want to disrupt legacy behaviors and don't want to add new features in V1.
Note that the deferred Sequential remain different in the following cases:
- When a deferred Sequential is called with inputs of different ranks. This is impossible to express in the Functional API (of which "regular Sequential" is a wrapper). However, this is almost certainly not something that anyone is doing.
- When a deferred Sequential starts with a layer that takes multiple inputs. At this time this is something that regular Sequential models do not support. This is an invalid use case of Sequential (which should be single-input and single-output), which unfortunately some users have come to rely on. We may choose to enable it in the future (since it can be expressed with the Functional API). When we enable it we could unify the deferred Sequential behavior in this case.
- When a deferred Sequential contains a non-autographable layer that isn't marked as dynamic, or that is marked as dynamic but does not support shape inference. In that case no Functional model can be built.
PiperOrigin-RevId: 306151882
Change-Id: I4aa881af254ee845f771e375933deae664c80354
Also the original code also passes since the saving code has been updated recently.
PiperOrigin-RevId: 303782079
Change-Id: I0ec9ca84d6584aa30bb5fc3c51906afc7de4320d
Allows SaveableObjects to specify feed dict addition callbacks for object-based saving.
For now just saves get_config() with Layers. Doesn't do any loading, and there isn't quite enough information to reconstruct a Model yet (needs topology).
My plan is to get Models to the point where they can be reconstructed from object-based checkpoints (probably one more change), add in SavedModel export (assuming no dynamic control flow for now), then add this "SavedModel+Python" format to Model.save / load_model.
PiperOrigin-RevId: 196043183
