jpcooper

I wonder whether they came to London from The Netherlands as well. The Wikipedia page for stoop only mentions North America. Is there a different name used in England?

The Van Dale dictionary seems to list another meaning of ‘stoep’ as steps to a house. Have I understood correctly?

https://www.vandale.nl/gratis-woordenboek/nederlands/beteken...

Yes. I agree that you certainly need to write tests for algorithmic code unless you are formally proving it. I definitely would not feel safe about a data structure I wrote in Haskell without writing a large suite of tests. If your tests cover a good portion of the code, then errors arising from incorrect arguments will be quickly found. It's nice to have that eliminated by the compiler when possible though.

Thanks. That makes sense.

Bad reading comprehension on my part. Was it under the EU rules, or something else?

Can you support this claim?

The author seems not to have been able to claim what he should under these rules.

Travel cancellation insurance is a thing that exists. It would be nice to see a travel cancellation insurance product which pays out based on the following automatically and easily verifiable outcomes:

1. Customer turns up.

2. Plane leaves within a certain range around scheduled time.

3. Plane arrives at destination.

4. Plane arrives at destination within a certain range around the scheduled time.

5. The price of the trip.

6. Weather events make things difficult.

Airlines could either integrate or not.

Maybe the premiums would have to be higher due to a higher occurrence of payouts, but maybe they wouldn't have to be so high due to the number of claims processing people you now do not have to employ.

Maybe I am oversimplifying.

I think it is nice in Haskell to retain the ability to control the underlying representation of a string. The laziness allows the native linked list representation without the user having to know about the underlying representation. Your memory mapping function can simply return a lazy linked list of chars in Haskell as well. If the underlying representation turns out to be inefficient on the current system, then that can always be tuned by the user. Maybe in Prolog it is sufficient to leave all of that to the runtime system.

Thanks for the Prolog tips. I had a look at clpqr, and could not find any reference to boolean variables and operators. Maybe clpqr intersects with another system whose docs do refer to boolean variables. I could not see how to combine clpqr with clpb. Basically what I would like is for certain linear constraints to be active only if other chosen boolean expressions are true.

Example: Choose energy price based on maximum power usage over past month. There are some Japanese electricity tariffs which do this. There would be a partition of maximum power usage ranges, and each range is associated with a price. Associate a binary variable to each range. Ensure exactly one of the variables is true (sum = 1). Create a range constraint over the maximum power usage for each partition, and multiply the bounds of that constraint with the associated binary variable. When a binary variable is set to zero, you have a trivial constraint.

It is indeed possible to represent boolean constraints as linear constraints over binary variables and develop a DSL to translate in this direction. I am wondering whether a system exists which allows easy expression of linear and boolean combined, and which provides tools for solving them efficiently.

I need to find more of those.

