simonbyrne

Well, I have indeed spent more time thinking about this than is probably healthy, but here are some nice edge cases to think about:

- https://github.com/JuliaLang/julia/issues/14826

    mod(-eps(), 4.0)

- https://github.com/JuliaLang/julia/issues/17415

    fld(1.0,0.2)

- https://github.com/JuliaLang/julia/issues/3127

    mod(1.0,0.1)

- https://github.com/JuliaLang/julia/issues/3104

    mod(0.95,0.01)

I'm pretty sure there are more issues.

re: mod 2pi, typically it is most accurate to reduce to (-pi,pi) (i.e. division rounding to nearest). Also to get it accurate you need fancy range reduction algorithms, hence julia has rem2pi https://docs.julialang.org/en/stable/base/math/#Base.Math.re...

I take the opinion that people should have the option to round division (and compute remainders) however they want: down, up, to zero, to nearest (with different options for breaking ties).

https://github.com/JuliaLang/julia/issues/9283

The other point is that remainder makes much more sense for floating point numbers, as it's exact. mod on the other hand is not, and is fiendishly difficult to get "right" (if that is even possible).

I guess because remainder is simpler to implement? (anecdotally, the assembly generated by @code_native in Julia is much shorter for remainder)

In my opinion neither are used sufficiently often to justify taking up a valuable ASCII symbol (same with xor).

We would love to have more professional programmers contribute: unfortunately those 1-based indices put them off.

More seriously: part of the problem does seem to be that Julia does have some significant differences from "traditional" languages (e.g. the concept of a "virtual method" is a bit fuzzy in Julia, what we call a JIT is probably better described as a JAOT, whether it has a "type system", homoiconicity, etc.).

That said, this JuliaCon I have met a lot more people from and classical "programmer" backgrounds. So hopefully that is changing.

Out of curiosity: what language has a package ecosystem that in your opinion does do this right?

Also, I was actually a postdoc...

What language defines % as mod and not remainder?

> I really want my zeroth frequency in my zeroth bin

That's precisely what it does!

> I also cringe at languages where -1 mod N does not equal N-1.

julia> mod(-1,10)

9

Well for FFTs you really want periodic indices. Luckily Julia has those too: https://github.com/JuliaArrays/FFTViews.jl

Actually, you can try 0.7: this is more or less equivalent, but is backwards compatible with 0.6 (it will warn when incompatible uses are used).

Of course, more time would have been nice, but you can always find a reason for a delay. At some point you have to rip off the bandaid.

A slight quibble: FFTs are more naturally indexed periodically. Luckily, Julia has that covered: https://github.com/JuliaArrays/FFTViews.jl

No, just need to wait for IJulia to be updated. I imagine it will be a day or two.

It turns out that compilers are pretty good at eliding constant integer offsets.

I don't think _any_ language has got exception handling handling right yet, despite a lot of effort. The problems are particularly apparent in parallel and multithreaded programs.

That said, I am optimistic Julia will have a good solution at some point: contextual dispatch, a la Cassette.jl, enables just the sought of interventions you want for error handling. I'm not quite sure what the result will look like, but I imagine you will see some experimentation in this direction in the near future.

I've heard this before: what is F#'s main draw over other functional languages in finance? Is it simply that it comes already bundled with .NET?

Conversely, the worlds most widely used financial software (Microsoft Excel) uses binary floating point under the hood.

I'm not really sure, but from a quick skim it seems that the Intel library provides standard math functions (log, exp, sin, etc.), whereas the speleotrove library does not. Also the speleotrove one doesn't appear to have been updated since 2010.

Also, you force people to take a break. It's pretty common in finance to require a 2 week consecutive holiday every so often: one justification being that if someone was cooking the books, the person taking over their role would probably stumble across it.

Your best bet might be wrapping the Intel decimal floating point library: https://software.intel.com/en-us/articles/intel-decimal-floa...

This is a software implementation of the standardized IEEE decimal format.

They weren't trying to replace the system, just emulate it for testing and simulation purposes: e.g. test how new rates would affect existing policy holders.

Insurance policies (the contracts) just have final premiums (sometimes they might split it out by risk), but they don't typically explain how the insurer arrived at that number.

There is a little more to it than "languages don't provide decimal or fixed point". Both Java and Python provide decimal implementations as part of their standard libraries, and languages don't provide fixed-point as it's largely trivial: "just do integer operations and scale them appropriately".

The problem is that fixed point is ambiguous: there are multiple ways to do rounding (unlike floating point which has been largely standardised since the early 90s). In fact, the COBOL rounding rules are rather complicated: https://stackoverflow.com/a/30215718/392585

This has some interesting consequences:

I know of an insurance company where there were difficulties trying to replicate the exact premium calculation (which was done on a mainframe in COBOL), part of which involved taking 1.01 to the power of a positive integer (which depended on various risk factors of the policy).

COBOL was not really intended for numerical work, and so doesn't have a "pow" function (or at least this version didn't): instead, it turns out that the programmer had used a simple loop which would iteratively multiply a variable by 1.01, incurring round-off at each iteration. So the only way to emulate it exactly was to use the same arithmetic _and_ the same ugly hacks used in the original software.

I've recently moved to the US from the UK, and I've had several Americans mention that they would like to visit Europe but are worried about the danger of terrorism. I tried to explain that any increased risk of terrorism is massively outweighed by the large decrease in risk of dying in a car accident, but that wasn't terribly successful.

It also introduces interesting financial arrangements. e.g. rather than profiting on the electricity directly, they make more money by selling options to sell at a fixed price at peak times.

Ah, I should have done more googling. I guess the AVX-512 ones are marginally more accurate?

It is worth noting that with AVX-512, Intel has introduced a native inverse sqrt approximation (VRSQRT14).

Well, in Julia it's an incomplete expression (Y is a variable, % is the infix operator for remainder, and # a line comment (the $ is used for string/command interpolation, but is commented out).

Even reinsurance has limits, and large earthquakes on major metropolitan centres are basically the one thing that will exceed them (floods can be bad too, but the risks are more predictable, and are often excluded from policies in high-risk areas).

The only alternative to the "government backstop" is that insurers will refuse to write policies or will exclude earthquake risk (in which case the government may need to set up it's own scheme, e.g. in CEA insurance in California).

Not generally: most compilers make use of the SSE instruction set which doesn't have extended precision. Occasionally old versions of gcc on 32-bit machines will still use the old x87 instructions (which do have extended precision), but these are becoming increasingly rare in the wild.

No kidding: this is a problem with signed integers as well: C allows signed magnitude, ones' complement, and two’s complement representations, but no mainstream compiler supports anything other than two's complement.

> In short, the only machine the author could find using non-two’s complement are made by Unisys. Nowadays they emulate their old architecture using x86 CPUs for customers who have legacy applications which they’ve been unable to migrate.

- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...