Re: [julia-users] Ccall, have julia manage C initialized struct memory?

[James Crist]

Yep, that was it! Thanks.

- Jim

On Friday, February 27, 2015 at 4:57:44 AM UTC-6, Tim Holy wrote:
>
> Do you mean something different from 
>
> cobj = Array(Uint8, len) 
> ccall(:foo, void, (Ptr{Void},), cobj) 
>
> ? 
> --Tim 
>
> On Thursday, February 26, 2015 10:50:51 PM James Crist wrote: 
> > This is more of a curiousity question than an actual use case. Is there 
> any 
> > way to have Julia manage heap allocated memory that is initialized by a 
> C 
> > function? By this, I mean suppose I had a function: 
> > 
> > void foo(void *x) { 
> >  ...initize some structure in C here from the memory passed in by 
> x... 
> > } 
> > 
> > In C, I would malloc, then pass in the memory to the initialization. Is 
> > there any way to do this in Julia, but have Julia manage the memory? 
>
>

[julia-users] Ccall, have julia manage C initialized struct memory?

[James Crist]

This is more of a curiousity question than an actual use case. Is there any 
way to have Julia manage heap allocated memory that is initialized by a C 
function? By this, I mean suppose I had a function:

void foo(void *x) {
 ...initize some structure in C here from the memory passed in by x...
}

In C, I would malloc, then pass in the memory to the initialization. Is 
there any way to do this in Julia, but have Julia manage the memory?

[julia-users] Tuples as a performant any container?

[James Crist]

I'm writing some code that requires a container of an abstract type. 
Iteration and concatenation speed (and memory size) are more important than 
indexing. Having fast reordering for a decent performing sort would also be 
nice, but that's a second. In my code, I compared 3 different containers: 
Vector{Any}, LinkedList (from DataStructures.jl), and tuples. Without 
numbers, here's the relations I found (tried for varying N, all relations 
seemed consistent in the range I care about):

Size (smaller is better):

Any[...] > list(...) > tuple(...) 

Concatenation Speed (smaller is better):

Any[...] > list(...) > tuple(...)

Iteration:

All about the same.


Based on the results above, I'm looking into using tuples. The application 
is a tree structure, where each node has an (unknown, but in 99% of cases < 
15, definitely no more than 100) number of children, which may be of a 
variety of different types. What I'm wondering is: are tuples meant for 
such a thing? Or am I misusing them in this context? In Python, I'd use a 
tuple for this, not sure how they compare though.

---

As an aside, I also looked at using the Traits Trick (
https://github.com/JuliaLang/julia/issues/2345#issuecomment-54537633), and 
have all the nodes be of the same type. I'd like to be able to use dispatch 
on each node, rather than writing a bunch of if-else statements in a 
visitor function. Would this be a better method than a generic Any 
container holding the children?

Sorry for bombarding the list with design questions lately, I'm still 
getting a hang of this language.

Re: [julia-users] Parametric vs Abstract typed collections, design question

[James Crist]

Thanks, that's kind of what I expected.

@Tim:

I found some stuff in there (and in the very helpful Types section), but
never saw explicitly whether a collection of unparametrized parametric type
offered any additional benefit to the compiler than one of just abstract
type. (i.e. Rational[] vs Real[]). Since the container type isn't concrete,
I figured it probably wouldn't offer any benefit, but thought I'd ask.

- Jim


On Sun, Feb 1, 2015 at 5:07 AM, Tim Holy  wrote:

> James, in case you haven't seen it, this is treated _extensively_ in the
> FAQ.
> Make a nice cup of tea and pull up a comfy chair before you start reading
> :-).
>
> --Tim
>
> On Sunday, February 01, 2015 01:16:19 AM Jutho wrote:
> > As long as not all parameters of a parametric concrete type are fully
> > specified, the type is treated as abstract. So in both cases your
> > collection would be of abstract elements and they would not be stored
> > packed in memory. I don't think what you are requesting is possible, but
> I
> > might be mistaken. If the elements of the collection are of a concrete
> > type, then applying a function to them should always be the same
> function.
> > If this were not the case, then type inference could not work.
>
>

Re: [julia-users] Parametric vs Abstract typed collections, design question

[James Crist]

Anyone have any thoughts on this? What I'm trying to figure out is a way to 
dispatch on different elements all in the same collection, without 
declaring the collection to be of abstract type. Meaning `func(a::Foo)` and 
`func(a::Bar)` should be different, even though `Bar` and `Foo` have the 
same internal representation (should be no underlying difference in memory).

This boils down to wondering if having a collection of an unparametrized 
parametric type is better/different than just an abstract type. Reiterating 
my example from above:

Option 1:

abstract Root

type Foo <: Root
...
end

type Bar <: Root
...
end

(the ... are the same for both Foo and Bar)

Option 2:

type Root
 ...
end
typealias Foo Root{:Foo}
typealias Bar Root{:Bar}

Would either option generate better code when iterating over a collection 
of `Root`? Or is `Root` in option 2 still treated the same as an abstract 
parameter (even though the internal structure is invariant among all 
parametrizations)?

Re: [julia-users] Parametric vs Abstract typed collections, design question

[James Crist]

Woops, example 2 should be:

type Root{T}
...
end

On Fri, Jan 30, 2015 at 4:53 PM, James Crist  wrote:

> The problem:
>
> I have 2 types. They have the same internal structure, and both can be
> thought of as subtypes of an abstract root.
>
> abstract Root
>
> type Foo <: Root
> ...
> end
>
> type Bar <: Root
> ...
> end
>
> Because they have the same internal structure, I could equally define a
> parametric type `Root`, and typealias `Foo` and `Bar`:
>
> type Root
>  ...
> end
> typealias Foo Root{:Foo}
> typealias Bar Root{:Bar}
>
> The Question:
>
> Given a collection of objects of these types (say a vector), where both
> Foo and Bar will be present, which way is more performant/Julian?
> Basically, is it better to have a collection of an abstract type (option
> 1), or of a parametric type with the parameters yet to be specified (option
> 2)?
>

[julia-users] Parametric vs Abstract typed collections, design question

[James Crist]

The problem:

I have 2 types. They have the same internal structure, and both can be 
thought of as subtypes of an abstract root.

abstract Root

type Foo <: Root
...
end

type Bar <: Root
...
end

Because they have the same internal structure, I could equally define a 
parametric type `Root`, and typealias `Foo` and `Bar`:

type Root
 ...
end
typealias Foo Root{:Foo}
typealias Bar Root{:Bar}

The Question:

Given a collection of objects of these types (say a vector), where both Foo 
and Bar will be present, which way is more performant/Julian? Basically, is 
it better to have a collection of an abstract type (option 1), or of a 
parametric type with the parameters yet to be specified (option 2)?

Re: [julia-users] Re: ANN: Symbolic computation with Julia

[James Crist]

>
> Maybe the parser could be useful if rewritten in Julia:


Side tracking a bit, but one of the reasons I use SymPy instead of
something like Maxima is that it meshes seamlessly into the language
infrastructure. By writing a parser and creating another system means that
it can't use julia's ecosystem without modification. I'd rather see a CAS
work within Julia's parser framework. But that's just me.

I am more concerned now in getting correct logical behavior than efficient
> application of rules.


Making it just *work* is certainly a priority, but design decisions made
now can make things tricky later on. Especially with the design of your
internal representation. How you represent expression trees and assumptions
can seriously affect the performance of matching/traversals/replacements.

