[WIP] Exp2

[oxinabox]

So, we have to start somewhere.
Why not with Exp2?
(Edit: Ah, I see while I wasn't looking, @musm got in ahead of me. Twice. 👍
Well we have to think about a 3rd function sometime, why not Exp2?)

This brings that over from OpenLibm

Right now this WIP,
I have it working with Float64s
I'll then get it working with Float32s,
and then I'll see about refactoring them to merge common code.

Before this is done, it might be desirable to cherry-pick and merge the stuff from math_private,
which does some of the word manipulation that OpenLibm is full of.
Its not quiet the same as the one @musm wrote. I think getting that stuff in is probably a priority if more porting of OpenLibm is to be done.

I think maybe we can actually go faster on 64 bit systems by doing less 3 2bit word manipulation, and manipulating all 64bits at a time.
But first to get it going, then tweak it.

In part, this is more to see what it would look like, than to actually get things moved across.
Particularly pending #5

[oxinabox]

So anyway, things to take away from this (and also from looking at @musm's fine work.
I'm going to note these here; since my motivation for porting this was to learn and see these things in play.

Namespacing constants

C code in msun/openlibm etc has all non-externed varibles as "file-private",
so it full of constants that only make sense in that file; and clobber (overwrite) constants from other files if you just include(file.jl) them.
So we need to namespace our constants.

Ways perhaps this can be done (each of which could perhaps be does partially with a macro that makes it simpler):

• 1 module per constant set, and only export the functions
  • this seems bad particularly as to have say a macro that generalises exp(::Float32), exp(::Float64), and exp2 and exp10 etc. would require a module to hold the macro, which itself contains 6 more modules. There are very few nested modules in julia, we should probably stick to that.
• Let blocks.
  • If all the constants are declared as parameters to the let block, that would lexically scope them, and keep them safe from being clobbered.
  • I've never seen a let block actually used in julia code, beyond a trivial example
  • the let block constants could be huge
• Bring them inside the functions
  • I have no idea how this is gonna play with the stack, and heap (Particularly for constants of arrays)
  • If there are constants share between some, but not all functions this brings us back to where we were.
• "Manual" namespacing where the names are declared to be unique, so rather than P1, P2 etc you would have in exp2.jl: exp2_P1, exp2_P2... and in exp10.jl, you would have exp10_P1 and exp10_P2
  • This sounds like a job for Macros, and Base.@gensym. But macro heavy code, is not nice to read, or edit

I can envision some really macro heavy ways to do the above that are particularly magic filled.

[simonbyrne]

let blocks are probably the easiest, and they are used in Base, e.g.
https://github.com/JuliaLang/julia/blob/03e7c798f9a0a5f3606abc0364b1a622218eb0c8/base/special/bessel.jl#L9-L11

The approach is

let
    const bar = ...
    global foo
    function foo(x)
       # uses bar
    end
end

[simonbyrne]

This needs to be rebased

[oxinabox]

This needs to be rebased

Yes it does.

I'm not particularly interested in having it merged.
It was more for the understanding/learning about the problem domain.
(A "spike" to use agile terminology)

I can, if you want rebase it,
clean it up and make it merge-able. (Re: put it in a let block, in a module etc).
(Would have to write the Float32 part first)

[simonbyrne]

Certainly, it would be good to have this.

[simonbyrne]

Note there is a problem with defining generic methods which are dispatched inside let blocks: JuliaLang/julia#18201

In that case, I suggest just prefixing them with an underscore.

[oxinabox]

I'm closing this because, I don't particularly care to deal with rebasing it and making it work.
It was more an experiment in design than actual working code.