Fastai v2 chat

So would you be wanting to see the results on the additional dataset during training? Or just have a way to easily evaluate after training?

After training is completely done to avoid test set bias

These are designed to work in the HTML version of the docs (, not in the notebooks.

We haven’t got much inference/prediction functionality yet - but once we do, that should be trivial, since all the data functionality is designed to handle as many datasets as you like.

1 Like

Awesome! :slight_smile: Glad to hear!

For anyone using Google Colab, run this in the first cell and everything should be set up for you to import and use

!pip3 install torch===1.2.0 torchvision===0.4.0 -f
!pip install typeguard
!git clone
%cd fastai_dev/dev

I’m slowly going further along, I’m trying to train my model with mixup (as the cnn_learner) tutorial has it, and I get a runtime error: _thnn_conv2d_forward not supported on CPUType for Half

After investigating it looks like for some reason python is not picking up to use my GPU, despite !python -c 'import torch; print(torch.cuda.is_available())' returning True…

(Training w/o mixup left me in an epoch time of 10 min/epoch, on v1 this is 1:30)

Also ds_tfms seems to have been removed from DataSource?

img_tfms = [PILFlip(0.5)]
tfms = [PILImage.create, [parent_label, Categorize()]]
dsrc = DataSource(items, tfms, filts=split_idx, ds_tfms=img_tfms)
TypeError: __init__() got an unexpected keyword argument 'ds_tfms'

Yes some things have new names - see nb 50 for up to date examples.

1 Like

I’m looking at 01_core and have a question on the example from patch_to:

def func1(x, a:bool): return x+2

Why is a:bool here and shouldn’t self, be in here?

def func1(self,x): return x+2

Or am I missing something with that a?

I’m writing up an explanation of how that decorator works and that’s the only biggest point of confusion I have at the moment.

should 01a_script be 01b_script?

So I think I figured it out and I think it is a mistake! If you look at the tests, the bool doesn’t matter. x refers to the self object of the object, in this case int.

def func(x:_T3, a:bool):
    return x+2

t = _T3(1)
test_eq(t.func(1), 3) # The one here doesn't matter
test_eq(t.func.__qualname__, '_T3.func')

We can make this a bit more sane, which is consistent with later in the core notebook:

def func(self:_T3):
    return self+2

def func2(self:_T3, a:int):
    return self+2+a

t = _T3(1)
test_eq(t.func(), 3) # Here the method takes in no arguments
test_eq(t.func.__qualname__, '_T3.func')

t2 = _T3(1)
test_eq(t2.func2(2), 5) # Here we can pass in an argument
test_eq(t2.func.__qualname__, '_T3.func')

Been reading through the core notebook today myself! It’s been a wild ride. These metaclasses are really melting my brain.


I agree with this change unless there is something happening that I’m missing with the a:bool. Pretty sure this is the correct interpretation though.

This stuff is very brain melty for sure. Just going to try understanding enough of it so I can work on adding audio capabilities.


Sounds good! I’ll go in and submit a pull request and and fix the other instances of that bool creeping in.

And yeah! Each fastai revision reminds me how little I know about python. Love it though. Understanding the core.ipynb was like trying to stay on one of those mechanical bulls. Gonna go through it a few more times, especially for the latter portion. Favorite part so far is definitely building up to getting rid of the super call in nn.Module. :partying_face:

class Module(nn.Module, metaclass=PrePostInitMeta):
    "Same as `nn.Module`, but no need for subclasses to call `super().__init__`"
    def __pre_init__(self): super().__init__()
    def __init__(self): pass

Think it would be better to write documentation on every class mentioned in 01_core.ipynb. That ways it would help every enthusiast to understand what is going on and also help us understand python better. Let me see what I can do.

1 Like

Not exactly a mistake - but I do agree it was a little unclear. I’ve changed the tests to make it more clear; thanks also for your PR! :slight_smile:

1 Like

I agree that documentation is a key issue. I would include comments in the code, which appears to be entirely comment-free. Just to give a hint as to the purpose of often obscure lines.
The videos are absolutely fantastic but I do not consider them to be easily accessible documentation.

I have had difficulty with the complete incorporation of tqdm (perhaps because I often do not use notebooks, and it can get mangled in displays). It has a disable flag but that doesn’t seem to work and to override huge classes for that is a tragedy. I would argue that tqdm is a bit too high level to put in a development package. But this could just be me…

I also think that the code is generally rather abstract. I can go quite quickly into almost anything in pytorch and easily understand how to make it work but in fastai, I have spent hours in some parts without really understanding much of anything. And I recall painfully learning data classes only to have them replaced from scratch.

Having said all that, the code rarely (if ever) fails when used properly and I really like that new research is quickly incorporated - greatly helpful in doing a (admittedly less pristine) port to pure Pytorch. For example, the 1-cycle was easy to put in pure Pytorch, after it was celebrated by fastai.

Sorry for the negativity. Even with that, I realize that fastai has had great positive impact and I am glad it exists.

The reasoning for this is ideally the documentation should explain line-by-line what’s going on. Which yes needs to be worked on immensely. However the new notebook structure allows that quite easily, and is a step in the right direction when compared to v1.

That being said though some decisions are just “well it just works” moments too that don’t necessarily have an explanation but do work in practice. For example the embedding sizes for tabular models. To some regard it took inspiration from word2vec but there isn’t a strong standpoint to why it works, aside from experimentation

1 Like

Thanks for the info. I don’t think I have seen the new notebook structure. Is there a link that explains it, or an example?

The entire v2 library is built by exporting notebooks. Right now I’m trying to go through and find a few areas that could need better explaining/updating as new developments happen within the library, however 08_pets_tutorial is a great example:

Note some bits do still need updating but the library is being updated as we speak anyways and so things are bound to change rapidly for the time being (but hopefully slow down soon enough).

You can then also see this notebook:

for where the source code originated from and testing it

As well as the data core notebook which goes into the processing for the datablock

Heads up for v2: I think fastai v1 reverses shape when it reads run-length encoded (RLE) segmentation masks. I.e. (x,y) instead of (height,width).

Hmm, just realized this is probably intentional (vision.image.open_mask_rle)… hold on: does training a model on RLE-masks work in fastai v1? If the datapath is:

input RLE → convert to input tensor → Model→ output tensor → convert to RLE

then the model won’t get the correct tensors unless the dataloader knows to reverse the masks’s height & width. Most I could find was how to work on regular masks (course v3: lesson3-camvid). SegmentationItemList has a .label_from_func method → so then is the correct way to run fastai v1 on RLE masks to either:

  1. decode all RLEs and save tensors to a folder?
  2. or write a function to correctly decode the RLE into its mask tensor?

Any thoughts then on how fastai_v2 should decode RLE masks? (width, height) vs (height, width). I’m happy to write it w/ an argument to do either, but maybe that’s getting ahead of things a bit. Guessing that’d be right next to Segmentation masks in 07_vision_core.

Here’s what I’m talking about:

This came up during debugging in an RLE-mask intensive kaggle competition. Learning about masks has been … a journey :sweat_smile:.