On Mon, Jan 26, 2015 at 11:47 AM, Francesco Bonazzi  wrote:

>
>
> On Monday, January 26, 2015 at 6:11:33 PM UTC+1, lapeyre@gmail.com
> wrote:
>>
>>
>> Another resource is Richard Fateman's  mma4max
>> , which I see has
>> updates since I last built it. It aims more or less to implement mma in
>> common lisp. In fact it has a Julia-compatible license and a complete
>> parser written in common lisp. IIRC the comments show that the pattern
>> matcher is not perfect, but I think it is complete.
>>
>
> Maybe the parser could be useful if rewritten in Julia:
> http://www.cs.berkeley.edu/~fateman/lisp/mma4max/parser.lisp
>

[julia-users] Re: ANN: Symbolic computation with Julia

[James Crist]

One of the SymPy devs here. Without looking too into your code, I'd like to 
comment on the pattern-dispatch system, with regards to 
associative-commutative expressions. This has been on my mind a lot lately, 
as I've been working on a rewrite of our pattern matcher to be more 
efficient/versatile.

With dispatch on patterns for symbolic computation, there seem to be two 
schools of thought. If you read papers from the theorem proving world, most 
use a sufficiently-smart-matcher(tm) that can handle patterns with certain 
properties (associative, commutative, identity, etc...). Most of these 
result in a single, heavily optimized data structure that then performs all 
pattern dispatches. In this case, you'd load all your rules, and then run 
the rewrite system. 

In contrast, most of the computer algebra work use a more heuristic-y 
approach, with preprocessing of the patterns, and formation of many smaller 
matching structures. These are then applied manually in human-written logic 
code. By this I mean that you may have a structure for trig rewriting 
rules, and one for logarithm rules, etc... And then in your main routine 
(let's say a simplification routine), you would apply these manually 
(match(expr, trig_rules), match(expr, log_rules), etc...). The idea behind 
this is that in most cases you have some knowledge about the structure of 
the expression, which can reduce the number of rules you'd need to check.

For larger collections of patterns, a good way is to use a discrimination 
net (a trie like structure), which can aid in faster matching. This paper 
is a good reference: Associative-Commutative Discrimination Nets 
.
 
This approach is great if you have a large group of patterns.

For smaller collections of patterns, Richard Jenk's paper "A Pattern 
Compiler" 

 
is a decent starting point. This system is much more similar to that of 
Mathematica's than the one dscribed above (describes the pattern compiler 
for SCRATCHPAD, which later became AXIOM). Unfortunately, it doesn't deeply 
discuss the implementation, but the basic idea behind it is given. The gist 
is that a collection of patterns is preprocessed, and all possible 
combinations of rules (associative/commutative/identity) are expanded. A 
matching program is then created and evaled, creating a specialized rewrite 
function for that set. For small patterns/collections of patterns (which 
for computer algebra is the norm) this is a great system, and one that I 
think could be implemented in Julia.

Sorry for the long response, this is something I've just been thinking 
about a lot lately.

- Jim

On Sunday, January 25, 2015 at 8:07:22 PM UTC-6, lapeyre@gmail.com 
wrote:
>
> Hi,
>
> Here is some code I have been working on. It is for symbolic computation 
> based on pattern matching.
> If you find it interesting, any feedback is welcome!
>
> https://github.com/jlapeyre/SJulia
>
> --John
>

Re: [julia-users] Getting 0 test coverage, when I know that's not true...

[James Crist]

I'm using the arch build from the aur, so it may be an issue with that. 
I'll try rebuilding it tonight with the latest master and see.

I filed an issue here: https://github.com/JuliaLang/julia/issues/9891

