A few Package Ideas, also looking for help on getting started with julia development

[Tucker DiNapoli]

First of all, hello, I'm new here this is my first time posting anything. I'm fairly new to julia but I've been using it for a month or so and I really like it, so I'd like to help out and contribute.

I've been writing some julia code for myself, and I feel like some of it might prove useful to other people, though I could be wrong(or they might already exist). I've written some stuff for myself for a quantum physics class, so I have module thats just a set of physical constants(which I think might be a good addition to the units package) and one that's versions of some common special functions/polynomials, specifically the Lagurre and Legendre Polynomials. I've taken the algorithms from the equivlant gsl functions. Its not much, but if it seems like something someone might find useful I could add a bunch more to it and make it a package. The other thing I've been working on are Julia implementations of some data-structures/types common in standard ml(sml)(I've done a bunch of work on the MLton sml compiler). Its mostly just been for fun and to learn julia, but I've got an option module, an array pair module and a linked list, I could add some more as well.

Also if anyone has some good ideas on how to get started working on Julia or any ideas for packages related to functional programming or physics, I'd love to hear them.

Tucker DiNapoli

[Jared Kofron]

Hey Tucker,

Good luck with Julia!  I haven't had much time lately to do... anything, really, but you might want to take a peek at this:

https://github.com/kofron/Codata.jl

It wraps all of the CODATA values from NIST into a Julia module - but it's been a while.

JK

[Stefan Karpinski]

Sounds like potentially useful stuff!

I would recommend putting the stuff into GitHub repos, separated out as seems appropriate and then sending an email to the list announcing them. You can use Pkg.scaffold to stub out a git repo that's in the right format for making a package. People can actually install these as packages without them being registered as packages just by doing Pkg.clone(url). The package manager will respect their requirements if you put them in the REQUIRE file in the package repo.

On Fri, Sep 27, 2013 at 12:38 PM, Tucker DiNapoli <t.dina...@gmail.com> wrote:

I've taken the algorithms from the equivlant gsl functions.

Be sure that you keep the GPL license in this case. Pkg.scaffold doesn't support that license yet, but it's easy to add a case here to handle it:

https://github.com/JuliaLang/julia/blob/master/base/pkg/scaffold.jl

[ggggg]

Nice.  I was planning on using CODATA for constants in Physical.jl. It looks like Codata.jl will be a good starting point.

[Tucker DiNapoli]

Looking at your Physical.jl package I personally like it a bit more than the offical units package, especially the addition of uncertainties. As I've been looking for something to work on, if you don't mind I think I'll take a crack at adding Codata support to your package. I've actually been looking for an implementation of uncertainties in julia, as that's something that comes up a lot in my work. I'll start taking a look at your code, if you have any suggestions feel free to let me know.

[Tim Holy]

Briefly, here's my proposal for straightening out the burgeoning units "mess":