Haskell allows you to build a (lazy) linked list of characters sourced in blocks from strict ByteStrings, which are pointers to bytes with an offset and length. Leaving out the garbage collection of the cons cells (I would hope that the cons cells are reused in some situations, but I don't know the specifics), I think this is quite a nice interface.

iolist sounds like lazy ByteStrings in Haskell. They are lists of strict ByteStrings.

Thanks for posting. I can't find it now, but we mention somewhere in the paper that typing makes it more difficult to fake messages. Typing allows you to make stronger proofs over the properties and behaviour of actor systems. Sorry if I've missed the point: What are the other direct implications to security which typing brings?

After years of using statically type checked languages like Haskell, I’ve observed that I am quite lazy. If I went to a language without static type checking today, I wouldn’t trust myself to provide the right function arguments in the right order all the time, or to send the right message types, especially after refactoring. It would be a nightmare for me to have to write unit tests for this. Maybe that would improve over time, or maybe I’m just a crap programmer.

Lots of implementations here: https://rosettacode.org/wiki/Binary_search. The J implementations are beautiful.

Without trying to sound too flamebaity, as typed versus untyped has been discussed endlessly, I would like to see a study which compares development time and reliability between a Erlang and another typed language running on BEAM. That is, typed versus untyped for the sort of systems which are built with Erlang.

The author says that he sees no need to include types in the language. There have been efforts to create typed languages which run on the Erlang BEAM virtual machine. I would be interested to know more about why the author thought that types were not useful.

Thanks for the explanation.

This makes sense. In Haskell, strict ByteStrings are a pointer, plus an offset, plus a length. You can call the unpack function on them, which provides a lazy list (it reads from the pointer in blocks) of the characters pointed to. There is also a library that provides lazy ByteStrings from mmapped files.

The Prolog stuff sounds quite interesting. I suppose you haven't published anything about the cross-border stuff? Quite a while ago I was using linear programming to build a home energy optimisation system, modelling the workings of a battery, solar panel, energy usage and energy tariffs. The whole thing was a big min-cost flow network. The output was a series of commands to hopefully optimise energy usage.

I defined the programme with glpk-hs (a Haskell library which can output in the CPLEX format) and then ran the programmes with cbc. It was very complex, and I later realised that what I really needed was a more general system which combined linear and logic.

Someone on HN mentioned ECLiPSe, but I see that you mention SWI quite a bit on your website. What can you recommend for the sort of thing I was doing? I am not an expert in linear programming, and I also found all the options of CBC a bit overwhelming.

Can you explain a bit more how exactly this string representation works, and how it differs from how strings are represented in Haskell? Also, what are you applying Prolog to these days?

Thanks for posting. The Pareto principle (distribution of influence) and Benford’s law (distribution of leading digits) immediately came to mind, which are also very interesting and are linked to in the article.

You might be right. Also if Betfair has its own bots playing as another commenter claims, then it will be hard to compete on odds. Only one way to find out.

I wonder what you base your sentiment on. I can't imagine there's much juice left in Twitter sentiment analysis.

What do you base your political bets on?

Thanks for the tips. The loans idea sounds interesting. I will send you an email.

Thanks for the heads up. It's good to get confirmation that that actually happens. I'd be surprised if it didn't. I'm not too far from implementing my final idea to get profitable bets in. If that (probably as you say) fails, then it was a fun learning experience.

Thanks. I would like to point out again that the code is out of date, and the margins displayed there are miscalculated due to not accounting for commission. The general spirit remains.

Did you backtest and show potential returns? Can you link to your model? Did you come across "Scoring dynamics across professional team sports: tempo, balance and predictability" [1]? They apply a Poisson model to team sports. I mentioned this paper to a company involved in betting who I interviewed with once, and they told me that they were doing something similar, but way more involved. It demotivated me somewhat regarding implementing it, making me wonder whether there really was any juice left to be squeezed from it.

[1] https://link.springer.com/article/10.1140/epjds29

I am assuming that all computer players of this game have access to the algorithm which I have discovered. I am assuming that all computer players have figured out the simple formula which gives them the cheapest profitable odds to back or lay an outcome given the commission and the outcome's probability (thanks to one of your previous comments).

I am assuming that there will be punters who bite at the odds I provide. If there weren't, then the game would not be sustainable.

I came across a "betting guide" for sale for this game which claims to advise on bets based on the "trends" seen in the game. I don't know what this means, but it gives me hope that there are people out there willing to part with their money in my direction.

Failing that, the novelty was an interesting one, and it's all about the journey, dude!

Yes. They provide various APIs for this.

Consider the case of betting with a traditional bookmaker. The bookmaker lays (bets against) an outcome. You back (bet for) the outcome. Each party is betting against the other.

Someone has to provide a market. That person has to do it profitably. I am assuming that this is possible, otherwise it would not be possible to play the game. My reasoning could of course be off. Could you elaborate?

On Betfair the house is you. You determine the odds. Let's assume that cards are dealt randomly. If I know the exact probabilities of every outcome I bet on, and I always bet with odds which have a margin over those probabilities, then I win in the long run.