On Thursday, January 22, 2015 at 8:18:09 PM UTC-6, Tim Holy wrote:
>
> The one other thing that could be useful would be full versioninfo(); it 
> could 
> be a LLVM-version thing. Please do file this as an issue, so it doesn't 
> get 
> lost. 
>
> But the bottom line is that I have no clue what's going on. Your version 
> of 
> julia is nominally new enough to not have any coverage-related bugs I know 
> about :-). But it's not behaving in the typical manner, so something is 
> wrong. 
>
> In case it's a packaging problem, depending on how much you care about 
> this 
> functionality you may want to try building your own julia straight from 
> the 
> git repo. 
>
> Best, 
> --Tim 
>
> On Thursday, January 22, 2015 05:41:20 PM James Crist wrote: 
> > Yeah. All lines that get run are 0, and all untested lines remain at 
> `-`. 
> > My backtraces all look fine (at least I haven't noticed anything weird). 
> > 
> > Platform is x86_64 arch linux, running 8 day old master, commit 
> eea31ae*. 
> > 
> > I can replicate this in a small testable case by creating a small 
> script, 
> > and running it with coverage, so it's not specific to my package. 
> > 
> > On Thu, Jan 22, 2015 at 5:31 PM, Tim Holy  > wrote: 
> > > Are you saying that no line has anything higher than a 1 in front of 
> it? 
> > > 
> > > I just tried the procedure you described below, as well as the simpler 
> > > `Pkg.test("Control", coverage=true)` (which now works on julia 0.4 
> again, 
> > > if 
> > > you're up to date). Both approaches worked fine for me. Do you have 
> any 
> > > problems with your backtraces, or anything else potentially related? 
> > > What's 
> > > your platform? 
> > > 
> > > --Tim 
> > > 
> > > On Thursday, January 22, 2015 11:52:17 AM James Crist wrote: 
> > > > I'm having issues getting coverage to work. Here's what I'm doing: 
> > > > 
> > > > 1. From my package directory I run this: 
> > > > 
> > > > $ julia --code-coverage --inline=no test/runtests.jl 
> > > > 
> > > > This results in *.cov files for all files that are run. 
> > > > 
> > > > 2. Run julia, then: 
> > > > 
> > > > julia> using Coverage 
> > > > julia> coverage_folder() 
> > > > 
> > > > This prints out a list of files in my src folder. All files that 
> have 
> > > 
> > > *.cov 
> > > 
> > > > associated with them also show "Skipped file_name". 
> > > > 
> > > > Looking closer at the *.cov files, I see that all lines that *I 
> know* 
> > > > are 
> > > > run have a 0 next to them, even if they are run several several 
> times in 
> > > > the tests. Lines that have no coverage are still at `-`. Any idea 
> why? 
> > > 
> > > I'm 
> > > 
> > > > kind of baffled on this. 
> > > > 
> > > > The package in question: https://github.com/JuliaControl/Control.jl 
>
>

Re: [julia-users] Getting 0 test coverage, when I know that's not true...

[James Crist]

Yeah. All lines that get run are 0, and all untested lines remain at `-`.
My backtraces all look fine (at least I haven't noticed anything weird).

Platform is x86_64 arch linux, running 8 day old master, commit eea31ae*.

I can replicate this in a small testable case by creating a small script,
and running it with coverage, so it's not specific to my package.

On Thu, Jan 22, 2015 at 5:31 PM, Tim Holy  wrote:

> Are you saying that no line has anything higher than a 1 in front of it?
>
> I just tried the procedure you described below, as well as the simpler
> `Pkg.test("Control", coverage=true)` (which now works on julia 0.4 again,
> if
> you're up to date). Both approaches worked fine for me. Do you have any
> problems with your backtraces, or anything else potentially related? What's
> your platform?
>
> --Tim
>
> On Thursday, January 22, 2015 11:52:17 AM James Crist wrote:
> > I'm having issues getting coverage to work. Here's what I'm doing:
> >
> > 1. From my package directory I run this:
> >
> > $ julia --code-coverage --inline=no test/runtests.jl
> >
> > This results in *.cov files for all files that are run.
> >
> > 2. Run julia, then:
> >
> > julia> using Coverage
> > julia> coverage_folder()
> >
> > This prints out a list of files in my src folder. All files that have
> *.cov
> > associated with them also show "Skipped file_name".
> >
> > Looking closer at the *.cov files, I see that all lines that *I know* are
> > run have a 0 next to them, even if they are run several several times in
> > the tests. Lines that have no coverage are still at `-`. Any idea why?
> I'm
> > kind of baffled on this.
> >
> > The package in question: https://github.com/JuliaControl/Control.jl
>
>

[julia-users] Getting 0 test coverage, when I know that's not true...

[James Crist]

I'm having issues getting coverage to work. Here's what I'm doing:

1. From my package directory I run this:

$ julia --code-coverage --inline=no test/runtests.jl

This results in *.cov files for all files that are run.

2. Run julia, then:

julia> using Coverage
julia> coverage_folder()

This prints out a list of files in my src folder. All files that have *.cov 
associated with them also show "Skipped file_name".

Looking closer at the *.cov files, I see that all lines that *I know* are 
run have a 0 next to them, even if they are run several several times in 
the tests. Lines that have no coverage are still at `-`. Any idea why? I'm 
kind of baffled on this.

The package in question: https://github.com/JuliaControl/Control.jl

Re: [julia-users] Re: Naming of functions advice

[James Crist]

>
> Alternatively, Julia has namespaces; I'm not sure why you think it doesn't.
>

I know it does, but the main mode of operation seemed to be adding methods
to existing functions in Base, to allow everything to work seemlessly.
Defining `zero` to do something other than what `Base.zero` does for my
custom types would then prevent functionality in Base that uses `zero` from
working on my types.


> That being said, the Julian style function is to only use the Base names
> for functions that are conceptually similar to the Base function.   If your
> function is conceptually different from Base.zero(x), then it would be more
> idiomatic to give it a different name.
>

This is what I was looking for. I wasn't sure if there was any precedence
for adding methods to those in Base that behave different than those in
Base. Looks like I'll have to come up with different names.

@Jason Merril

I'm not a big fan of `roots`, as the poles of the system could also be
thought of as roots of the denominator polynomial. Perhaps a qualifier on
`zero`, such as `ltizero` and `ltipole`? I'd prefer an underscore in there,
but this goes against the style guide (I think?).

The `response` idea is interesting though. Would a type be the best way to
go about this? Currently all my code uses Symbols as options, so I'd write
it like:

y, t, x = response(sys, :step)
y, t, x = response(sys, :impulse)

Is a custom type better for this? I suppose that would allow the dispatch
to work, rather than handling the diversity in the function itself.




On Mon, Jan 12, 2015 at 5:32 PM, Jason Merrill  wrote:

> Another Julian option for response functions would be to have something
> like:
>
> abstract AbstractDrivingFunction
>
> immutable StepType <: AbstractDrivingFunction
> end
>
> immutable ImpulseType <: AbstractDrivingFunction
> end
>
> Step = StepType()
> Impulse = ImpulseType()
>
>
> Then you could have people call
>
> response(sys::LTISystem, Step)
>
> or
>
> response(sys::LTISystem, Impulse)
>
> to get the step response or the impulse response for the system.
>
>
> On Monday, January 12, 2015 at 3:20:10 PM UTC-8, Jason Merrill wrote:
>>
>> Not sure if this is very helpful, but I think `roots` would be a great
>> name to use instead of `zero`.
>>
>> You could maybe use `stepresponse` instead of `step`, but it's a little
>> hard to parse with Julia's squishedcase convention.
>>
>> On Monday, January 12, 2015 at 11:09:54 AM UTC-8, James Crist wrote:
>>>
>>> I'm currently writing a control theory package for Julia. The MATLAB
>>> control theory toolbox has been around forever, and is *the standard*
>>> grammar for the field. Almost all control theory packages in other
>>> languages just replicate the same set of functions, with the same names.
>>> The function names are so hardcoded into me, that I'm reluctant to change
>>> them.
>>>
>>> That said, several of them conflict with Julia base function names. For
>>> example:
>>>
>>> `zero(sys::LTISystem)` would compute the zeros of the system in MATLAB,
>>> but in Julia this should create the "zero-valued" system
>>>
>>> `step(sys::LTISystem)` computes the step-response, but in julia it gives
>>> the step for a range
>>>
>>> There are others as well. I see two options here:
>>>
>>> 1.) I begrudgingly rename them, and attempt to retrain my muscle-memory
>>> when writing code :/
>>> 2.) Some functions don't do what they do in julia base for these types
>>>
>>> #1 probably is for the best, but I'm wondering what the community
>>> response is to this? I come from a heavy Python background, and without
>>> namespaces, I'm not sure how to handle function name-clashing best.
>>>
>>

[julia-users] Naming of functions advice

[James Crist]

I'm currently writing a control theory package for Julia. The MATLAB 
control theory toolbox has been around forever, and is *the standard* 
grammar for the field. Almost all control theory packages in other 
languages just replicate the same set of functions, with the same names. 
The function names are so hardcoded into me, that I'm reluctant to change 
them.

That said, several of them conflict with Julia base function names. For 
example:

`zero(sys::LTISystem)` would compute the zeros of the system in MATLAB, but 
in Julia this should create the "zero-valued" system

`step(sys::LTISystem)` computes the step-response, but in julia it gives 
the step for a range

There are others as well. I see two options here:

1.) I begrudgingly rename them, and attempt to retrain my muscle-memory 
when writing code :/
2.) Some functions don't do what they do in julia base for these types

#1 probably is for the best, but I'm wondering what the community response 
is to this? I come from a heavy Python background, and without namespaces, 
I'm not sure how to handle function name-clashing best.

[julia-users] Interface design advice - optional plotting?

[James Crist]

I'm trying to replicate the interface of some MATLAB code I use frequently. 
Because functions in MATLAB have knowledge of their "output arguments", 
different behaviors can occur if an assignment is used or not (i.e. `a = 
foo()` can do something different than just `foo()`). Specifically, the 
interface I'm trying to replicate displays a plot with no output arguments, 
and otherwise returns the data. 

In Python, I'd use a kwarg `plot=False`. What's the most Julian way of 
doing this? I have two thoughts right now:

1. Use a kwarg. `foo(...)` returns the data, `foo(..., plot=true)` creates 
a plot and returns nothing (or the plot handle?).

2. Create a `@plot` macro that sets a global `PLOT` boolean variable. This 
indicates to the functions it's configured to work with that the data 
should be plotted. The use would be: `@plot foo(...)`, which generates the 
code:
```
PLOT = true
foo(...)
PLOT = false
```
This could also be modified to return the plot handle at the end of the 
block. While I tend to like this interface more than #1, it's also more 
magical, which is bad.

3. Create a `@plot` macro that somehow knows how to plot each function (a 
registry of some kind?). Then the function needs no knowledge of how to 
plot itself, and the macro is just a fast way of writing in the plotting 
code. Use is `@plot foo(...)`, which expands to
```
data = foo(...)
plotting code here...
```

4. Create a separate function `fooplot`. `foo` returns the data. `fooplot` 
runs foo, and creates a plot.

