BrandonS113

I really wanted to like Typst. No more latex would be fantastic. Decided to use it for a project, and had to give up and return to latex, just too many corner cases. Both things its missing from latex, and lack of Pandoc convertibility. Really hope it gets the last 10%

I have European debit cards. They get rejected in many Albert Heijn when Dutch cards (debit and credit) are taken. Jumbo takes foreign cards. Jumbo gets my (and a lot of my colleagues who pass though) business, AH not. Many restaurants take Dutch credit cards and not non-Dutch European credit cards. I went to a restaurant that takes Bitcoin but not EU debit (and Bitcoin transactions costs are much higher)

So if the fees on non-Dutch European and Dutch cards are the same, what explains this? Xenophobia? That is what my colleagues in Holland say.

I agree. But plenty of Dutch vendor only accept Dutch mastercards and not foreign. The fee s the same. WHY? And foreigners can't get IDEAL or Dutch mastercards. I have gotten used to carry a lot of cash when there. Fortunately, Holland is safe. Someone looked at me very funny when I payed them EUR 500 in cash last week.

But we also know why a European home grown payments system is not happening. The incumbent banks hate it and have enough power to block such solutions.

One reason to like the visa mastercard duopoly. They work everywhere. I go to the Netherlands a lot for work, and it is a real pain as they have their own payment system, IDEAL, one needs to live there, that is closed to foreigners. Many vendors, especially outside of main tourist areas will not take foreign cards. Guess they don't want to pay 0.1% fees. Yesterday, was left embarrassed in Albert Heijn where they only took Dutch cards and I did not have enough cash. (some AH do, most don't)

AMEX unusable in Europe? Hardly. I payed for my dentist Friday with it, both supermarket and lunch today, and all Amazon, etc. Some vendors dont take it, but in my European country most places

I much prefer parallel in R with mclapply() to the Julia implementation of parallel. One of the few areas where I prefer R to julia (other being R data.tables to julia dataframes)

I think that is exactly what is happening. Most of my code is much much faster in Julia, and the code is nicer. But R has its moments. Which is good since this particular app has 3K lines, and I do not want to port it to Julia.

And data.tables in R is faster (and I think nicer to write) than DataFrames in Julia. And since data.tables feed my optimization, R still wins.

Great idea, I do lurk there, just might do that next time I look at the code. My hunch is that simd is the low hanging fruit julia brings. But, and I am not an expert, both might end up doing BLAS anyways, which is why they are so similar.

No, its 4 lines of code. I just benchmarked for myself. All it is for 2 vectors x and y of average length 50, and 5 parameters, with exponential, addition, and multiplication, and ultimately sum to return to the optimizer. I was also surprised as I expected c to be much faster. And with Rccp, its actually slower than the R, overhead I guess. When I looked into it, apparently R has really fast code for such vector calculations. With julia, admittingly I did not use simd which would likely make it faster.

Now, I generally use Julia for heavy computes, and usually its much faster than R. But not always.

And this little bit of code runs for hours on the largest instance on AWS every day. Why I was looking so speed it up.

no, the function it calls is pure R and that is where the the code spends all its time.

I used to think so, but I have a function that gets called about a billion times each and every day as new data comes in, and and takes about 0.01 seconds to evaluate (optimizaiton with nlopt). I tried to code it in c (30% speed improvement) python (twice as slow), Julia (about the same speed). Reason is that call has 5 parameters that operate on a vector of length 50 to return a value to minimize. Turns out R is pretty good at such vector calculations.

Well I exported to ps this morning, since I used the pstricks package in latex.

It is the best way I have seen to make diagrams with code, which can be very convenient.

so python takes instrument data and writes latex with pstricks, then to ps to pdf/svg/png/* to insert into whatever doc my colleagues are making

We are continually evaluating alternatives as latex is a heavy dependency, but nothing works as well, yet.

and even more importantly it has worked for 10 years and likely will work for the next 50 years with exactly the same code.

I disagree, there are at least 2 reasons why eps can be better. a) you can exactly match the fonts in an eps figure to a latex file, which will look much better. b) you can use \psfrag to change text to get proper mathematics in figures, like gamma2 in an eps becomes $\gamma^2$ c) maybe also, the pstricks package is very nice, but does not work with pdflatex if pdflatex could do both, I would switch today but