Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab

    @Gusten_Isfeldt_gitlab Also, be careful in general. I never finished implementing proper synchronisation for accumulator operators that cannot be implemented with hardware atomics (basically, primitive operators).

    @athas would this manifest as incorrect results, and if so, would the errors in general be small, like missed values in the accumulation?

    Troels Henriksen
    @athas
    @Gusten_Isfeldt_gitlab Yes, that seems like a likely outcome.
    Especially if you get the right results with the c backend.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    To be clear, I have not yet confirmed this. At the moment precise results are not critical in a sense, since I am not creating true production data. As long as the visuals are good enough for my presentations, it's okay, basically.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    (now I also have a scapegoat if an obvious artifact turns up in my presentation)
    Troels Henriksen
    @athas
    What are you visualising?
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    particle coordinates. The potential error is in the particle interaction.
    I will both show the particles in a simulation box and some more condensed statistics. Neither is particularly sensitive to errors, in terms of how they look.
    Troels Henriksen
    @athas
    That's the nice thing about graphics.
    Even the bugs can be attractive.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Yes, particularly in raytracing, though this is not.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    let lj (sigma:f32) (epsilon:f32) (r:f32) =
        let sdr = sigma/r
        let sdr2 = sdr*sdr
        let sdr6 = sdr2*sdr2*sdr2
        let sdr12 = sdr6*sdr6
        in 4*epsilon*(sdr12-sdr6)
    
    let k_B:f32 = 8.617333262125e-5  -- eV/K
    
    let p T V = f32.exp (-V/(k_B*T))
    
    let sigma:f32 = 1
    
    let epsilon:f32 = 1
    
    let n:i64 = 100
    
    let rs = tabulate n (\i -> 3*sigma* f32.from_fraction i n)
    
    let vs = map (\r -> let v = lj sigma epsilon r in (v, p 300 v)) rs
    
    let rvs = zip (zip rs rs) vs
    
    -- > :plot2d rvs

    results in

    Internal compiler error (unhandled IO exception).
    Please report this at https://github.com/diku-dk/futhark/issues
    After sending command ["store","/tmp/futhark-server-read1763236-1","out0"] to server process:fd:330: hGetLine: end of file
    Server process exited unexpectedly with exit code: -11
    Server stderr:
    
    CallStack (from HasCallStack):
      error, called at src/Futhark/Server.hs:141:7 in futhark-0.20.0-7O7l1SWHThQFOpbzz8q8kj:Futhark.Server

    What am I doing wrong?

    oh, I see it now...
    the x and y values should not be zipped
    after changing that I get
    > :plot2d rvs failed:
    Invalid data file produced by Futhark server.
    futhark: testplot-img: getDirectoryContents:openDirStream: does not exist (No such file or directory)
    Troels Henriksen
    @athas
    That should not happen.
    Troels Henriksen
    @athas
    @Gusten_Isfeldt_gitlab The error message is of course awful, but the problem is that the expression you have to pass to plot2d must be of some type ([]t, []t), where t is some kind of numeric type.
    That part is documented. futhark literate is just terrible at handling errors.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    The documentations says it can also handle records of said type, but I had no luck with that either.
    let rs = tabulate n (\i -> 3*sigma* f32.from_fraction i n)
    
    let vs = map (lj sigma epsilon) rs
    let ps = map (p 300) vs
    
    let rvs = {potential = (rs, vs), probability = (rs, ps)}
    -- > :plot2d rvs
    Internal compiler error (unhandled IO exception).
    Please report this at https://github.com/diku-dk/futhark/issues
    After sending command ["store","/tmp/futhark-server-read1951878-1","out0"] to server process:fd:330: hGetLine: end of file
    Server process exited unexpectedly with exit code: -11
    Server stderr:
    
    CallStack (from HasCallStack):
      error, called at src/Futhark/Server.hs:141:7 in futhark-0.20.0-7O7l1SWHThQFOpbzz8q8kj:Futhark.Server
    Troels Henriksen
    @athas
    I have no clue why that makes the server process segfault. I can't reproduce that part.
    I see. This is because records are not exposed in the C API. If you want to plot records, you need to use a record expression directly in the directive: :plt2d {potential = (rs, vs), probability = (rs, ps)}.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    ah, I see
    Troels Henriksen
    @athas
    These are the kinds of sharp edges that make futhark literate a bit of a clumsy tool.
    It's really a hack.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    Maybe one day it won't be(to the same extent)
    Troels Henriksen
    @athas
    There's no deep reason this can't be fixed, but it would take some time to define a protocol for how to communicate values of more complex types.
    The C interface actually supports obtaining the raw data (in the binary data format) underlying any opaque value. What would be needed is a description of how those parts map to the high-level type.
    This would be interesting for sum types, but not so hard for records.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    For now as long as I know how it works, it's ok.
    Gusten Theodor Isfeldt
    @Gusten_Isfeldt_gitlab
    -- > :plot2d { potential=(rs, vs) , probability = (rs, ps) }
    fails with
    unexpected space
    expecting '='
    removing all the whitespace in the record declaration works
    but my guess is that it is not supposed to be whitespace-sensitive
    Troels Henriksen
    @athas
    Ugh, lexer bug. Thanks. I'll get around to fix it.
    Snektron
    @snektron:matrix.org
    [m]
    What size is bool in binary data sets? and what layout do higher ranked arrays have?
    Troels Henriksen
    @athas
    Snektron
    @snektron:matrix.org
    [m]
    i've seen that page, but size of bools and layout of higher ranked arrays doesn't seem to be documented there
    Troels Henriksen
    @athas
    Hm, you're right. I'll have to add it. Bools are bytes, and the values are in row-major order.
    Snektron
    @snektron:matrix.org
    [m]
    (with layout i mean which axis goes where)
    Thanks
    Troels Henriksen
    @athas
    Both things should be fixed now.
    By the way, if you are in the unfortunate situation that you have to work directly with the Futhark data format, but fortunate enough to use Python, consider: https://pypi.org/project/futhark-data/
    Snektron
    @snektron:matrix.org
    [m]
    This is for the output of the lexer generator. For the parser, i just generated a source file, but for the lexer this file is several megabytes and so i can't really do that.
    I can either use some internal format or the Futhark binary data format. I guess the latter adds that i can experiment more easily.
    Thanks for that link though, i'll check out its source and use it for the small helper scripts i made.
    Snektron
    @snektron:matrix.org
    [m]
    are the indexes into the dataset lexographic or co-lexographic?
    i mean is the first value when writing a[x, y] the innermost or outermost axis
    Troels Henriksen
    @athas
    It's row-major order, so lexicographic.
    Snektron
    @snektron:matrix.org
    [m]
    thanks
    Troels Henriksen
    @athas
    Although that's not strictly true. Futhark does not define an in-memory representation. It's whatever the compiler thinks will make your code run faster.
    But when you flatten/reshape arrays, the semantic ordering is considered row-major order.