Out of all of these, I like option #3 best, but want to use the most Julian 
way of doing things as possible. Thoughts?

--

Also, is there a good way to only load the plotting package (Gadfly, 
Winston, etc...) when it's first used? Loading these takes a long time; it 
would be nice if they could only be loaded upon the first call to `plot`.

Re: [julia-users] Re: Control system library for Julia?

[James Crist]

>
> I think Jim Crist spent the summer doing a Python GSoC, so progress on 
> control packages for Julia has been mostly stalled.
>

Ha, yeah, was working on symbolic dynamics solver stuff - more applicable 
to my research. I have some unpushed commits for Control.jl, but for the 
most part this project has stalled until I finish my degree. I just don't 
have the use for simple linear systems routines right now, when my system 
has nonlinearities, and i'm implementing it in discrete time in C. This 
project started out as me just playing around with Julia, and wishing it 
had a controls toolbox. I still do, but just don't have the time.

A Julia replacement for "realtime workshop" is a good long-term goal.
>

That would be awesome. I hate doing *almost* everything opensource, and 
then still turning back to simulink in the end to test on hardware. Not 
cool.

more informations on kite control you can find in the following papers
>

This is super cool. 

- Jim

 
On Monday, September 15, 2014 10:26:35 PM UTC-5, Patrick O'Leary wrote:
>
> On Monday, September 15, 2014 9:56:23 AM UTC-5, Uwe Fechner wrote:
>>
>> more informations on kite control you can find in the following papers:
>>
>
> Fascinating! Thanks for sharing. 
>

Re: [julia-users] Best way to check if package is installed

[James Crist]

Good to know. Because the package is still in development though (and thus
not in metadata), it errors if not installed:

julia> Pkg.installed("Slicot")
ERROR: Slicot is not a package (not registered or installed)

I suppose I could wrap it in a try block, and once it's up to snuff and in
metadata this won't be a problem. I'm just looking for a good intermediate
solution so people can work on it until then.


On Sun, Jun 8, 2014 at 4:04 PM, Stefan Karpinski 
wrote:

> Pkg.installed("DataFrames") should be substantially faster since it just
> checks for a single package instead of checking all of them. This is yet
> another one of the growing number of issues caused by the incredible
> slowness of forking git so much in the package manager.
>
>
> On Sun, Jun 8, 2014 at 12:54 AM, James Crist  wrote:
>
>> I'm working on a package that has an optional dependency. As in it works
>> without it, but has additional functionality if it is installed. Because
>> the packages are still in development, they're not in Metadata right now.
>> So I'm checking with:
>>
>> if haskey(Pkg.installed(), "Pkgname")
>> import added_functionality
>> end
>>
>> This call takes 22 seconds on my machine. Is there a faster/better way to
>> go about doing this?
>>
>
>

[julia-users] Best way to check if package is installed

[James Crist]

I'm working on a package that has an optional dependency. As in it works 
without it, but has additional functionality if it is installed. Because 
the packages are still in development, they're not in Metadata right now. 
So I'm checking with:

if haskey(Pkg.installed(), "Pkgname")
import added_functionality
end

This call takes 22 seconds on my machine. Is there a faster/better way to 
go about doing this?

Re: [julia-users] Re: Easy way to declare function works on array of floats

[James Crist]

@Toivo:

Thanks! I didn't know you could parametrize type aliases. Ths solution is
exactly what I was looking for. Although I agree the shorthand proposal
would be nice as well.


On Mon, May 26, 2014 at 2:35 PM, John Myles White 
wrote:

> I’ve often thought that Array{T <: Any} would be easier to understand, so
> +1 for this.
>
>  — John
>
> On May 26, 2014, at 12:33 PM, Toivo Henningsson 
> wrote:
>
> Or you can use
>
> typealias FPArray{T<:FloatingPoint} Array{T}
>
> foo(a::FPArray, b::FPArray) = a+b
>
> to get the same effect (foo will still apply when the element types of a
> and b are different).
>
> Perhaps we could introduce a syntax to create such a covariant typealias
> on the fly, e.g.
>
> const FPArray2 = Array{<:FloatingPoint}
>
> would work the same as FPArray above (though with an anonymous/hidden
> type parameter).
> Then the example could be written
>
> foo(a::Array{<:FloatingPoint}, b::Array{<:FloatingPoint}) = a+b
>
> if you don't want to define the typealias first.
>
> On Sunday, 25 May 2014 17:44:26 UTC+2, Pierre-Yves Gérardy wrote:
>>
>> On Sunday, May 25, 2014 5:10:49 PM UTC+2, James Crist wrote:
>>>
>>> Yeah, that's what I've been using. My issue with it is that the
>>> declarations get long for functions with more than 2 arrays. Was hoping
>>> there was a more concise way.
>>>
>>
>> You can use  typealias Fp FloatingPoint , then
>>
>> function foo{T1<:Fp, T2<:Fp}(a::Array{T1}, b::Array{T2})
>>
>>
>

Re: [julia-users] Re: Easy way to declare function works on array of floats

[James Crist]

Is that preferable? The function is only defined for floats (integers or 
complex wouldn't make any sense). Checking would have to occur inside the 
function then, while I thought that it was more preferable to have the type 
dispatch do that.

On Sunday, May 25, 2014 10:20:00 AM UTC-5, Mauro wrote:
>
> I think there is nothing shorter, if you need to dispatch on the type 
> (e.g. if you also have a `foobar` function for say Intergers as well). 
>  Otherwise a function `foobar(a,b)` without type information works just as 
> well and as fast as it will be compiled for the specific input types. 
>
> On Sun, 25 May 2014 08:10:49 -0700 (PDT), James Crist 
> > 
> wrote: 
>
> > Yeah, that's what I've been using. My issue with it is that the 
> > declarations get long for functions with more than 2 arrays. Was hoping 
> > there was a more concise way. 
> > 
> > On Sunday, May 25, 2014 8:16:58 AM UTC-5, Steven G. Johnson wrote: 
> > > 
> > > On Sunday, May 25, 2014 9:14:46 AM UTC-4, Steven G. Johnson wrote: 
> > >> 
> > >> function foo{T1<:FloatingPoint, T2<:FloatingPoint)(a::Array{T2}, 
> > >> b::Array{T2}) 
> > >> 
> > > 
> > > Whoops, two typos.  This should be: 
> > > 
> > > function foo{T1<:FloatingPoint, T2<:FloatingPoint}(a::Array{T1}, 
> > > b::Array{T2}) 
> > > 
>
>
>

[julia-users] Re: Easy way to declare function works on array of floats

[James Crist]

Yeah, that's what I've been using. My issue with it is that the 
declarations get long for functions with more than 2 arrays. Was hoping 
there was a more concise way.

On Sunday, May 25, 2014 8:16:58 AM UTC-5, Steven G. Johnson wrote:
>
> On Sunday, May 25, 2014 9:14:46 AM UTC-4, Steven G. Johnson wrote:
>>
>> function foo{T1<:FloatingPoint, T2<:FloatingPoint)(a::Array{T2}, 
>> b::Array{T2})
>>
>
> Whoops, two typos.  This should be:
>
> function foo{T1<:FloatingPoint, T2<:FloatingPoint}(a::Array{T1}, 
> b::Array{T2}) 
>

[julia-users] Easy way to declare function works on array of floats

[James Crist]

I've been struggling with this for a while, and haven't found a way to do 
it that I'm happy with. I'm sure there is one though. Basically, I want to 
declare a function that works on an array of floats. Doesn't matter what 
kind of float. Doesn't matter if there are 2 different kinds of float 
arrays.

For example, if `a` is an array of Float64, and `b` is an array of Float32, 
the function foobar(a, b) should work, just as well as f(a, a) or f(b, b). 
I've gotten a couple ways to work, but am not sure what's the most Julian, 
and have to believe there is a better way:

1.) Parametric definition. This gets really long if there are multiple 
different Matrices in the call.
function foobar{T<:FloatingPoint, S<:FloatingPoint}(a::Matrix{T}, b::Matrix{
S})

