Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    for == to work like it generally should, we would need to implement consistent __eq__s
    the end result would be that == effectively does what aesara.graph.basic.equal_computations does
    this would make g_1 == g_2 a little expensive when they're both large graphs that are very similar except in the "leaf" nodes/inputs
    it would also require consistent __hash__ implementations
    and computing hashes for large graphs would take some effort
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    and, since we put graphs in sets and dicts all the time, it would surely have an effect
    now, if we made sure that graph objects were immutable, these hashes could be cached
    and that problem would be largely mitigated
    ultimately, I would like to take things down this path
    (or a better one)
    you can find this idea--and all the surrounding ones--in some Aesara issues
    and a full implementation in the symbolic-pymc meta objects
    Kaustubh
    @kc611:matrix.org
    [m]

    This seems like a whole other problem in itself.

    As of now, I was looking for ways to have a copy of a nested structure (for instance a dict with list of TensorVariables), I wanted to track changes within such structures, by comparing old to new modified structures. But ran into this issue when I deepcopied the nested structure.

    brandonwillard
    @brandonwillard:matrix.org
    [m]
    it doesn't work for the reason described above; in other words, equality is by identity
    that's why we need to clone graphs and track/use maps between old and cloned variables, as well
    we're just about set up to do some non-trivial graph rewriting with miniKanren
    the example above is AC unification (well, it's actually more than that: relational "matching" with AC properties)
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    Ricardo Vieira, I created an issue for that Blockwise Op: aesara-devs/aesara#695
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Thanks Brandon!
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    the documentation now has sections for unification/reification and minikanren
    the examples aren't that great, but I think they'll do the job for now
    tell me if you think anything should be clarified/added
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Where should I move softmax and related Ops to in the tensor module? Does a new file softmax.py make sense? math seems a bit cluttered. There is also extra_ops.py?
    2 replies
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    On another note, anyone has a good trick to manage default updates of random variables in a scan, when not using a RandomStream?
    import aesara
    import aesara.tensor as at
    
    rv, updates = aesara.scan(
        fn=lambda : at.random.normal(0, 1),
        n_steps=5,
    )
    print(rv.eval())
    # [-1.5294442 -1.5294442 -1.5294442 -1.5294442 -1.5294442]
    print(rv.eval())
    # [-1.5294442 -1.5294442 -1.5294442 -1.5294442 -1.5294442]
    1 reply
    remilouf
    @remilouf:matrix.org
    [m]
    Nope, I had the same issue and used RandomStream instead.
    I'm not a big fan of stateful rngs anymore, too much magic going on
    brandonwillard
    @brandonwillard:matrix.org
    [m]
    see my article on DLMs
    remilouf
    @remilouf:matrix.org
    [m]
    I was thinking about doing a correspondence table between aesara and numpy and start working my way through the list. Could do that with scipy as well.
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    That would definitely be nice. My question is more of how do we arrange things internally (and possibly how do we show to users). We are trying to offer functions that can come from two different libraries (numpy and scipy). We have been putting everything in math, but this can get unwieldy.
    remilouf
    @remilouf:matrix.org
    [m]
    I would say in a way that has the least cognitive overhead for someone who is already familiar with numpy/scipy
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Do you think that everything that is in scipy.special should go into tensor.special?
    remilouf
    @remilouf:matrix.org
    [m]
    That’s a small deviation from what i’m used to (jax has jax.numpy and jax.scipy) but it would make a lot of sense
    The way i usually work on api and modules is by writing mock code
    And to that respect the separation numpy/scipy is sometimes (often) confusing
    from aesara.tensor.special import softmax ?
    from aesara.tensor.math import softmax
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Well math objects are usually offered at the tensor level, so it would be from aesara.tensor import softmax or more typically import aesara.tensor as at; at.softmax
    remilouf
    @remilouf:matrix.org
    [m]
    if it’s only going to be visible to developers I’d suggest special.py. Makes comparisons with what’s available in scipy easier
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    So we should move the equivalent tensor/math.py methods that are implemented scipy.special to there, and then what I wanted to do in the first place which was to take the softmax out of nnet
    remilouf
    @remilouf:matrix.org
    [m]
    softmax in nnet is definitely confusing
    Ricardo Vieira
    @ricardov94:matrix.org
    [m]
    Yeah that's coming out. I just didn't want to put it in the already large math.py
    remilouf
    @remilouf:matrix.org
    [m]

    I’m reading the code for linkers and I have 2 questions:

    1- Is there any reason why the file structure is different for numba and jax linkers?

    2- Is there any way to print the generated code without compiling for debugging ? That was very useful with MCX.

    Kaustubh
    @kc611:matrix.org
    [m]
    Regarding the file structure I guess the one of the reason we split numba's dispatch was because the file was getting too long.
    The jax file structure is pretty much same except for dispatch being in same file. We should probably split it like Numba.
    remilouf
    @remilouf:matrix.org
    [m]
    Thanks! Oh and 3- why is the code generation approach used with numba and not (that I saw) with jax?
    Kaustubh
    @kc611:matrix.org
    [m]

    Probably because Jax offers much more flexibility than Numba.

    For instance take the case of Scan. Jax has an inbuilt scan like functionality, but in case of Numba we have to create the loops manually.

    We can use code generation approach in Jax too, but i think we're yet to run into logic that cannot be implemented in Jax.

    1 reply
    remilouf
    @remilouf:matrix.org
    [m]
    That makes sense