In Dr. Dobb's Python-URL I came upon this thread proposing a change to Python (either syntax or builtin) to facilitate this general pattern:
class Foo(object): def __init__(self, a, b=5, c=None): self.a = a self.b = b self.c = c or {}
There's two proposals, basically. One is syntax:
class Foo(object):
- def __init__(self, .a, .b=5, c=None):
- self.c = c or {}
By putting (that very little character) . in front of an argument, you imply that it should be assigned to self. The other builtin is:
class Foo(object): def __init__(self, a, b=5, c=None): adapt_init_args(self, locals()) # reassignment fixup: self.c = c or {}
Using frame hacks, you could easily allow adapt_init_args() to work without arguments.
There's lots of ways to do this. For instance, I regularly use:
class Foo(object): def __init__(self, **kw): for name, value in kw.items(): setattr(self, name, value)
But that can allow typos too easily. So sometimes I set defaults as class variables, and test for hasattr(), and raise an error if an extraneous variable is found. It also doesn't allow for positional arguments. Or mutable defaults, since those defaults end up as class variables, and unwittingly mutating values for all instances will mess you up.
This is one those There's More Than One Way To Do It cases. Though I'm not excited about the syntax proposal, it's addresses a real problem. Clever hacks don't cut it. There's lots of them. They work differently. You can't necessarily recognize them each right away. They each have flaws -- some quite significant.
So far the only hack that seems decent to me (a hack that does not exist to my knowledge) would be a decorator that works with the _ prefixes on variables (using something like **_kw to replicate the setattr thing I show above). This should be a clever decorator because it needs to:
A decorator for this is okay -- better than most of the things people have been proposing -- but not terribly pleasing. It's magical, but a kind of hidden and mysterious magic. It bridges an implementation and an external interface, but if you don't know how the decorator works then you won't understand the disconnect.
I'm not sure what syntax I'd want. I'm not sure if syntax is feasible here -- there's limited room in a function signature. But I think people who say that syntax is always the wrong answer, or that this isn't an issue, are just too set in their ways to see the issue. Python's strength -- particularly compared to the other dynamic languages -- is in the consistency with which people use it. This is how Python is different from Lisp and Ruby (and actually how it is similar to Smalltalk). I think many people (especially the perennial skeptics in comp.lang.python) underappreciate this.
What I don't like about .syntax is that the comma and the dot overlap visually. OTOH, something like this:
class Foo: def bar(self, self.baz, self.xyzzy): passis what I'd like to see in Python.
# Baczek
Hmmm, this seems to make sense (so much that I actually went and tried it out to see if it would work... which it didn't of course ;-)
# polaar
I took a crack at writing a simple "autoinit" decorator. It's not "complete" in that it doesn't do all the minor tasks like setting the wrapping functions name, doc string, etc. nor does it preserve the function signature of the wrapped function, but it does do everything else. One minor "issue" is that it will assign every keyword argument to the instance, not just declared ones:
from itertools import izip def autoinit(f): # get arg names minus 'self' argnames = f.func_code.co_varnames[1:f.func_code.co_argcount] # get argument defaults argdefs = f.func_defaults # build defaults dictionary if argdefs: defdict = dict(izip(argnames[-len(argdefs):], argdefs)) else: defdict = {} def newf(self, *args, **kwargs): selfdict = self.__dict__ # start with argument defaults selfdict.update(defdict) # add positional arguments selfdict.update(izip(argnames, args)) # add keyword arguments selfdict.update(kwargs) # call the original function return f(self, *args, **kwargs) return newf# Shahms King
That consistency is both a strength and a weakness. It doesn't have only good points. Couldn't the argument be be made the other way around? That people who think it's very good are just caught up in they're ways to realize the expressivity and power that comes from more freedom?
Actually Lisp has a much smaller core than Python. I imagine you're talking about Common Lisp. But consider Scheme for example.
# Mike
Yes, I was thinking of Common Lisp. Or any of the Lisps that have macros, really. Though really a small core is exactly the thing that leads to TMTOWTDI -- it's based on the idea that it is okay if things are simply possible, regardless of whether they are easy, obvious, readable, or reproduceable; that a small core is a virtue in itself, often ignoring the size of the working set of functionality a programmer must use to actually get anything done. Common Lisp includes all that functionality in duplicate in its core, while Scheme includes none of that functionality. Both end up in the same place -- TMTOWTDI. For example, there are many object systems for Scheme. And there's many ways to bind a variable in Common Lisp. Neither place great value in consistency for practical programs.
And maybe Smalltalk isn't a good counterexample -- as a language it's more like Lisp than Python. But culturally it's more like Python in this regard, with a rich library and set of conventions.
Re: expressivity; in this case, there is a fine edge. If you try to handle every case, you've recreated all of Python in a set of weird rules that can be embedded in a function signature. That's bad. This is something frameworks often get wrong -- they write piles of code to save framework users a couple if statements or a loop, confusing everyone in the process. Certainly __init__, a procedure which can do anything it wants with the object, shouldn't and can't go away. But really, the choice here isn't between expressivity/freedom and TOOWTDI. The status quo has simplicity and transparency on its side, while a change has conciseness and uniformity on its side. This isn't a question of consistency vs. expressivity.
# Ian Bicking
These ideas about monkeying with __init__ are Just Plain Wrong, because __init__ is the source of the problem in the first place. The existence of __init__ is largely a hack to work around the absence of descriptors in earlier versions of Python, so compounding the hack with more hackery is a bad idea.
If you are defining attributes, the sane place to do so is in the class body, not in an __init__ signature. Your "class Foo" is the One Obvious Way to do it, defining attributes using default values in the class, or properties, or other kinds of descriptors. But don't define __init__ methods in your subclasses, just define the attributes. This is the One True Way to solve this problem, because trying to "fix" __init__ will get you nowhere: the very idea of __init__ is what's broken. Pinning wings on the pig won't make it fly.
All of the problems that make you discard this solution are actually quite trivial to fix, compared to trying to "fix" __init__. For example, mutable defaults are easily handled with a descriptor that creates a new mutable value when its __get__ is called and no value is defined. In PEAK, for example, bar = binding.Make(list) defines a bar property that will be a new list object when first accessed, unless you set it to something else via the constructor or some other way. Such descriptors are easily created, and far less magical than stack-tampering decorators.
Similarly, positional arguments are also easy. You should never have more than a few of those anyway, so just write an __init__ that calls the base __init__ with them as keywords. Again, it's much simpler and more straightforward than the alternatives.
I wish that the object base class provided this behavior; it sure would make it the "obvious" way to do things. Unfortunately, I don't think it can be added without breaking code that works now, so it likely won't be until Python 3.0 that it'll appear, assuming that Guido agrees this is the One Obvious Way. (Jython already believes this, and interprets keyword arguments to Java object constructors as a request to set properties on the created object.)
I'm not sure exactly what you are proposing or backing; if you want to, say, follow this up with a blog post of your own on the issue, I'm sure that would be interesting.
Anyway, I think what you mean is that the default __init__ should always act like this:
class Foo(object): def __init__(self, **kw): for name, value in kw.items(): setattr(self, name, value)And, of course, self.__dict__.update(kw) is a horrible hack that bypasses descriptors and shouldn't be seen as a decent way to implement any of this (I note this because it's often offered up -- an example of one of the Bad Ideas about how to deal with this problem).
Of course, there are many places where you really need clever descriptors to make this work right, if you propose that it replace all of __init__ (at least all the attribute-setup portion of that function -- it's overboard to say that all possible initialization code could be removed).
For an instance of where this becomes complicated, I was just writing some code today:
class Site(object): def __init__(self, htdocs, conf_dir=None): self.htdocs = htdocs self.conf_dir = conf_dir or htdocsI.e., conf_dir defaults to htdocs, and of course you can't resolve that default in the class definition. So you need a special decorator that forwards .conf_dir to .htdocs when you haven't given an explicit conf_dir. This is slightly different semantics, but in most cases it's equivalent. I'd actually be surprised if PEAK didn't already have some binding option to do this. But some patterns of initialization won't exist. So when that happens you'd have to write something like this:
class forwarding_attr(object): def __init__(self, forwarded): # I want a positional argument here, # so I need __init__ anyway! self.forwarded = forwarded self.private_attr = forwarded + '_explicit' def __get__(self, obj, type=None): return getattr(obj, self.private_attr, getattr(obj, self.forwarded)) def __set__(self, obj, value): setattr(obj, self.private_attr, value) class Site(object): htdocs = Attr() conf_dir = forwarding_attr('htdocs')The private_attr thing is dumb, and I wrote about that before -- I think PEAK has an answer to that, but there's no convention for it, and it regularly annoys me.
Anyway, I'll know what forwarding_attr is. And I can describe it easily enough in a docstring or whatever. But it's not transparent; I have a hard time justifying how it is better than self.conf_dir = conf_dir or htdocs. It's not even significantly shorter, though it is declarative and introspectable.
I think this sort of thing would appeal to me if I committed to the style. But I have a hard time committing. I also have a hard time asking other people to commit to this style -- and I am highly reluctant to commit to something that I'm not willing to advocate that everyone use. And everyone has to understand this, because it's not a bit of implementation you can encapsulate -- it's a whole different way of thinking about object instantiation, and effects the language significantly. So, these are the reasons that high-level declarative extensions to Python worry me, even though I understand the motivation, and I can certainly see how it could be useful.
# Ian Bicking
"""This is slightly different semantics, but in most cases it's equivalent. I'd actually be surprised if PEAK didn't already have some binding option to do this."""
Yep. conf_dir = binding.Obtain('htdocs') is the simplest way to do what you described in PEAK; if conf_dir is used without being set, it will take on the value in htdocs at the moment it was looked up (and stays set to it thereafter, unless changed). There's no private_attr because PEAK is smart enough to be able to ensure that the descriptors know their attribute names. If conf_dir is set directly or via the constructor, then it won't try to "obtain" the htdocs attribute.
"""it's overboard to say that all possible initialization code could be removed"""Maybe. Maybe not. Fewer than 10% of PEAK's classes even have an __init__ method, and most of those are in very "low level" classes. If you look at "component" and "entity" classes only (high-level constructs used to model services or business objects), you'll find almost no __init__ methods at all. (And I only say "almost" so that I won't look silly if somebody happens to find one or two out of PEAK's 2200+ classes.)
"""it's a whole different way of thinking about object instantiation, and effects the language significantly. So, these are the reasons that high-level declarative extensions to Python worry me, even though I understand the motivation, and I can certainly see how it could be useful."""I can understand that. In a sense, something like this "wants" to be part of the language; you should really be able to do the equivalents of binding.Make, binding.Obtain, and binding.Delegate with syntax or builtins. But, if what you're looking for is the best technical solution to the problem, PEAK's descriptor patterns are the way to go, whether you use PEAK's implementation or not. If you're trying to deal with the educational/political issues, then you should just write the boilerplate __init__ methods and quit trying to "fix" them, because the fixes will just have a different set of educational/political issues, in addition to being a technically inferior solution.
>>> class Foo(object): ... def __init__(self, a, b=10): ... for name, value in locals().items(): ... setattr(self, name, value) ... >>> foo = Foo(1) >>> foo.__dict__ {'a': 1, 'self': <__main__.Foo object at 0xb7d7396c>, 'b': 10}
>>> class Foo(object): ... def __init__(self, a, b=10): ... for name, value in locals().items(): ... setattr(self, name, value) ... >>> foo = Foo(1) >>> foo.__dict__ {'a': 1, 'self': <__main__.Foo object at 0xb7d7396c>, 'b': 10}


-- Copyright 2016 TensorFlow authors. -- -- Licensed under the Apache License, Version 2.0 (the "License"); -- you may not use this file except in compliance with the License. -- You may obtain a copy of the License at -- -- http://www.apache.org/licenses/LICENSE-2.0 -- -- Unless required by applicable law or agreed to in writing, software -- distributed under the License is distributed on an "AS IS" BASIS, -- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -- See the License for the specific language governing permissions and -- limitations under the License. {-# LANGUAGE ExplicitNamespaces #-} -- | The core functionality of TensorFlow. -- -- Unless you are defining ops, you do not need to import other modules from -- this package. -- -- Basic ops are provided in the tensorflow-ops and tensorflow-core-ops -- packages. module TensorFlow.Core ( -- * Session Session , Options , sessionConfig , sessionTarget , sessionTracer , runSession , runSessionWithOptions -- ** Building graphs , build , buildAnd , buildWithSummary -- ** Running graphs , Fetchable , Scalar(..) , Nodes , run , run_ , Feed , feed , runWithFeeds , runWithFeeds_ -- ** Async , asyncProdNodes -- * Build , Build , BuildT , render , asGraphDef , addGraphDef -- * Tensor , ControlNode , Tensor , Value , Ref , TensorKind(..) , tensorAttr , value , tensorFromName -- ** Element types , TensorData , TensorType(decodeTensorData, encodeTensorData) , Shape(..) , OneOf , type (/=) -- * Op combinators , colocateWith , Device(..) , withDevice , withNameScope , named -- ** Dependencies , withControlDependencies , group -- ** Misc , identity , noOp ) where import TensorFlow.Build import TensorFlow.ControlFlow import TensorFlow.Nodes import TensorFlow.Output import TensorFlow.Session import TensorFlow.Tensor import TensorFlow.Types


Demo Block
Hello Girl! CSS Learning
Hello Girl2! CSS Learning
Demo Inline
Hello Girl! CSS Learning
Hello Girl2! CSS Learning
Demo Inline - block
Hello Girl! CSS Learning
Hello Girl2! CSS Learning
Hello Girl2! vertical-aline: bottom
Hello Girl2! CSS Learning
Demo Inline - flex
Hello Girl! CSS Learning
Hello Girl2! CSS Learning


Please provide the tender publication info. Then you can create tenders under this publication.
Registration is required for the contract of cost exceeding Rs.5,000,000 as per the Public Contract Act No.03 of 1987
You can create new tender by filling below form under the same publication.
Fill in all steps for completing the process.
{{item.label}}
{{tenderItems.items.length}} item(s) currently added
No items currently added


In this project, you'll define and train a DCGAN on a dataset of faces. Your goal is to get a generator network to generate new images of faces that look as realistic as possible!
The project will be broken down into a series of tasks from loading in data to defining and training adversarial networks.
You'll be using the CelebFaces Attributes Dataset (CelebA) to train your adversarial networks.
This dataset is more complex than the number datasets (like MNIST or SVHN) you've been working with, and so, you should prepare to define deeper networks and train them for a longer time to get good results. It is suggested that you utilize a GPU for training.
Since the project's main focus is on building the GANs, we've done some of the pre-processing for you. Each of the CelebA images has been cropped to remove parts of the image that don't include a face, then resized down to 64x64x3 NumPy images. Some sample data is show below.
If you are working locally, you can download this data by clicking here
This is a zip file that you'll need to extract in the home directory of this notebook for further loading and processing. After extracting the data, you should be left with a directory of data processed_celeba_small/
!wget -c "https://s3.amazonaws.com/video.udacity-data.com/topher/2018/November/5be7eb6f_processed-celeba-small/processed-celeba-small.zip"
# can comment out after executing
!unzip -qq processed-celeba-small.zip
!wget -c https://raw.githubusercontent.com/sumanyurosha/deep-learning-v2-pytorch/master/project-face-generation/problem_unittests.py
data_dir = 'processed_celeba_small/'
"""
DON'T MODIFY ANYTHING IN THIS CELL
"""
import pickle as pkl
import matplotlib.pyplot as plt
import numpy as np
import problem_unittests as tests
#import helper
%matplotlib inline
The CelebA dataset contains over 200,000 celebrity images with annotations. Since you're going to be generating faces, you won't need the annotations, you'll only need the images. Note that these are color images with 3 color channels (RGB)#RGB_Images) each.
Since the project's main focus is on building the GANs, we've done some of the pre-processing for you. Each of the CelebA images has been cropped to remove parts of the image that don't include a face, then resized down to 64x64x3 NumPy images. This pre-processed dataset is a smaller subset of the very large CelebA data.
There are a few other steps that you'll need to transform this data and create a DataLoader.
get_dataloader
function, such that it satisfies these requirements:¶image_size x image_size
in the x and y dimension.To create a dataset given a directory of images, it's recommended that you use PyTorch's ImageFolder wrapper, with a root directory processed_celeba_small/
and data transformation passed in.
# necessary imports
import torch
from torchvision import datasets
from torchvision import transforms
def get_dataloader(batch_size, image_size, data_dir='processed_celeba_small/'):
"""
Batch the neural network data using DataLoader
:param batch_size: The size of each batch; the number of images in a batch
:param img_size: The square size of the image data (x, y)
:param data_dir: Directory where image data is located
:return: DataLoader with batched data
"""
# TODO: Implement function and return a dataloader
transform = transforms.Compose([transforms.Resize(size=(image_size, image_size)),
transforms.ToTensor()])
dataset = datasets.ImageFolder(data_dir, transform=transform)
dataloader = torch.utils.data.DataLoader(dataset, batch_size, shuffle=True)
return dataloader
celeba_train_loader
with appropriate hyperparameters.¶Call the above function and create a dataloader to view images.
batch_size
parameterimage_size
must be 32
. Resizing the data to a smaller size will make for faster training, while still creating convincing images of faces!#  You should seen square images of somewhat-centered faces.
Note: You'll need to convert the Tensor images into a NumPy type and transpose the dimensions to correctly display an image, suggested imshow
code is below, but it may not be perfect.
# helper display function
def imshow(img):
npimg = img.numpy()
plt.imshow(np.transpose(npimg, (1, 2, 0)))
"""
DON'T MODIFY ANYTHING IN THIS CELL THAT IS BELOW THIS LINE
"""
# obtain one batch of training images
dataiter = iter(celeba_train_loader)
images, _ = dataiter.next() # _ for no labels
# plot the images in the batch, along with the corresponding labels
fig = plt.figure(figsize=(20, 4))
plot_size=20
for idx in np.arange(plot_size):
ax = fig.add_subplot(2, plot_size/2, idx+1, xticks=[], yticks=[])
imshow(images[idx])
You need to do a bit of pre-processing; you know that the output of a tanh
activated generator will contain pixel values in a range from -1 to 1, and so, we need to rescale our training images to a range of -1 to 1. (Right now, they are in a range from 0-1.)
# TODO: Complete the scale function
def scale(x, feature_range=(-1, 1)):
''' Scale takes in an image x and returns that image, scaled
with a feature_range of pixel values from -1 to 1.
This function assumes that the input x is already scaled from 0-1.'''
# assume x is scaled to (0, 1)
# scale to feature_range and return scaled x
min, max = feature_range
x = x * (max - min) + min
return x
"""
DON'T MODIFY ANYTHING IN THIS CELL THAT IS BELOW THIS LINE
"""
# check scaled range
# should be close to -1 to 1
img = images[0]
scaled_img = scale(img)
print('Min: ', scaled_img.min())
print('Max: ', scaled_img.max())
A GAN is comprised of two adversarial networks, a discriminator and a generator.
Your first task will be to define the discriminator. This is a convolutional classifier like you've built before, only without any maxpooling layers. To deal with this complex data, it's suggested you use a deep network with normalization. You are also allowed to create any helper functions that may be useful.
import torch.nn as nn
import torch.nn.functional as F
def conv(in_channels, out_channels, kernel_size, stride=2, padding=1, batch_norm=True):
layers = []
# creating a convolution layer
conv_layer = nn.Conv2d(in_channels, out_channels, kernel_size, stride, padding, bias=False)
layers.append(conv_layer)
# adding batch normalisation only if batch_norm is True
if batch_norm:
layers.append(nn.BatchNorm2d(out_channels))
# using sequential container
return nn.Sequential(*layers)
class Discriminator(nn.Module):
def __init__(self, conv_dim):
"""
Initialize the Discriminator Module
:param conv_dim: The depth of the first convolutional layer
"""
super(Discriminator, self).__init__()
self.conv_dim = conv_dim
# complete init function
# 32x32x3 input
self.conv1 = conv(3, conv_dim, 3, batch_norm=False) # not using batch_norm is first layer
# 16x16x32 output
self.conv2 = conv(conv_dim, conv_dim*2, 3)
# 8X8X64 output
self.conv3 = conv(conv_dim*2, conv_dim*4, 3)
# 4x4x128 output
self.conv4 = conv(conv_dim*4, conv_dim*8, 3)
# 2x2x256 output
# fully-connected layer
self.fc = nn.Linear(conv_dim*8*2*2, 1)
def forward(self, x):
"""
Forward propagation of the neural network
:param x: The input to the neural network
:return: Discriminator logits; the output of the neural network
"""
# define feedforward behavior
# passing the input through a series of convolution layers
# with leaky_relu activation
out = F.leaky_relu(self.conv1(x), 0.2)
out = F.leaky_relu(self.conv2(out), 0.2)
out = F.leaky_relu(self.conv3(out), 0.2)
out = F.leaky_relu(self.conv4(out), 0.2)
# flatten the input
out = out.view(-1, self.conv_dim*8*2*2)
# passing through the final, fully-connected layer
out = self.fc(out)
return out
"""
DON'T MODIFY ANYTHING IN THIS CELL THAT IS BELOW THIS LINE
"""
tests.test_discriminator(Discriminator)
The generator should upsample an input and generate a new image of the same size as our training data 32x32x3
. This should be mostly transpose convolutional layers with normalization applied to the outputs.
z_size
32x32x3
def deconv(in_channels, out_channels, kernel_size, stride=2, padding=1, batch_norm=True):
layers = []
de_conv = nn.ConvTranspose2d(in_channels, out_channels, kernel_size, stride,
padding, bias=False)
# adding transpose convolution layer
layers.append(de_conv)
if batch_norm:
layers.append(nn.BatchNorm2d(out_channels))
# returning the layers in a sequential container
return nn.Sequential(*layers)
class Generator(nn.Module):
def __init__(self, z_size, conv_dim):
"""
Initialize the Generator Module
:param z_size: The length of the input latent vector, z
:param conv_dim: The depth of the inputs to the *last* transpose convolutional layer
"""
super(Generator, self).__init__()
self.conv_dim = conv_dim
# complete init function
# creating the expected shape for the network from latent vector z
self.fc = nn.Linear(z_size, conv_dim*8*2*2)
# 256x2x2 input
self.t_conv1 = deconv(conv_dim*8, conv_dim*4, 4)
# 128x4x4 output
self.t_conv2 = deconv(conv_dim*4, conv_dim*2, 4)
# 64x8x8 output
self.t_conv3 = deconv(conv_dim*2, conv_dim, 4)
# 32x16x16 output
self.t_conv4 = deconv(conv_dim, 3, 4, batch_norm=False)
# 3x32x32 output
def forward(self, x):
"""
Forward propagation of the neural network
:param x: The input to the neural network
:return: A 32x32x3 Tensor image as output
"""
# define feedforward behavior
#
out = self.fc(x)
# reshaping it
out = out.view(-1, self.conv_dim*8, 2, 2)
# passing through de_conv layers
out = F.relu(self.t_conv1(out))
out = F.relu(self.t_conv2(out))
out = F.relu(self.t_conv3(out))
out = F.tanh(self.t_conv4(out))
return out
"""
DON'T MODIFY ANYTHING IN THIS CELL THAT IS BELOW THIS LINE
"""
tests.test_generator(Generator)
To help your models converge, you should initialize the weights of the convolutional and linear layers in your model. From reading the original DCGAN paper, they say:
All weights were initialized from a zero-centered Normal distribution with standard deviation 0.02.
So, your next task will be to define a weight initialization function that does just this!
You can refer back to the lesson on weight initialization or even consult existing model code, such as that from the networks.py
file in CycleGAN Github repository to help you complete this function.
import random
from torch.nn import init
def weights_init_normal(m):
"""
Applies initial weights to certain layers in a model .
The weights are taken from a normal distribution
with mean = 0, std dev = 0.02.
:param m: A module or layer in a network
"""
# classname will be something like:
# `Conv`, `BatchNorm2d`, `Linear`, etc.
classname = m.__class__.__name__
# TODO: Apply initial weights to convolutional and linear layers
if hasattr(m, 'weight'):
init.normal_(m.weight.data, 0.0, 0.02)
Define your models' hyperparameters and instantiate the discriminator and generator from the classes defined above. Make sure you've passed in the correct input arguments.
 Here, we'll set this as a boolean variable train_on_gpu
. Later, you'll be responsible for making sure that
- Models,
- Model inputs, and
- Loss function arguments
Are moved to GPU, where appropriate.
"""
DON'T MODIFY ANYTHING IN THIS CELL
"""
import torch
# Check for a GPU
train_on_gpu = torch.cuda.is_available()
if not train_on_gpu:
print('No GPU found. Please use a GPU to train your neural network.')
else:
print('Training on GPU!')
Now we need to calculate the losses for both types of adversarial networks.
- For the discriminator, the total loss is the sum of the losses for real and fake images,
d_loss = d_real_loss + d_fake_loss
.- Remember that we want the discriminator to output 1 for real images and 0 for fake images, so we need to set up the losses to reflect that.
The generator loss will look similar only with flipped labels. The generator's goal is to get the discriminator to think its generated images are real.
You may choose to use either cross entropy or a least squares error loss to complete the following real_loss
and fake_loss
functions.
def real_loss(D_out):
'''Calculates how close discriminator outputs are to being real.
param, D_out: discriminator logits
return: real loss'''
batch_size = D_out.size(0)
labels = torch.ones(batch_size)
if train_on_gpu:
labels = labels.cuda()
criterion = nn.BCEWithLogitsLoss()
loss = criterion(D_out.squeeze(), labels)
return loss
def fake_loss(D_out):
'''Calculates how close discriminator outputs are to being fake.
param, D_out: discriminator logits
return: fake loss'''
batch_size = D_out.size(0)
labels = torch.zeros(batch_size)
if train_on_gpu:
labels = labels.cuda()
criterion = nn.BCEWithLogitsLoss()
loss = criterion(D_out.squeeze(), labels)
return loss
import torch.optim as optim
lr = 0.0002
beta1 = 0.5
beta2 = 0.999
# Create optimizers for the discriminator D and generator G
d_optimizer = optim.Adam(D.parameters(), lr, [beta1, beta2])
g_optimizer = optim.Adam(G.parameters(), lr, [beta1, beta2])
Training will involve alternating between training the discriminator and the generator. You'll use your functions real_loss
and fake_loss
to help you calculate the discriminator losses.
You've been given some code to print out some loss statistics and save some generated "fake" samples.
Keep in mind that, if you've moved your models to GPU, you'll also have to move any model inputs to GPU.
def train(D, G, n_epochs, print_every=50):
'''Trains adversarial networks for some number of epochs
param, D: the discriminator network
param, G: the generator network
param, n_epochs: number of epochs to train for
param, print_every: when to print and record the models' losses
return: D and G losses'''
# move models to GPU
if train_on_gpu:
D.cuda()
G.cuda()
# keep track of loss and generated, "fake" samples
samples = []
losses = []
# Get some fixed data for sampling. These are images that are held
# constant throughout training, and allow us to inspect the model's performance
sample_size=16
fixed_z = np.random.uniform(-1, 1, size=(sample_size, z_size))
fixed_z = torch.from_numpy(fixed_z).float()
# move z to GPU if available
if train_on_gpu:
fixed_z = fixed_z.cuda()
# epoch training loop
for epoch in range(n_epochs):
# batch training loop
for batch_i, (real_images, _) in enumerate(celeba_train_loader):
batch_size = real_images.size(0)
real_images = scale(real_images)
# real_images = torch.from_numpy(real_images).float()
# moving to gpu, if available!
if train_on_gpu:
real_images = real_images.cuda()
# ===============================================
# YOUR CODE HERE: TRAIN THE NETWORKS
# ===============================================
# 1. Train the discriminator on real and fake images
# clearing the gradients
d_optimizer.zero_grad()
# training the generator with real images
D_real = D(real_images)
d_real_loss = real_loss(D_real)
# training the generator with fake images
z = np.random.uniform(-1., 1., size=(batch_size, z_size))
z = torch.from_numpy(z).float()
if train_on_gpu:
z = z.cuda()
fake_images = G(z)
D_fake = D(fake_images)
d_fake_loss = fake_loss(D_fake)
# adding loss and performing backprop
d_loss = d_real_loss + d_fake_loss
d_loss.backward()
d_optimizer.step()
# 2. Train the generator with an adversarial loss
# clearing accumulated gradients
g_optimizer.zero_grad()
# creating latent vector z
z = np.random.uniform(-1., 1., (batch_size, z_size))
z = torch.from_numpy(z).float()
# moving to gpu, if available!
if train_on_gpu:
z = z.cuda()
# generating fake_images
fake_images = G(z)
# compute discriminator loss on fake images
D_fake = D(fake_images)
# calculating loss and performing backprop
g_loss = real_loss(D_fake)
g_loss.backward()
g_optimizer.step()
# ===============================================
# END OF YOUR CODE
# ===============================================
# Print some loss stats
if batch_i % print_every == 0:
# append discriminator loss and generator loss
losses.append((d_loss.item(), g_loss.item()))
# print discriminator and generator loss
print('Epoch [{:5d}/{:5d}] | d_loss: {:6.4f} | g_loss: {:6.4f}'.format(
epoch+1, n_epochs, d_loss.item(), g_loss.item()))
## AFTER EACH EPOCH##
# this code assumes your generator is named G, feel free to change the name
# generate and save sample, fake images
G.eval() # for generating samples
samples_z = G(fixed_z)
samples.append(samples_z)
G.train() # back to training mode
# Save training generator samples
with open('train_samples.pkl', 'wb') as f:
pkl.dump(samples, f)
# finally return losses
return losses
Set your number of training epochs and train your GAN!
# set number of epochs
n_epochs = 25
"""
DON'T MODIFY ANYTHING IN THIS CELL
"""
# call training function
losses = train(D, G, n_epochs=n_epochs, print_every=300)
Plot the training losses for the generator and discriminator, recorded after each epoch.
fig, ax = plt.subplots()
losses = np.array(losses)
plt.plot(losses.T[0], label='Discriminator', alpha=0.5)
plt.plot(losses.T[1], label='Generator', alpha=0.5)
plt.title("Training Losses")
plt.legend()
View samples of images from the generator, and answer a question about the strengths and weaknesses of your trained models.
# helper function for viewing a list of passed in sample images
def view_samples(epoch, samples):
fig, axes = plt.subplots(figsize=(16,4), nrows=2, ncols=8, sharey=True, sharex=True)
for ax, img in zip(axes.flatten(), samples[epoch]):
img = img.detach().cpu().numpy()
img = np.transpose(img, (1, 2, 0))
img = ((img + 1)*255 / (2)).astype(np.uint8)
ax.xaxis.set_visible(False)
ax.yaxis.set_visible(False)
im = ax.imshow(img.reshape((32,32,3)))
# Load samples from generator, taken while training
with open('train_samples.pkl', 'rb') as f:
samples = pkl.load(f)
_ = view_samples(-1, samples)
When you answer this question, consider the following factors:
Answer:
When submitting this project, make sure to run all the cells before saving the notebook. Save the notebook file as "dlnd_face_generation.ipynb" and save it as a HTML file under "File" -> "Download as". Include the "problem_unittests.py" files in your submission.


The goal of the project was to create a strategic plan for Docsuggest, a healthcare startup to understand the needs, requirements and dependencies of the patients and the doctors it catered to. Also, provide design ideas to increase the inflow of Docsuggest users and decrease their apprehension.The project team comprised of 11 Interaction Design and 3 Ph.D. students from the 2014 batch of IDC under the guidance of Prof. Anirudha Joshi. The students have formal backgrounds in engineering, architecture and design.
An Affinity map was created of important statements in the interviews with doctors, patients and other stakeholders.
References available on request.
Affinity Mapping, User, User Studies, Doctor, Patient, Healthcare, Clinics, Hospital, Emergency, Consulting, Persona, Brainstorming, Mindmapping, Care, DocSuggest, Interaction design, HCI, IDC, IITB, Indian Institute of Technology, Bombay, Mumbai


## Api Manifest Widget The Api Manifest Widget eases the scaffolding of some WebApi exposing their OpenApi schema.
## Fetch Widget The Api Manifest Widget can be exploitet to feed a `PacemWidgetFetchElement`> targeting a proper endpoint to retrieve structured data.


--- layout: single title: "Projects" permalink: /portfolio/ author_profile: true classes: wide --- {% include base_path %} {% for staff_member in site.portfolio reversed %} {{ staff_member.title }} {{ staff_member.excerpt }} {% endfor %}
{{ staff_member.excerpt }}


The Roborock E20 Robot Vacuum Can Be Yours For Under $200
Amazon has discounted the Roborock E20 robot vacuum today, and you can pick it up for just $199, ahead of Black Friday.
The normal price on the Roborock E20 is about $299, so you're saving $100 here, and you're getting a very capable robot vacuum for under $200. That's a win/win.
Whether you're buying this for yourself or for someone on your shopping list this year, it's a really great option for a robot vacuum.
Advertisement
The Roborock E20 is able to map out your home, thanks to the dual-gyro system that it has. Instead of using lasers. This is able to map out your home, so you can see in the Mi Home app where the Roborock E20 is and where it hasn't cleaned yet. You can also control it and tell it where to go.
With this robot vacuum, you're also getting some really good suction. We're looking at twice if not more, than the competitors in this price range. Making it a really great robot vacuum to use for those with pets.
There's also auto carpet boost, where the robot vacuum is able to automatically boost the suction when it realizes that it is on carpet and not laminate or hardwood floor. That makes a big difference, as carpet needs more suction anyways.
Advertisement
Finally, and this is a feature that we can't forget about. The Roborock E20 works with Amazon Alexa and Google Assistant. So you can say "Hey Google, ask Roborock to start cleaning", and you're new Roborock E20 robot vacuum will start cleaning your home. That's a pretty neat feature to say the least.
You can pick up the Roborock E20 robot vacuum cleaner from Amazon in this early Black Friday deal by clicking here. This one likely won't stay in stock long, so you're going to want to grab it before it's gone.
Advertisement


Weather Dashb
o
ard
Humidity
Wind Speed
UV Index
Today's Summary
Sunrise
Morning
Afternoon
Evening
Sunset
Night
Hourly Forecast
TEMPERATURE
FEELS LIKE
WEATHER
5-Day Forecast


--- layout: page title: about visible: true permalink: /about/ ---
Hi! I'm Gabi :)
I just graduated with a Bachelor's degree in Information Systems from USP (Universidade de Sao Paulo). It's very similar to a Computer Science major, but more focused on using CS to achieve objectives inside organizations.
I am passionate about using technology and data to make positive impact.
I spent a year in University of Pennsylvania (2013-2014), with a full scholarship from the Government of Brazil (CsF program). I loved the university, the campus, and the city!
My summer internship was at Microsoft New England. It was an incredible opportunity, and I learned a lot! Plus I could enjoy the amazing atmosphere in Boston.
After that, I worked at two education startups in Brazil: Quantica (working on Evoke) and Sílabe.
This Winter I had the pleasure of collaborating with MIT Media Lab's Dazza Greenwood, working on Projects Gallery and iAuth. I am also collaborating with Clarence Dow-Spielman and David Honick in the Life Credit System.
I'm currently looking for freelance projects to work on!
Contact me:
{% if site.owner.email %} {% endif %} {% if site.owner.github %} {% endif %} {% if site.owner.linkedin %} {% endif %} {% if site.owner.tumblr %} {% endif %} {% if site.owner.twitter %} {% endif %}Social good, data ethics, women in society (especially in tech and leadership), education, urban planning and pedestrians, homelessness... (the list is always growing.)
At USP, I was head of the Academic section of DASI. Among other things, I was in the organization committee of the Information Systems Week (SSI) in 2012 and 2013, and started the study group Sufoco. I was also a member of PET, and co-founded Conecte-SI (if you're an alumni, join us!). My undergrad research was on data mining and social networks with Prof. Luciano Digiampietri.
In high school, I went to CTI-Unesp, a vocation school where I studied Informatics. My final year project was a fluxogram interpreter called IF, and our "company" was called Else. We wrote weekly posts on our blog for the entire year :)
I also used to read and write Harry Potter fanfics, and later on, McFly fanfics. I made amazing friends in these communities. With one of them I co-founded the first Brazilian website about Twilight - which in 2007 was lots of fun!


[gecode-users] Freeze with MSVC 2015 optimized build
Filip Konvička
filip.konvicka at logis.cz
Sun Apr 3 22:12:25 CEST 2016
Hi,
I have updated to MSVC 2015 update 2, compiled the current Gecode trunk
for x64, and my testcase from the beginning of this thread still freezes
(the one from Sep 3rd 2015 - I have attached it to this mail for
convenience).
I also tried running Float::Arithmetic::Div::Sol::A and that test still
fails. For some reason 'make check' only runs a small subset of tests,
so I ran this manually like this:
$ test/test -test Float::Arithmetic::Div::Sol::A
Float::Arithmetic::Div::Sol::A -
Options: -seed 1 -test Float::Arithmetic::Div::Sol::A
Another try failed with a different seed number:
$ test/test -test Float::Arithmetic::Div
Float::Arithmetic::Div::A +++++
Float::Arithmetic::Div::B +++++
Float::Arithmetic::Div::C +++++
Float::Arithmetic::Div::Sol::A -
Options: -seed<PHONE_NUMBER> -test Float::Arithmetic::Div::Sol::A
Thanks,
Filip
> Christian,
>
> Thanks. I was referring to this September & October thread - there were
> issues with Gecode freezing on some FloatVar problems (my testcase and
> your "Float::Arithmetic::Div::C") with MSVC 2015, and you said then that
> it might be resolved by not using SSE2 (but that Guido would investigate
> more). We also identified a number of float tests that were failing on
> GCC 5 (not with GCC 4.9).
>
> I can try re-running our tests here with the current trunk to see if
> something changed - I just thought that I would ask directly whether you
> did something specific to address these issues. The failures seemed a
> bit non-deterministic...
>
> Thanks,
> Filip
>
>> MSVC2015 works for Gecode.4.4.0 since its initial release, I in fact
>> uploaded packages to the Gecode website last week. Since last week
>> (Mar 30)
>> the update 2 to MSVC 2015 finally also compiles the trunk and the
>> upcoming
>> Gecode 5.0.0.
>>
>> Don't know about GCC, though.
>>
>> Cheers
>> Christian
>>
>>
>>
>> --
>> Christian Schulte, www.gecode.org/~schulte
>> Professor of Computer Science, KTH, cschulte at kth.se
>> Expert Researcher, SICS, cschulte at sics.se
>>
>> -----Original Message-----
>> From: users-bounces at gecode.org
>> [mailto:users-bounces at gecode.org] On Behalf
>> Of Filip Konvicka
>> Sent: Friday, April 1, 2016 14:41
>> To: users at gecode.org
>> Subject: Re: [gecode-users] Freeze with MSVC 2015 optimized build
>>
>> Hi Christian,
>>
>> Have you had any chance to look into supporting gcc 5 and MSVC 2015?
>>
>> Thanks,
>> Filip
>>
>>> Hi Filip,
>>>
>>> Thanks for the information. This really looks like a gcc problem.
>>> Guido, can you reproduce this behavior?
>>>
>>> Cheers
>>> Christian
>>>
>>> --
>>> Christian Schulte, www.gecode.org/~schulte Professor of Computer
>>> Science, KTH, cschulte at kth.se Expert
>>> Researcher, SICS,
>>> cschulte at sics.se
>>>
>>> -----Original Message-----
>>> From: users-bounces at gecode.org
>>> [mailto:users-bounces at gecode.org] On
>>> Behalf Of Filip Konvicka
>>> Sent: Friday, October 2, 2015 09:58 AM
>>> To: users at gecode.org
>>> Subject: Re: [gecode-users] Freeze with MSVC 2015 optimized build
>>>
>>> Hi,
>>>
>>> We were looking a bit more into 4.4.0 on Linux where we've also hit
>>> some issues.
>>>
>>> All tests worked fine with gcc 4.9.3. However, with gcc 5.2.0 many
>>> tests failed - see the attachements for details:
>>> gecode-4.4.0-gcc-5.2.0-failed_tests.list
>>> ... list of failed tests (except two memory fails below)
>>> gecode-4.4.0-gcc-5.2.0-failed_tests.log
>>> ... log from 'test' for failed tests
>>>
>>> Two tests ran out of memory (allocated several GBs of memory before
>>> getting killed by system):
>>> Set::Branch::Sparse::3
>>> Set::Channel::Sorted
>>>
>>> gcc details:
>>> target=x86_64-linux-gnu
>>> GCC_VER=5.2.0
>>> GMP_VER=6.0.0
>>> MPFR_VER=3.1.3
>>> MPC_VER=1.0.3
>>> BINUTILS_VER=2.25
>>>
>>> It could also be a gcc bug of course, hard to tell.
>>>
>>> Thanks,
>>> Filip
>>>
>>
>>
>>
>> _______________________________________________
>> Gecode users mailing list
>> users at gecode.org
>> https://www.gecode.org/mailman/listinfo/gecode-users
>>
More information about the users
mailing list