2.) Type union definition. Not sure if this is optimal or not. It also will 
only work with the initial defined floats, so anything that subtypes 
FloatingPoint later on will not be valid
FloatArrays = Union(Matrix{Float16}, Matrix{Float32}, Matrix{Float64})

function foobar(a::FloatArrays, b::FloatArrays)

Am I making this problem more complicated than it needs to be? What is the 
correct way to do this?

[julia-users] Easy way to declare function works on array of floats

[James Crist]

I've been struggling with this for a while, and haven't found a way to do 
it that I'm happy with. I'm sure there is one though. Basically, I want to 
declare a function that works on an array of floats. Doesn't matter what 
kind of float. Doesn't matter if there are 2 different kinds of float 
arrays.

For example, if `a` is an array of Float64, and `b` is an array of Float32, 
the function foobar(a, b) should work, just as well as f(a, a) or f(b, b). 
I've gotten a couple ways to work, but am not sure what's the most Julian, 
and have to believe there is a better way:

1.) Parametric definition. This gets really long if there are multiple 
different Matrices in the call.
function foobar{T<:FloatingPoint, S<:FloatingPoint}(a::Matrix{T}, b::Matrix{
S})

2.) Type union definition. Not sure if this is optimal or not. It also will 
only work with the initial defined floats, so anything that subtypes 
FloatingPoint later on will not be valid
FloatArrays = Union(Matrix{Float16}, Matrix{Float32}, Matrix{Float64})

function foobar(a::FloatArrays, b::FloatArrays)

Am I making this problem more complicated than it needs to be? What is the 
correct way to do this?

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

Thanks for the tip! I knew this should be possible (even with a bit of 
work). Looking through the github issues and PRs, it looks like this 
functionality is slated for 0.3. I've been using 0.2. Suppose it's time to 
upgrade to the nightlies... :)

-Jim