- Codata is a standalone package
- There are _two_ units packages: one in which everything is implemented with
immutables (a merge of mine & Keno's), and Physical. The reason we need both
is that for anyone who wants to manipulate arrays of 10^8 unit-bearing
quantities, the immutable route is probably the only feasible choice---storing
10^8 Dicts will be prohibitive. For smaller numbers of unit-bearing
quantities, basing things on Dicts is probably more flexible.
- Both units packages make use of Codata

--Tim

On Monday, September 30, 2013 06:04:59 AM Tucker DiNapoli wrote:
> Looking at your Physical.jl package I personally like it a bit more than
> the offical units package, especially the addition of uncertainties. As
> I've been looking for something to work on, if you don't mind I think I'll
> take a crack at adding Codata support to your package. I've actually been
> looking for an implementation of uncertainties in julia, as that's
> something that comes up a lot in my work. I'll start taking a look at your
> code, if you have any suggestions feel free to let me know.
>
> On Friday, September 27, 2013 4:42:32 PM UTC-4, ggggg wrote:
> > Nice. I was planning on using CODATA for constants in

> > Physical.jl<https://github.com/ggggggggg/Physical.jl>. It looks like

[ggggg]

Tim,

I think your proposal sounds fine, a few thoughts.

- Physical should be able to work from CODATA as it currently exists fairly easily. (Tucker my thoughts on how are at this issue, and detailed communication should probably go there.)

- We should probably provide a conversion function between the two unit's packages.  I'm not clear on the best practices for "glue" code. Should this wait until each version has settled down?

- Quantity{Array} stores only one dict for the whole array. Array{Quantity} allows each element to have different units, but stores a dict for each element, as you suggest this is not a good idea for large arrays.

[Stefan Karpinski]

I really don't think there should be a dict-based units package. Units should always be represented using types. I also think that non-SI units should be strictly a matter of presentation – as in the actual representation of units should always use SI, but you can ask to convert it to some other form for presentation.

[Ivar Nesje]

I agree with Stefan that the dict based approach is not what most people should use. Isn't the 7 SI base units enough?

There are at least good reasons to use scaled SI units for computation, if you want to use newton iteration or other optimization methods to solve problems with different units on the target variables. If I try to solve a thermodynamic equation for the implicit pressure and temperature, it would be nice if I could scale the unit system so that they become within the same order of magnitude.

[Tim Holy]

On Monday, September 30, 2013 01:42:25 PM Stefan Karpinski wrote:
> I also think that non-SI units
> should be strictly a matter of presentation – as in the actual
> representation of units should always use SI, but you can ask to convert it
> to some other form for presentation.

If all you're thinking about is computing with units, I agree. However, if
you're thinking about annotating with units, then somehow you need to store
the desired representation. Folks will not be thrilled if they specify that
they want a scalebar of size "10 microns" in their image, and the little
helpful text printed above the scalebar says "1e-4 meters".

So going the immutable route we need either of the following:
(A) Standardized immutable type for computation + Non-standardized type for
annotation

(B) Standardized immutable type for computation + A type that stores 2 of the
first type of object (the standardized value and the desired representation).

With the second version, you get the coefficient from uval/urepres, but you
still have the question of how you pretty-print the units value. So I think
(A) is better. That basically corresponds to merging Keno's (standardized) and
my (annotation) repositories, plus adding a converter between the two.

--Tim

[Stefan Karpinski]

The second approach seems more tenable to me – the second object is a representation of how to present data and many actual values can be used with a single presentation format object. All presentation objects have an implied SI unit, which is the type that all value objects they refer to must have. Presentation can even include how many digits of precision to present and relative to what exponent.

[ggggg]

The 7 SI base units are enough for most situations.  Adding in Radians covers more.  But there are other situations, for example if you want to keep track of quantities of different substances like mol_Al and mol_Cu or entities like photons.  Or if you want to use a different unit system such as CGS-gaussian units, which disagree with SI about what dimensions many things have.  In the majority of situations in which units are used, SI will do the trick. 

I'm all for a solid goto SI Unit package for most purposes. Hopefully this doesn't mean Physical will have to disappear, but instead can be the fallback for edge cases.

But yes, most common use cases should be fine with just the 7 SI units + Radians.

[Simon Byrne]

One problem with an SI-based system is that there are units that don't even have an SI representation (currency is one obvious example). Even if there is a representation, then there's the additional overhead of conversion, as well as possible floating point rounding error.

[Tim Holy]

That all seems reasonable to me.

--Tim

[Tim Holy]

I hadn't thought about the # of digits of precision issue, and of course
you're right that this is important, too. For an immutables-based units
package, I think that does tip the balance towards (B). Seems like we should
make SIUnits.jl the basis of the main package, and write a customized display
type around it.

I don't have a lot of time to work on this at the moment; should I do anything
like move Units.jl somewhere else? I know there was a suggestion to move
things to JuliaLang, although I am unsure whether one can grant push
privileges to a particular repository in JuliaLang without granting privileges
for the whole thing. I can also rename the repository, if we want to reserve
the name "Units.jl" for an elaborated version of what's in Keno's SIUnits.jl.
Or I can grant push privileges to Keno & Galen and we can merge into Units.jl.
Basically, I'm totally open to whatever people want to do here.

--Tim

[Tucker DiNapoli]

So I've been working on modifying Codata. I rewrote the generating function to allow the constants to be generated by a function, which takes the name of the constant, it's value, it's units and it's uncertainty as strings for arguments. I added a parameter to choose a function to generate the header file, so the write types can be defined/packages included. This should let any package use the codata values by writing up a function to generate constants of the right type. I also wrote functions to generate constants for SIUnits.jl. I added most arguments as optional arguments so by default things work exactly as they did before. I attached the file to my post, but I'm not exactly sure what the best way of going about things would be. I'm sure there a couple things that need to be fixed, but I just figured I'd let people know what I've been working on.