A Julia package for high-throughput manipulation of structured signal data
github.com
github.com
> Onda is a lightweight format defined atop Apache Arrow for storing and manipulating sets of multi-sensor, multi-channel, LPCM-encodable, annotated, time-series recordings.
> This format is intentionally language-agnostic; any consumer/producer that supports Apache Arrow can read/write Onda-compliant Arrow tables. For the sake of convenience, the Onda specification resides here (in the Onda.jl repository) and leverages the Legolas framework to both define and version the Arrow table schemas relevant to the format. Terminology
> This document uses the term...
> ..."LPCM" to refer to linear pulse code modulation, a form of signal encoding where multivariate waveforms are digitized as a series of samples uniformly spaced over time and quantized to a uniformly spaced grid.
> ..."signal" to refer to the digitized output of a process. We refer to the "devices" (physical, or virtual) that sample processes to generate signals as sensors. A signal is comprised of metadata (e.g. LPCM encoding, sensor information, channel information, sample data path/format information, etc.) and associated multi-channel sample data.
> ..."recording" to refer a collection of one or more signals recorded simultaneously over some time period.
> ..."annotation" to refer to a piece of (meta)data associated with a specific time span within a specific recording.
I'm not sure if it's directly relevant for what I do, but I invariably learn a lot from reading Julia libraries; they tend to be high-quality. Certain higher quality than the average python library. This is what I'm gonna be doing tonight after dinner :-) Thanks for sharing.
I'll leave you to think why it might be that your take is so off.
(Thanks for your work)
All of the cost function values are infinite, which results in an empty plot.
There were others, but it's been too long that I don't recall exactly which ones.
Edit: Here is another from the advanced tutorials
DiffEqUncertainty/02-AD_and_optimization.ipynb
The fourth cell produces the error
Simultaneously using keywords vars and idxs is not supported. Please only use idxs.
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35
[2] macro expansion
[3] apply_recipe(plotattributes::AbstractDict{Symbol, Any}, sol::SciMLBase.AbstractTimeseriesSolution)
@ SciMLBase ~/.julia/packages/RecipesBase/eU0hg/src/RecipesBase.jl:300
[4] _process_userrecipes!(plt::Any, plotattributes::Any, args::Any)
@ RecipesPipeline ~/.julia/packages/RecipesPipeline/XxUHt/src/user_recipe.jl:38
[5] recipe_pipeline!(plt::Any, plotattributes::Any, args::Any)
@ RecipesPipeline ~/.julia/packages/RecipesPipeline/XxUHt/src/RecipesPipeline.jl:72
[6] _plot!(plt::Plots.Plot, plotattributes::Any, args::Any)
@ Plots ~/.julia/packages/Plots/aRJ6C/src/plot.jl:225
[7] #plot#182
@ ~/.julia/packages/Plots/aRJ6C/src/plot.jl:102 [inlined]
[8] top-level scope
@ In[4]:11
[9] eval
@ ./boot.jl:368 [inlined]
[10] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
@ Base ./loading.jl:1428> All of the cost function values are infinite, which results in an empty plot.
I copy pasted the code up to the first plot of a cost function, and works fine.
On a higher note though... I'm a bit confused: we were talking about DifferentialEquations.jl, one of the libraries that is most heavily maintained, and then when asked for examples of what tutorials aren't working, you don't post any examples from DifferentialEquations.jl but from tutorials of other libraries? One of which we publicly discuss all of the time as not yet completed (DiffEqUncertainty -> SciMLUncertainty, one of the current research projects)? I would not conflate the two, it's like saying SciPy isn't robust because Python's ODES library isn't: they are two different libraries and the authors are quite public about the differences. We have been very public that the UQ stuff is still ongoing research with monthly talks about it, and we keep it in a separate Github repo with separate documentation. We don't call that DifferentialEquations.jl for a very good reason.
Stop believing everything you read.
And how do you explain that? Because to me the simplest explanation is very obvious.
I tend to use it the same way I'd use Jupyter notebooks. If something were mission critical I'd be wary of using Julia for it unless it's absolutely the best tool for the job.
On the other hand, if production for you involves simulation, optimization or lots of data munging/analysis, you should very strongly consider it. JuMP is great for optimization (and being used in production to among other things optimize power grids). The DifferentialEquations ecosystem has by far the best solvers out there. The PDE side is very WIP, but for ODE's and DAEs Julia is significantly better than anything else out there. The DiffEq ecosystem is used in production possibly most notably by Pumas.ai which has been used in the development drugs and vaccines that are in use. The data analysis side of Julia has less in terms of stand out packages, but has the advantage that unlike low level languages, you get a lot of expressivity (better code reuse, lots less boilerplate, and interactivity), while compared to high level languages, you don't have to shove all your computation down into low level languages to get good performance. You can just write the code to solve your problem without caring about fitting it into a framework or reciting ancient runes to please the compilers of the past.
The bigger picture is that if you work in Python or Matlab and you have a program that runs in more than 15 minutes, you should strongly consider switching to Julia. Conversely, if you are working in C++ or Fortran and are annoyed about dealing with UB, needing a preprocessor because your language isn't powerful enough, or not having a good build/dependency management system, Julia is definitely worth looking at.
There are definitely some gripes I have with Julia's developer experience, but it also has some great parts. The REPL is great (before I came to Julia I hated REPLs but Julia's is really good). Package management is great (including for binary dependencies), and there are a lot of tools built in to let you interactively ask the compiler about all sorts of things.`@which` tells you where a function was defined, `@edit` lets you jump to some code and start messing with it, there are a bunch of `@code_<X>` macros that let you inspect each step of compilation all the way down to native code.
Lastly it depends on your team and what experience they have and what they are willing to learn. Julia has an interesting habit of taking scientists who only cared about their domains and turning them into compiler developers (or experts in solving numerical differential equations). Julia is in some ways fairly close to Python, Matlab, C++, and Lisp but in other ways is very different. If you come to Julia and try to pretend it's a normal object oriented language, you will be fighting it every step of the way, but if you are willing to try something new, it is really powerful.