On Tuesday, March 25, 2014 6:47:02 PM UTC-5, andrew cooke wrote:
>
>
> references
>
> https://groups.google.com/forum/#!msg/julia-users/Ui977brdzAU/u4rWiDeJv-MJ
> https://github.com/andrewcooke/IntModN.jl
>
>
> On Tuesday, 25 March 2014 20:19:32 UTC-3, andrew cooke wrote:
>>
>>
>> something like this does work:
>>
>> julia> using IntModN
>>
>> julia> a = [GF2(1) GF2(1); GF2(0) GF2(1)]
>> 2x2 Array{ZField{2,Int64},2}:
>>  1  1
>>  0  1
>>
>> ulia> b = inv(a)
>> 2x2 Array{ZField{2,Int64},2}:
>>  1  1
>>  0  1
>>
>> julia> b * a
>> 2x2 Array{ZField{2,Int64},2}:
>>  1  0
>>  0  1
>>
>>
>> that's all GF(2), not integers.
>>
>> i do subclass Number (i can't remember why, but it's necessary).  i also 
>> have promotion *from* Int, so that you can add and compare against constant 
>> integers in the code (typically 0 and 1).
>>
>> andrew
>>
>>
>> On Tuesday, 25 March 2014 13:18:06 UTC-3, Andreas Noack Jensen wrote:
>>>
>>> Okay. Now I understand what is going on. I would like something like 
>>> this to work. I'll have to go now, but will think about what to do.
>>>
>>>
>>> 2014-03-25 16:40 GMT+01:00 James Crist :
>>>
>>>> I just realized that my test case is obviously singular, so not 
>>>> invertible. But I don't think it even gets to the actual inversion code 
>>>> before erroring, so I doubt that's the problem.
>>>>
>>>> -Jim
>>>>
>>>>
>>>> On Tuesday, March 25, 2014 10:38:45 AM UTC-5, James Crist wrote:
>>>>>
>>>>> Here's the gist: https://gist.github.com/jcrist/ad663d6bdc4d82896176
>>>>>
>>>>> I tried to simplify everything down to just the bare essentials, but 
>>>>> there may be something I missed. Gives the same error as it did in the 
>>>>> full
>>>>> code though, so I think I got it all.
>>>>>
>>>>> I'm running version 0.2.0.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Jim
>>>>>
>>>>> On Tuesday, March 25, 2014 10:21:10 AM UTC-5, Andreas Noack Jensen 
>>>>> wrote:
>>>>>>
>>>>>> A gist would be helpful. By the way, which version of Julia are you 
>>>>>> running?
>>>>>>
>>>>>>
>>>>>> 2014-03-25 16:19 GMT+01:00 James Crist :
>>>>>>
>>>>>>> I'm probably not. New to this language, still figuring things out. 
>>>>>>> The matrix type seems to be inferred correctly though. I'll put a gist 
>>>>>>> up 
>>>>>>> in a bit to try and get some more relevant feedback.
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, March 25, 2014 9:54:53 AM UTC-5, Andreas Noack Jensen 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I don't think you are right about LAPACK. The code tries to promote 
>>>>>>>> to a type which is stable under lu factorizing which is the 
>>>>>>>> intermediate 
>>>>>>>> step in the calculation. The problem could be that your matrix type is 
>>>>>>>> not 
>>>>>>>> inferred correctly. Please try to let your type by subtype of Number 
>>>>>>>> and 
>>>>>>>> then define your matrix by
>>>>>>>>
>>>>>>>> a = Mytype[mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>>>>>
>>>>>>>> and see if it works.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-03-25 15:29 GMT+01:00 James Crist :
>>>>>>>>
>>>>>>>> Yeah, I get a "ERROR: no method Triangular{..." error, because my 
>>>>>>>>> type doesn't subtype Number. If I do subtype number, then it wants a 
>>>>>>>>> conversion function to convert it to a float, so it can use the 
>>>>>>>>

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

Cool. Thanks a bunch. If there is some way this could be made to work 
without subtyping Number, that would be even better. While all numeric 
operators work on this type, they aren't really numbers, and treating them 
as such elsewhere may cause problems.

-Jim

On Tuesday, March 25, 2014 11:18:06 AM UTC-5, Andreas Noack Jensen wrote:
>
> Okay. Now I understand what is going on. I would like something like this 
> to work. I'll have to go now, but will think about what to do.
>
>
> 2014-03-25 16:40 GMT+01:00 James Crist >:
>
>> I just realized that my test case is obviously singular, so not 
>> invertible. But I don't think it even gets to the actual inversion code 
>> before erroring, so I doubt that's the problem.
>>
>> -Jim
>>
>>
>> On Tuesday, March 25, 2014 10:38:45 AM UTC-5, James Crist wrote:
>>>
>>> Here's the gist: https://gist.github.com/jcrist/ad663d6bdc4d82896176
>>>
>>> I tried to simplify everything down to just the bare essentials, but 
>>> there may be something I missed. Gives the same error as it did in the full
>>> code though, so I think I got it all.
>>>
>>> I'm running version 0.2.0.
>>>
>>> Thanks,
>>>
>>> -Jim
>>>
>>> On Tuesday, March 25, 2014 10:21:10 AM UTC-5, Andreas Noack Jensen wrote:
>>>>
>>>> A gist would be helpful. By the way, which version of Julia are you 
>>>> running?
>>>>
>>>>
>>>> 2014-03-25 16:19 GMT+01:00 James Crist :
>>>>
>>>>> I'm probably not. New to this language, still figuring things out. The 
>>>>> matrix type seems to be inferred correctly though. I'll put a gist up in 
>>>>> a 
>>>>> bit to try and get some more relevant feedback.
>>>>>
>>>>>
>>>>> On Tuesday, March 25, 2014 9:54:53 AM UTC-5, Andreas Noack Jensen 
>>>>> wrote:
>>>>>
>>>>>> I don't think you are right about LAPACK. The code tries to promote 
>>>>>> to a type which is stable under lu factorizing which is the intermediate 
>>>>>> step in the calculation. The problem could be that your matrix type is 
>>>>>> not 
>>>>>> inferred correctly. Please try to let your type by subtype of Number and 
>>>>>> then define your matrix by
>>>>>>
>>>>>> a = Mytype[mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>>>
>>>>>> and see if it works.
>>>>>>
>>>>>>
>>>>>> 2014-03-25 15:29 GMT+01:00 James Crist :
>>>>>>
>>>>>> Yeah, I get a "ERROR: no method Triangular{..." error, because my 
>>>>>>> type doesn't subtype Number. If I do subtype number, then it wants a 
>>>>>>> conversion function to convert it to a float, so it can use the LAPACK 
>>>>>>> routines.
>>>>>>>
>>>>>>> -Jim
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, March 25, 2014 9:22:29 AM UTC-5, Andreas Noack Jensen 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Have you tried to invert it? Maybe it works already. There is a 
>>>>>>>> generic inv in base/linalg/generic.jl. You'll have to define a one 
>>>>>>>> method 
>>>>>>>> for you type and maybe also a zero method.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2014-03-25 15:14 GMT+01:00 James Crist :
>>>>>>>>
>>>>>>>> I have a type I've defined. It's not a number, but it has all 
>>>>>>>>> arithmetic operations defined for it. Is there a way to calculate the 
>>>>>>>>> inverse of a matrix of a user defined type? For example, if I was to 
>>>>>>>>> define:
>>>>>>>>>
>>>>>>>>> a = [mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>>>>>> b = inv(a)
>>>>>>>>>
>>>>>>>>> Looking through base, there doesn't seem to be a way to find 
>>>>>>>>> inverses of non-numeric matrices (although I may be missing it). For 
>>>>>>>>> my 
>>>>>>>>> case, even a simple algorithm that only works well for small matrices 
>>>>>>>>> (<10x10) would be more than sufficient. If a way for doing this 
>>>>>>>>> doesn't 
>>>>>>>>> currently exist, I'll probably try to roll my own.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Med venlig hilsen
>>>>>>>>
>>>>>>>> Andreas Noack Jensen
>>>>>>>>  
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Med venlig hilsen
>>>>>>
>>>>>> Andreas Noack Jensen
>>>>>>  
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Med venlig hilsen
>>>>
>>>> Andreas Noack Jensen
>>>>  
>>>
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

I just realized that my test case is obviously singular, so not invertible. 
But I don't think it even gets to the actual inversion code before 
erroring, so I doubt that's the problem.

-Jim

On Tuesday, March 25, 2014 10:38:45 AM UTC-5, James Crist wrote:
>
> Here's the gist: https://gist.github.com/jcrist/ad663d6bdc4d82896176
>
> I tried to simplify everything down to just the bare essentials, but there 
> may be something I missed. Gives the same error as it did in the full
> code though, so I think I got it all.
>
> I'm running version 0.2.0.
>
> Thanks,
>
> -Jim
>
> On Tuesday, March 25, 2014 10:21:10 AM UTC-5, Andreas Noack Jensen wrote:
>>
>> A gist would be helpful. By the way, which version of Julia are you 
>> running?
>>
>>
>> 2014-03-25 16:19 GMT+01:00 James Crist :
>>
>>> I'm probably not. New to this language, still figuring things out. The 
>>> matrix type seems to be inferred correctly though. I'll put a gist up in a 
>>> bit to try and get some more relevant feedback.
>>>
>>>
>>> On Tuesday, March 25, 2014 9:54:53 AM UTC-5, Andreas Noack Jensen wrote:
>>>
>>>> I don't think you are right about LAPACK. The code tries to promote to 
>>>> a type which is stable under lu factorizing which is the intermediate step 
>>>> in the calculation. The problem could be that your matrix type is not 
>>>> inferred correctly. Please try to let your type by subtype of Number and 
>>>> then define your matrix by
>>>>
>>>> a = Mytype[mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>
>>>> and see if it works.
>>>>
>>>>
>>>> 2014-03-25 15:29 GMT+01:00 James Crist :
>>>>
>>>> Yeah, I get a "ERROR: no method Triangular{..." error, because my type 
>>>>> doesn't subtype Number. If I do subtype number, then it wants a 
>>>>> conversion 
>>>>> function to convert it to a float, so it can use the LAPACK routines.
>>>>>
>>>>> -Jim
>>>>>
>>>>>
>>>>> On Tuesday, March 25, 2014 9:22:29 AM UTC-5, Andreas Noack Jensen 
>>>>> wrote:
>>>>>
>>>>>> Have you tried to invert it? Maybe it works already. There is a 
>>>>>> generic inv in base/linalg/generic.jl. You'll have to define a one 
>>>>>> method 
>>>>>> for you type and maybe also a zero method.
>>>>>>
>>>>>>
>>>>>> 2014-03-25 15:14 GMT+01:00 James Crist :
>>>>>>
>>>>>> I have a type I've defined. It's not a number, but it has all 
>>>>>>> arithmetic operations defined for it. Is there a way to calculate the 
>>>>>>> inverse of a matrix of a user defined type? For example, if I was to 
>>>>>>> define:
>>>>>>>
>>>>>>> a = [mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>>>> b = inv(a)
>>>>>>>
>>>>>>> Looking through base, there doesn't seem to be a way to find 
>>>>>>> inverses of non-numeric matrices (although I may be missing it). For my 
>>>>>>> case, even a simple algorithm that only works well for small matrices 
>>>>>>> (<10x10) would be more than sufficient. If a way for doing this doesn't 
>>>>>>> currently exist, I'll probably try to roll my own.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Med venlig hilsen
>>>>>>
>>>>>> Andreas Noack Jensen
>>>>>>  
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Med venlig hilsen
>>>>
>>>> Andreas Noack Jensen
>>>>  
>>>
>>
>>
>> -- 
>> Med venlig hilsen
>>
>> Andreas Noack Jensen
>>  
>

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

Here's the gist: https://gist.github.com/jcrist/ad663d6bdc4d82896176

I tried to simplify everything down to just the bare essentials, but there 
may be something I missed. Gives the same error as it did in the full
code though, so I think I got it all.

I'm running version 0.2.0.

Thanks,

-Jim

On Tuesday, March 25, 2014 10:21:10 AM UTC-5, Andreas Noack Jensen wrote:
>
> A gist would be helpful. By the way, which version of Julia are you 
> running?
>
>
> 2014-03-25 16:19 GMT+01:00 James Crist >:
>
>> I'm probably not. New to this language, still figuring things out. The 
>> matrix type seems to be inferred correctly though. I'll put a gist up in a 
>> bit to try and get some more relevant feedback.
>>
>>
>> On Tuesday, March 25, 2014 9:54:53 AM UTC-5, Andreas Noack Jensen wrote:
>>
>>> I don't think you are right about LAPACK. The code tries to promote to a 
>>> type which is stable under lu factorizing which is the intermediate step in 
>>> the calculation. The problem could be that your matrix type is not inferred 
>>> correctly. Please try to let your type by subtype of Number and then define 
>>> your matrix by
>>>
>>> a = Mytype[mytype(1) mytype(2); mytype(3) mytype(4)]
>>>
>>> and see if it works.
>>>
>>>
>>> 2014-03-25 15:29 GMT+01:00 James Crist :
>>>
>>> Yeah, I get a "ERROR: no method Triangular{..." error, because my type 
>>>> doesn't subtype Number. If I do subtype number, then it wants a conversion 
>>>> function to convert it to a float, so it can use the LAPACK routines.
>>>>
>>>> -Jim
>>>>
>>>>
>>>> On Tuesday, March 25, 2014 9:22:29 AM UTC-5, Andreas Noack Jensen wrote:
>>>>
>>>>> Have you tried to invert it? Maybe it works already. There is a 
>>>>> generic inv in base/linalg/generic.jl. You'll have to define a one method 
>>>>> for you type and maybe also a zero method.
>>>>>
>>>>>
>>>>> 2014-03-25 15:14 GMT+01:00 James Crist :
>>>>>
>>>>> I have a type I've defined. It's not a number, but it has all 
>>>>>> arithmetic operations defined for it. Is there a way to calculate the 
>>>>>> inverse of a matrix of a user defined type? For example, if I was to 
>>>>>> define:
>>>>>>
>>>>>> a = [mytype(1) mytype(2); mytype(3) mytype(4)]
>>>>>> b = inv(a)
>>>>>>
>>>>>> Looking through base, there doesn't seem to be a way to find inverses 
>>>>>> of non-numeric matrices (although I may be missing it). For my case, 
>>>>>> even a 
>>>>>> simple algorithm that only works well for small matrices (<10x10) would 
>>>>>> be 
>>>>>> more than sufficient. If a way for doing this doesn't currently exist, 
>>>>>> I'll 
>>>>>> probably try to roll my own.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Med venlig hilsen
>>>>>
>>>>> Andreas Noack Jensen
>>>>>  
>>>>
>>>
>>>
>>> -- 
>>> Med venlig hilsen
>>>
>>> Andreas Noack Jensen
>>>  
>>
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

I'm probably not. New to this language, still figuring things out. The 
matrix type seems to be inferred correctly though. I'll put a gist up in a 
bit to try and get some more relevant feedback.

On Tuesday, March 25, 2014 9:54:53 AM UTC-5, Andreas Noack Jensen wrote:
>
> I don't think you are right about LAPACK. The code tries to promote to a 
> type which is stable under lu factorizing which is the intermediate step in 
> the calculation. The problem could be that your matrix type is not inferred 
> correctly. Please try to let your type by subtype of Number and then define 
> your matrix by
>
> a = Mytype[mytype(1) mytype(2); mytype(3) mytype(4)]
>
> and see if it works.
>
>
> 2014-03-25 15:29 GMT+01:00 James Crist >:
>
>> Yeah, I get a "ERROR: no method Triangular{..." error, because my type 
>> doesn't subtype Number. If I do subtype number, then it wants a conversion 
>> function to convert it to a float, so it can use the LAPACK routines.
>>
>> -Jim
>>
>>
>> On Tuesday, March 25, 2014 9:22:29 AM UTC-5, Andreas Noack Jensen wrote:
>>
>>> Have you tried to invert it? Maybe it works already. There is a generic 
>>> inv in base/linalg/generic.jl. You'll have to define a one method for you 
>>> type and maybe also a zero method.
>>>
>>>
>>> 2014-03-25 15:14 GMT+01:00 James Crist :
>>>
>>> I have a type I've defined. It's not a number, but it has all arithmetic 
>>>> operations defined for it. Is there a way to calculate the inverse of a 
>>>> matrix of a user defined type? For example, if I was to define:
>>>>
>>>> a = [mytype(1) mytype(2); mytype(3) mytype(4)]
>>>> b = inv(a)
>>>>
>>>> Looking through base, there doesn't seem to be a way to find inverses 
>>>> of non-numeric matrices (although I may be missing it). For my case, even 
>>>> a 
>>>> simple algorithm that only works well for small matrices (<10x10) would be 
>>>> more than sufficient. If a way for doing this doesn't currently exist, 
>>>> I'll 
>>>> probably try to roll my own.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Med venlig hilsen
>>>
>>> Andreas Noack Jensen
>>>  
>>
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

[julia-users] Inverse of a matrix of user defined type?

[James Crist]

I have a type I've defined. It's not a number, but it has all arithmetic 
operations defined for it. Is there a way to calculate the inverse of a 
matrix of a user defined type? For example, if I was to define:

a = [mytype(1) mytype(2); mytype(3) mytype(4)]
b = inv(a)

Looking through base, there doesn't seem to be a way to find inverses of 
non-numeric matrices (although I may be missing it). For my case, even a 
simple algorithm that only works well for small matrices (<10x10) would be 
more than sufficient. If a way for doing this doesn't currently exist, I'll 
probably try to roll my own.

Re: [julia-users] Inverse of a matrix of user defined type?

[James Crist]

Yeah, I get a "ERROR: no method Triangular{..." error, because my type 
doesn't subtype Number. If I do subtype number, then it wants a conversion 
function to convert it to a float, so it can use the LAPACK routines.

-Jim

On Tuesday, March 25, 2014 9:22:29 AM UTC-5, Andreas Noack Jensen wrote:
>
> Have you tried to invert it? Maybe it works already. There is a generic 
> inv in base/linalg/generic.jl. You'll have to define a one method for you 
> type and maybe also a zero method.
>
>
> 2014-03-25 15:14 GMT+01:00 James Crist >:
>
>> I have a type I've defined. It's not a number, but it has all arithmetic 
>> operations defined for it. Is there a way to calculate the inverse of a 
>> matrix of a user defined type? For example, if I was to define:
>>
>> a = [mytype(1) mytype(2); mytype(3) mytype(4)]
>> b = inv(a)
>>
>> Looking through base, there doesn't seem to be a way to find inverses of 
>> non-numeric matrices (although I may be missing it). For my case, even a 
>> simple algorithm that only works well for small matrices (<10x10) would be 
>> more than sufficient. If a way for doing this doesn't currently exist, I'll 
>> probably try to roll my own.
>>
>
>
>
> -- 
> Med venlig hilsen
>
> Andreas Noack Jensen
>  

Re: [julia-users] Re: Control system library for Julia?

[James Crist]

@Tony,

I agree on pulling from the debian repo. Doesn't make sense to rehost code. 
The only things that need to be changed are the build process, and the 
alternate xerbla.f file. Perhaps the makefiles and the xerbla subroutine 
could live in the git repo, and julia could just switch them out?

@Simon,

I initially started off using the polynomial package, but stopped due to 
its limitations and some design decisions. I may try to integrate my added 
functions and send them a pull request. As for the DSP library, nice work! 
The python control package integrates nicely with scipy's dsp functions, 
perhaps there's a way we could do the same? Two thoughts on this:

1.) Conversion function between DSP types and control types
- or -
2.) Same base type for both DSP TF and control TF (they're basically the 
same)

For ease of use, I'm leaning towards the first one. Does DSP.jl support 
mimo systems? 

For those interested in helping, perhaps we should move this discussion 
somewhere else? Not sure if github issues are the best way to communicate, 
or if a google group should be started up.

-Jim


On Friday, February 21, 2014 5:40:52 PM UTC-6, Simon Kornblith wrote:
>
> This is great! ss2tf and potentially other functionality is also relevant 
> to DSP more generally. We currently have conversions between most standard 
> filter representations in DSP.jl (see 
> https://github.com/JuliaDSP/DSP.jl/blob/master/src/filter_design.jl) but 
> no state space representation. There is also a Polynomial package (
> https://github.com/vtjnash/Polynomial.jl) that may be a good place for 
> polynomial-related functions to live.
>
> Simon
>
> On Friday, February 21, 2014 1:11:19 AM UTC-5, James Crist wrote:
>>
>> Hello all,
>>
>> Glad to see there's some interest in this. I'm the one behind 
>> https://github.com/jcrist/Control.jl.
>>
>> I've been working through the getting the base types defined, before 
>> starting work on the analysis functions. The first goal is to get something 
>> simliar to matlab's basic control toolbox, with all the commands that an 
>> undergrad would use in an intro course. After that, higher level stuff will 
>> be tackled. Both Python control and Octave's control toolbox have been 
>> serving as inspiration. It's surprising (not really actually) how easily 
>> most of this transposes into julia.
>>
>> I need to get ready for a seminar I'm giving tomorrow, but over the 
>> weekend I plan to commit a major refactoring of the base types 
>> (TransferFunction and StateSpace) to make them more julia-friendly (python 
>> has pythonic, what's the julia version?). After that, it should be fairly 
>> trivial for others to write functions that work on these types.
>>
>> Slicot will be used to do all the heavy lifting, because it's free* and 
>> why bother reinventing the wheel. I have a set of wrappers that I generated 
>> for the raw interface that still need a human to look over them. I was 
>> planning on doing it as I got to using individual functions, but that'd be 
>> an easy thing to look through for others.
>>
>> - - - - -
>>
>> Major quesion of the moment: what plotting library is best plotting 
>> library? I'm coming from heavy python usage, so winston's syntax is more 
>> friendly to me.  But gadfly looks great as well. I'd rather not use pyplot 
>> - I'd like to keep it as much in julia as possible. Thoughts?
>>
>> -Jim
>>
>> *Slicot (per they're website) is no longer GPL after version 4.5. 
>> However, the debian repo has 5.0, and the tar ball I got contains a GPL2 
>> license. Not sure what to make of this. The most recent free version should 
>> definitely be the one used.
>>  
>> On Thursday, February 20, 2014 9:25:10 PM UTC-6, Jeremy West wrote:
>>>
>>> I guess somebody got impatient with my disappearance :) I'll probably 
>>> contribute to that instead, it looks like a similar roadmap I had in mind 
>>> before things got messy.
>>> On Feb 20, 2014 8:00 PM, "Tony Kelman"  wrote:
>>>
>>>> Well and at least a start on some useful functionality, to get 
>>>> everybody in the same place and not duplicating the initial effort.
>>>>
>>>> Those kite power projects are so incredibly cool! I imagine you're 
>>>> using some combination of Casadi, Acado, and/or Optimica?
>>>>
>>>> I do model predictive control at Berkeley, we have our own custom 
>>>> Matlab/Simulink tools that work pretty well for our uses but longer-term 
>>>> I'd 

Re: [julia-users] Re: Control system library for Julia?

[James Crist]

Hello all,

Glad to see there's some interest in this. I'm the one behind 
https://github.com/jcrist/Control.jl.

I've been working through the getting the base types defined, before 
starting work on the analysis functions. The first goal is to get something 
simliar to matlab's basic control toolbox, with all the commands that an 
undergrad would use in an intro course. After that, higher level stuff will 
be tackled. Both Python control and Octave's control toolbox have been 
serving as inspiration. It's surprising (not really actually) how easily 
most of this transposes into julia.

I need to get ready for a seminar I'm giving tomorrow, but over the weekend 
I plan to commit a major refactoring of the base types (TransferFunction 
and StateSpace) to make them more julia-friendly (python has pythonic, 
what's the julia version?). After that, it should be fairly trivial for 
others to write functions that work on these types.

Slicot will be used to do all the heavy lifting, because it's free* and why 
bother reinventing the wheel. I have a set of wrappers that I generated for 
the raw interface that still need a human to look over them. I was planning 
on doing it as I got to using individual functions, but that'd be an easy 
thing to look through for others.

- - - - -

Major quesion of the moment: what plotting library is best plotting 
library? I'm coming from heavy python usage, so winston's syntax is more 
friendly to me.  But gadfly looks great as well. I'd rather not use pyplot 
- I'd like to keep it as much in julia as possible. Thoughts?

-Jim

*Slicot (per they're website) is no longer GPL after version 4.5. However, 
the debian repo has 5.0, and the tar ball I got contains a GPL2 license. 
Not sure what to make of this. The most recent free version should 
definitely be the one used.
 
On Thursday, February 20, 2014 9:25:10 PM UTC-6, Jeremy West wrote:
>
> I guess somebody got impatient with my disappearance :) I'll probably 
> contribute to that instead, it looks like a similar roadmap I had in mind 
> before things got messy.
> On Feb 20, 2014 8:00 PM, "Tony Kelman" > 
> wrote:
>
>> Well and at least a start on some useful functionality, to get everybody 
>> in the same place and not duplicating the initial effort.
>>
>> Those kite power projects are so incredibly cool! I imagine you're using 
>> some combination of Casadi, Acado, and/or Optimica?
>>
>> I do model predictive control at Berkeley, we have our own custom 
>> Matlab/Simulink tools that work pretty well for our uses but longer-term 
>> I'd rather have something more elegant (and in an open environment) that 
>> doesn't have to work around Matlab's limitations and Simulink's 10+ 
>> subtly-incompatible but still-in-common-use versions.
>>
>>
>> On Thursday, February 20, 2014 4:08:54 PM UTC-8, Uwe Fechner wrote:
>>>
>>>  Hi,
>>>
>>> this looks already promising. The important thing is to get started and 
>>> to have an issue tracker, and with this
>>> git repo this is already in place.
>>>
>>> I am currently working on automated control of kite-power systems. A 
>>> little video about our
>>> project: http://www.youtube.com/watch?v=FJmlt3_dOuA
>>>
>>> Best regards:
>>>
>>> Uwe
>>>
>>> Am 21.02.2014 00:24, schrieb Tony Kelman:
>>>  
>>> Have a look here, https://github.com/jcrist/Control.jl is making better 
>>> progress than anything else I've found in the topic. He has wrappers to 
>>> Slicot as well.
>>>
>>> On Thursday, February 20, 2014 1:56:20 PM UTC-8, Uwe Fechner wrote: 

 Hello,

 I could not find any control system library for Julia yet. Would that 
 make sense?
 There is a control system library available for Python:
 http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control

 Perhaps this could be used as starting point? I think that implementing 
 this in Julia
 should be easier and faster than in Python.

 Any comments?
 Should I open a feature request?

 Uwe Fechner, TU Delft, The Netherlands
  
>>>  
>>>