anewhnaccount2

I guess the problem is that if you create a shared-library, yes, you can call it from Python, but you are now restricted to C datatypes, and don't get any of the type-conversion or type-proxying that the other bridges provide --- as far as I can see.

That said, I think the bridges are actually pretty developed compared to what exists between many pairs of high-level languages. They are clearly working for some people since you will find Python-wrapper packages for Julia code. I'm not so sure it's so important to have a single `.so` package. There are solutions which allow Python to be-in-charge and bundle Julia to various extents. There are at least:

1. https://github.com/jlapeyre/julia_project

2. Usage of Conda and https://github.com/JuliaPy/pyjuliapkg

Given the amount of code involved, perhaps just out of fear the resulting code generation might not be as good? Rather a quick job to write something like that, but the scaling tests take a bit more time.

The evidence suggests that many of the deaths had symptoms consistent with being injected with air. We would need to have a model of P(symptoms_i|not injected with air) to try and get to the possibility of there having been a miscarriage of justice.

Does anyone have any kind of explanation for the blacked out section?

Since people keep saying he's a genocide denier, I'll drop this link here https://digitalcommons.usf.edu/gsp/vol14/iss1/8/ which explains that it's more a matter of semantics. He hasn't denied mass murders have taken place. He would probably also object to using either "terrorist" or "freedom fighter" since using these words emotively serves to obscure what's really going on.

It's fairly clear to me that trained models are a transformative rather than derivative works. However, without distributing forms which are not transformed, open/distributed/permissionless work in this space is either severely hampered, or basically impossible. I think a lot of people instinctively feel that removing barriers to their work is particularly important, since if we don't it could remain impossible for anyone outside a few megacorps -- who have the resource to obtain whatever they need in multiple ways without the additional liability of distributing non-transformed copies externally -- to build highly scaled up machine learning models.

In the case of Unix, it was deliberately a KISS/stripped down successor to Multics. The simplicity was originally intended for faster development and running on minicomputers rather than mainframes. In the end the simplicity also meant hackability and portability which is probably why it was successful and has had so much staying power.

If you only have to sacrifice a tiny bit of accuracy, it's not really a problem is it? You can quantify these things experimentally to see whether it's acceptable for your use case.

Given that vector and hybrid search are used in many situations at scale, I think to make the kind of claims you're trying to make, it might help to quantify exactly when you think it will be too slow or what experiences you have had of struggling to make it fast enough.

Absolutely. We could definitely chalk this up to being the "exception that proves the rule".

They may have had an edge on 64-bit performance, which is pretty much useless for deep learning, but can be useful e.g. physics simulations or other natural science applications.

> >Who is going to take the risk of deplying 10,000 AMD GPUs or 10,000 random startup silicon chips? That’s almost a $300 million investment.

Lumi: https://www.lumi-supercomputer.eu/lumis-full-system-architec...

Certainly there is a lot of magic going on in very popular Python libraries that implement autodiff or JIT compilation like PyTorch or JAX -- although the maturity of the ecosystem does mean that it is often quite well hidden. For the other languages, well... if you don't think C++'s templates tricks, Haskell's extension potpourri or indeed Rust's own combination of traits and type-level programming techniques can get convoluted, I'm not sure what to say.

The article mentioned that there are some gains from using vectorised numpy methods, i.e. spending more time in numpy code. I would be interested in whether the List[Polygon] could be converted into two long arrays of all xs and all ys with indices into the starts (essentially a dense representation of a sparse array) and then the core function rewritten for Numba since it could now not use any Python objects. This would break the interface of course, but may get within striking distance of the Rust implementation.

I suppose one advantage here as that it is might be possible to disable with a userstyle for power users.

There is a file generated by Quartus at https://github.com/alfikpl/ao486/blob/df6eba123654fdf3e3058c... I'm not sure, but it does seem mostly manual. I tend to agree that RTL is somehow particularly mind numbing. I would guess that in order to keep track of things you may have a large block diagram on paper beforehand.

I always thought that "dark" in "dark ages" refers to the lack of written evidence, i.e., more "dark" as in the lights have gone out and you can't see what's happening than "dark" as in grim.

