HN user

magv

232 karma

Name: Vitaly Magerya

Occupation: physics, programming

Posts0
Comments40
View on HN
No posts found.

Hey, I have my own chess with a textual UI which allows you to play against several beginner-level chess AI opponents:

- Maia chess (https://maiachess.com), the human-like chess engine based on neural networks,

- several of neural networks by Dietrich Kappe (https://github.com/dkappe/leela-chess-weights/releases),

- and handicapped Stockfish (https://stockfishchess.org).

The whole thing is at https://github.com/magv/bchess, and can be installed with just 'pip install bchess'.

Years ago there was a thread like this one, and people suggested "Drawing on the Right Side of the Brain", just like they do here. So I tried that. Here's my account; I hope it will be useful to whoever reads it now that the topic has fallen off of the front page.

* * *

I worked through all the exercises in the book, and to be honest it was elevating: in a few (two?) weeks I was able to draw still life in a way I never thought I could, and the trick of looking at objects and imagining them flattened on paper burned into my mind so much that I was catching myself randomly doing it in the middle of my day (I still do it sometimes).

Then in a month or so I signed up for actual drawing classes. On the first meeting I told my teacher about the book and showed some of my drawings. Here's how I remember the conversation that followed.

- Does that book also teach composition?

- A bit I guess, but not particularly.

- For example if you draw a sphere, where should you place it in the picture, and how should you orient the frame?

- In the middle I guess? I don't know?

He sketched a few spheres, and it turned out that portrait frame placement combined with the sphere being slightly elevated from the center ("on a pedestal") looked the best. At this point I realized that the pictures I brought had their objects scattered randomly, as I paid no attention to their placement.

- Does it also teach the laws of perspective?

- It teaches to use your eyes, so perspective is achieved automatically.

So he placed a small cube onto a table and had me draw it. It came out a bit uneven, but I thought it was OK. Then he pointed out that I did not abide by the perspective laws, and actually inverted the perspective on the top face. He corrected a few lines, and the the cube magically became much more believable. I though I used my eyes well -- I did apply all my effort -- but apparently without knowing what to look for I missed an important relation, and my cube looked like it widened toward the far end of it.

- What about shading?

- The book says to use your eyes. Maybe squint a bit to help see the values.

So he had me fill in the cube. It was obvious to me that the darkest spot on the cube was its bottom part where the shadow fell, so I shaded that part extra dark. The teacher told me to walk away for a bit, and come back and look at my drawing. Sure enough the extra dark part was the first thing that popped into me eyes when I looked at it -- but looking at the actual object it was the front edge that attracted attention the most. There was a discrepancy. And yet, in my mind the values were correct: I copied them the way I thought I saw them. The teacher explained that the biggest contrast on paper attracts the most attention -- unlike the 3d space.

Then he had me half-erase the bottom part and outer edges until they almost faded into the background, and add contrast to the front edge -- darken the shadow and brighten the light just around the edge area -- much more than there was on the object, maybe even contrary to the physics itself. I then walked away, came back, looked at the drawing again: now my attention was dead on the front edge -- just like with the 3d object. Logically I thought the tones were all wrong, but it sure looked much better.

Although the teacher didn't explain it in these words, but I gathered that he never concentrated on reproducing the exact tones he saw, but rather on recreating the feeling of looking at the object -- the tones are then all made up to implement this feeling.

- Do you know how to sharpen a pencil?

- What do you mean? Who doesn't?

- Show me.

Folks, it turned out I didn't even know that. The actual technique for drawing is to sharpen a pencil to a needle and expose 5-10mm of its graphite: this makes it easier to shade, and (more importantly) forces you to grip it far away from the tip (as you would a fencing foil, rather than a pen), which makes it possible to stand further back when drawing, and keep the whole picture in the field of view instead of the particular detail you're working on, which is then needed to implement the intended whole-image feeling, and prevents from getting lost in the details.

* * *

My conclusion, if any, is this: there is so much more to drawing than just using your eyes. There are very basic techniques, used by painters daily, that improve the quality of their work beyond that of blind copying -- at a fraction of the effort. I am very grateful to "Drawing on the Right Side of the Brain" for persuading me that I can learn to draw (anyone can), but make no mistake: it did not teach me the techniques a novice should learn.

For those of us that don't use Lisp (or Emacs+SLIME), and are stuck with Python/Julia/Lua/etc and Vim may I give a practical recommendation? The Vim-Slime plugin [1] is a half-decent way of making interactive development work. With a bit of tuning you can make it start a terminal emulator window inside Vim, and have it send the current paragraph of your source code into it with a press of a button.

While not as great as working with a proper Repl-oriented language (as the article explains), this is still so much more pleasant than having to re-run the whole program every time you change a function.

[1] https://github.com/jpalardy/vim-slime

Those gaps immediately catch your eye, don't they? Seeing them and thinking "what if there's something we are missing" is exactly what many particle physicists also think. This is why the existence of particles and interactions addressing those gaps have been hypothesized to death and then some. Trying to compare some of these hypothesis with the experiment is a major part of fundamental physics today, second only to measuring the things we know exist more precisely. In many cases the comparison has been performed, and when it has been the conclusion was "if there is something there, then the parameters must be such that our instruments did not measure the effects yet". This is why particle physicists are pushing for better instruments.

verified the existence of the Higgs

As a related tangent: we have verified the existence of the Higgs, but only partially.

What was so far measured was the interaction strength between Higgs and W bosons, Z bosons, and the top quarks: these are the main channels of Higgs production at the LHC, and they fit the theory prediction within 20%. Yes, 20%. Not precise at all. What about interaction between Higgs and the other 5 kinds of quarks? Electrons? Muons? Tau? Itself? The data ranges from +-100% to none at all.

In particular the measurement of Higgs-Higgs interaction is an important one: the assumption Standard Model makes about the strength of this interaction is not unique, and others are possible. We don't know yet: not enough data. Moreover models with multiple Higgs particles are possible. Again, we don't know yet, not enough data.

This is why some cautious researchers claim that we have discovered "a scalar particle", "believed to be Higgs", but further measurement is needed to determine all of its properties.

This is one of the main activities at LHC and among the theoreticians at the moment: measuring Higgs interactions with other particles. There is still way to improve precision with more data from LHC, but ultimately there is only so much it can do without increasing the energy.

I think the idea that scientific code should be judged by the same standards as production code is a bit unfair. The point when the code works the first time is when an industry programmer starts to refactor it -- because he expects to use and work on it in the future. The point when the code works the first time is when a scientists abandons it -- because it has fulfilled its purpose. This is why the quality is lower: lots of scientific code is the first iteration that never got a second.

(Of course, not all scientific code is discardable, large quantities of reusable code is reused every day; we have many frameworks, and the code quality of those is completely different).

An interesting concern is that there often is no single piece of code that has produced the results of a given paper.

Often it is a mixture of different (and evolving) versions of different scripts and programs, with manual steps in between. Often one starts the calculation with one version of the code, identifies edge cases where it is slow or inaccurate, develops it further while the calculations are running, does the next step (or re-does a previous one) with the new version, possibly modifying intermediate results manually to fit the structure of the new code, and so on -- the process it interactive, and not trivially repeatable.

So the set of code one has at the end is not the code the results were obtained with: it is just the code with the latest edge case fixed. Is it able to reproduce the parts of the results that were obtained before it was written? One hopes so, but given that advanced research may take months of computer time and machines with high memory/disk/CPU/GPU/network speed requirements only available in a given lab -- it is not at all easy to verify.

As one point of comparison, SymPy is comically slow compared to Sage. This is mostly because SymPy is purely Python; Sage on the other hand uses its own derivative of GiNaC [1], Pynac [2], for its internal symbolic expression representation, and then multiple external libraries for non-trivial operations. Symbolic transformations are mostly Maxima [3], for example. Sage literally converts expressions to strings, pipes them through a Maxima process, and then parses the result back. This is still much faster than the pure Python SymPy.

There is an effort to speed up SymPy core, SymEngine [4], but it's been in development for years now, and still isn't integrated into SymPy. Not sure why.

Case in point: 'expand("(2 + 3 * x + 4 * x * y)^60")' takes 5 seconds with SymPy; Sage (Pynac) does the same in 0.02 seconds.

[1] https://www.ginac.de/

[2] http://pynac.org/

[3] http://maxima.sourceforge.net/

[4] https://github.com/symengine/symengine

LEP was annihilating electrons with positrons; LHC does not, as it only accelerates protons. FCC will have the option to do both: the plan includes two separate pipes in the same tunnel, one for protons, one for electrons.

This however does not increase the collision energy significantly: a single electron-positron pair has the (rest) energy of ~1MeV -- this is what is released during the annihilation, but the energies we want to go to at the next collider go up to 10TeV, so 10^7 times larger.

I am continuously surprised by the amount of work zig committers manage to put out every release. It is actually inspiring. How do they get to appear so productive?

Anyway, here's a nitpick. In this release they've removed varargs, and now this is how a printf call looks like in zig:

    std.debug.warn("{}+{} is {}\n", .{1, 1, 1 + 1});
The ergonomics of typing .{} for every print seems pretty awful if you're a heavy user of debug printing. I was hoping that maybe some sort of a syntax sugar is planned so that tuples could be used without .{} -- emulating varargs, but the bug tracker doesn't turn up anything in that direction.

In the previous release (0.5.0) one didn't need the .{}, but instead integer literals needed explicit casts, because the vararg implementation was limited:

    std.debug.warn("{}+{} is {}\n", i32(1), i32(1), i32(1 + 1));
Both of these options seem like a regression compared to the usual
    printf("%d+%d is %d\n", 1, 1, 1 + 1);
... and there doesn't seem to be a way to work around it by e.g. using a function overloaded in the number of arguments (no such thing in zig) or some preprocessor tricks (again, no such thing).

PS. I'm also surprised to find out that zig seems to take 2.6 seconds to compile the above example.

From just glancing at a few articles, this site is a treasure trove of references to highly readable explanations on a variety of fairly advanced topics. In fact, just the links to Wilczek's grand unification overview [1], and Klauber's Student Friendly QFT book [2,3] made this site worth visiting for me.

Resources that explain physics in (relatively) simple language without requiring books worth of prior knowledge seem to always be targeted at school-level physics; this one is different.

Of course, this is no substitute for a university curriculum, but as a way to plug holes in one's understanding, the site seems genuinely high quality.

[1] http://frankwilczek.com/Wilczek_Easy_Pieces/172_Unification_...

[2] https://www.quantumfieldtheory.info/

[3] ftp://srdconsulting.com/USB_BackUp/Data/Articles/QFT/StudentFriendlyQFT/

Scientific Linux 6.10 has make 3.81, CentOS 7.7 has 3.82. These long-term-support distros have old software by their nature, and sometimes you're just stuck with one of them unfortunately.

I have used this in one of my projects, but in the end had to abandon it: the problem is that Guile itself requires GNU make during build, which creates a circular dependency, and thus building it with e.g. FreeBSD ports required manual intervention every time you updated it. This combined with the fact that this integration is only available since GNU make 4.0, and some Linux distributions still have older make, made it a hassle to setup. This should improve over time, of course.

Still a great feature though. Without it there are e.g. manipulations on the file paths that you can not do at all, or can do but only as a hack. Case in point: "GNU Make Standard Library" (https://gmsl.sourceforge.io/) is a collections of such hacks; here's its definition of 'strlen':

    strlen = $(call assert_no_dollar,$0,$1)$(strip $(eval __temp := $(subst $(__gmsl_space),x,$1))$(foreach a,$(__gmsl_characters),$(eval __temp := $$(subst $$a,x,$(__temp))))$(eval __temp := $(subst x,x ,$(__temp)))$(words $(__temp)))

So what are they gonna do for 25 years?

Run 2 of the LHC ended in 2018. Currently the experimentalists are busy analyzing that data, and the theoreticians are busy improving the theoretical prediction precision to the level of the experiment. If we had no new data, it would take a decade for this work to be finished.

Run 3 of the LHC is scheduled for 2021-2023. After that the High Luminosity LHC upgrade will take place, with data taking currently scheduled for 2026-2038 [1].

Overall, just with the LHC-related projects in the foreseeable future we are looking at decades worth of measurement and research. There's no reason to worry about the lack of work to do :)

[1] https://project-hl-lhc-industry.web.cern.ch/content/project-...

So, yes, aside from the discovery of neutrino mass there was no "fundamental" progress since the Standard Model -- as in, all the effects we see in current experiments are accounted for by the theory -- if you know how to calculate them well enough, which is actually not trivial at all, and has been keeping physicist busy for the last few decades.

And yes, by scientific standards 20-30B EUR over ~25 years is a large sum, even though 1B/year is about the current CERN budget, about 1/5 of the current ESA budget, 1/20 of NASA budget, and 1/500 of the US military budget, etc -- so not that outrageous by other standards.

And yes again, there are multiple cheaper experiments with a more certain outcome. For example the Japanese Hyper-Kamiokande neutrino detector will provide enough data to solve neutrino mass hierarchy problem at the cost of ~2B EUR; or the space-based LIGO successor, LISA, which will improve over LIGO's ability to detect gravity waves by half of a dozen orders of magnitude for about 1B EUR or so.

And yet, those experiments can not bring more understanding into the "fundamental" physics -- i.e. to find a breach in the Standard Model. Only two kinds of experiments can:

1) cheap detectors constructed to test special classes of SM extensions (e.g. detectors like ALPS, which consist of a laser pointing at a wall to search for e.g. axions) -- if by some luck the particular extension turns out to be true;

2) a collider with higher energies like FCC, CLIC or ILC.

Now, there's no shortage of the cheap experiments, but up till now they've only excluded certain classes of "beyond standard model" theories, while confirming the SM even more. We'll probably continue building these in the forseeable future, but overall it doesn't seem likely that we'll find anything here.

So if you want any progress in the "fundamental" physics -- there doesn't seem to be a way without a bigger collider to show deviation from the SM. Without such an experiment, all people are left with is speculation, and that is how you get the string theories, supersymmetries, and the dreaded "naturalness" criteria, which the author of the article dislikes so much.

Is this a US thing?

In Ukraine, no-one is weird. No-one is a geek, or a nerd -- there aren't even equivalent words in our language. Nobody thinks less of you if you're smart, shy, or talk about transistors on occasion. There are no "popular kids", and even the scariest kid in school is not a bully.

So, again, what is wrong with US schools?

Aside from the license issue, it also helps that the guy who maintains Sendmail in the FreeBSD sources is Gregory Neil Shapiro, vice president and CTO of Sendmail Inc.

I've been using DDG since the new privacy policy. There are two points I frequently bump into:

1. DDG has a spellchecker, but not a good one. For example, DDG correctly guesses "hcker news", but unlike Google it fails to correct e.g. "hooker news".

2. DDG is relatively good on general queries (like unique names), but not on specific ones (like phrases). Recent example: searching for "r6rs vote" on Google gives ratification votes as the first link, DDG can't find that link at all.

So while I'm not too dissatisfied, I'm not too impressed either.

> If you ever got to being a candidate for, say, a national senior-school physics competition, you'd be transferred to region's best teachers. They would train you like a circus dog [...] but it wouldn't make you any good physicist.

Being one of such people, this is not entirely accurate.

For one thing, there is no practice of transferring students to best teachers, you have to want it get into the better schools. Another thing is that the best teachers are precisely the people who understand and will show you the essence of physics (or whatever your subject is).

Yes, a lot of time is devoted to competitions with repetitive problem set (the olympiads). But then, lots of time is devoted to non-competition topics. There are also competitions with open problems which require lots of imagination and original research on your part (e.g. ТЮФ, ТРИЗ and МАН for those who know). Some of the better schools require each student to complete a research project in his subject of choice.

My point here is that "circus dog training" is not at all correct.

> Bigloo, Chicken, and some others even have hygienic macros off by default due to the overhead, and recommend that you use define-macro whenever possible.

Not anymore for Chicken! Chicken 4.0 switched to `syntax-rules' and explicit renaming macros.

Edit: those who like traditional macros might also like explicit renaming ones [1,2], since they're very similar.

[1] http://www.gnu.org/software/mit-scheme/documentation/mit-sch...

[2] http://chicken.wiki.br/explicit-renaming-macros

New Arc Out 17 years ago

Not really. Only pairs are immutable now; vectors, strings, structures, hash tables and all the rest are still mutable. There's also separate mutable pairs. And mutable bindings, as always.

So no, far from Erlang in mutability.

New Arc Out 17 years ago

To be fair, the base language of PLT never claimed to support any relevant standard. Instead implementations of standards are built as libraries on top of the base language. So PLT does provide both R5RS and R6RS, both with mutable pairs.

It is when you want to use PLT-specific non-RnRS libraries from RnRS code, you run into pair incompatibilities.