How are they going to seek the damages given the defendants probably don't own any property in the UK?

Yes, that would be safer when available (although generally files within library dependencies are not modified I think?). It looks like fclones implements this, is faster and is written in Rust https://github.com/pkolaczk/fclones (the last is the most important point of course /s).

"Today, Israeli forces killed nine Palestinians during West Bank raid."

"Israeli authorities are being criticized for being too brutal, and Palestinian parents are being criticized for having too many kids."

Looks like it's best not to try to feed it actual news, because the results are more than a little awful.

See https://github.com/pauldreik/rdfind

I use rdfind to deal with this: https://github.com/pauldreik/rdfind

Cosmopolitan is a replacement standard library. It's not so much "pulling-in" a library as replacing e.g. glibc. The point of the blog post is that it's a libc but also a batteries included C development environment. On the one hand, it's nothing magic, on the other hand, it does have some nice concordances which are worth showing off.

This may also be how it works for humans. The more conscious parts of the brain are involved in coming up with a general "movement plan", while fine-grained re-balancing and re-planning is taken care or subconciously.

Reading between the lines here, the situation seems to be a little like the softmodem situation, which was also a major pain for Linux support. The abstraction previously given in hardware has been split into software/hardware to save on hardware costs, but now they refuse to open source the software.

As for the provided user-space software, it's not clear why this is happening. As long as kernel modules keep to the allowed interfaces, (and not the GPL-only internal interfaces) they can be closed source. Is it a case of too much caution from the vendors (after all -- NVidia have closed source drivers)? Is this supposed to be more forward compatible? Is it possible to have a higher performance (zero copy?) user-space exposed abstraction for this kind of video processing?

You can think of views as modelling a particular sort of implication, which is nevertheless somewhat restricted. Despite the restriction, it may be sufficient to cover many usages of OWL, but you may need to squint a bit -- what I mean to say there is it is not exactly an implementation of implication, but it may be used to model it and so some degree of reinterpretation of the resulting set of tables and views may be needed. The type of implication supported is roughly "a result to given SQL query based on (a combination of) existing tables and views => new record in a fresh table/relation".

It is happening: https://github.com/faster-cpython/ideas

The point is that these things (string processing/hash tables) are typically done using custom/tuned code in C and so would be faster than the generic, and not particularly carefully tuned Julia implementations.

However, given this library seems to be about passing NumPy arrays to/from Julia, the application is almost certainly to expose numerical stuff from Julia to Python. Basically, the use case is similar to Numba, but it works by producing a C-extension from a Julia system image (if I understand correctly). The main advantage over something like Numba would be access to the Julia ecosystem.

Agreed that the title is technically accurate. Julia should also be in the title, but this is possibly an oversight. It seems a bit unnecessary for the GP to assume that this is a bad faith attempt to mislead and insert Julia where it is not welcome rather than a potentially useful extra tool for writing high performance code. Note that the author/poster is probably not a native English speaker.

> Also why should I pick this over cython, pythran or numba?

One scenario would be that there is code already written in Julia, which you would like to expose to a broader audience. Although overall Julia's ecosystem is smaller than Python's, there are some niches within which it is highly developed. Library code accessible from the alternatives you listed is mainly limited to existing Python and C code. See the demo with `ParallelKMeans.jl`, which wraps a high performance Julia library performing K-means clustering, which could be a useful addition to the Python ecosystem.

Another scenario is that you want to write some custom code which makes use of the Julia ecosystem and then expose it to Python.

A quick way of determining this with Finnish is if it is 1) a nature word + 2) follows a simple phonetic structure where each syllable is CV or CVV (C = consonant V = vowel) then it might be from proto-Uralic and so not a result of language contact but a "really old" Finnish word and may be congnate with words in other Uralic languages e.g. Hungarian or one of several tiny languages Russia. Also e.g. puu (= tree), vuori (= mountain) is proto-Uralic. Other nature words like järvi (= lake) which don't follow the pattern might be proto-Finnic but have come from neighbours (for järvi it is apparently from baltic/proto-slavic).