Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Einstein Notation applied in programming

hz2.org

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Einstein Notation applied in programming

#21

Post by hzhou321 »

JadeNB wrote: post #6
QuantumRoar wrote: post #5

I've never seen a cross product being defined in that way using Einstein notation. You might want to express the cross product using the Levi-Civita symbol epsilon_{ijk} [1]. epsilon_{ijk} = 1 for i,j,k = 1,2,3 and all even permutations thereof. epsilon_{ijk} = -1 for all odd permutations of i,j,k = 1,2,3. Else it is 0. Then, the cross product reduces to: C_i = epsilon_{ijk} A_j B_k Using identities for epsilon_{ijk}…

> I've never seen a cross product being defined in that way using Einstein notation. In fact, I can't understand this use of the notation—namely, C_i = A_{i + 1 `mod` 3}B_{i + 2 `mod` 3} —and am not sure that it's correct. There is no free variable on the right-hand side, so I'm not sure over what to sum. Even if this were fixed, we'd need something like, as you say, the Levi–Civita symbol, since a given entry of the…

When there is no free variable, there is no sum, just the loop.

But you are right the the notion does not work as is because complicated subscript support is not implemented yet. But the equation is listed before the programming part is mentioned and it is an illustration of idea, so I believe it is ok.

It is not difficult to add the implementation, although it will be tedious (but still behind the surface). It is matter of how useful it is. And you are probably right that implementing a Levi-Civita syntax might be more straight forward.

Re: Einstein Notation applied in programming

#22

Post by hzhou321 »

geocar wrote: post #14
KfZ wrote: post #10

What the author call "black magic" I call abstraction. Why would you need to know at all times what summation and multiplications of what rows and columns are going on in your matrices? That's why use matrices, to not have to think about those all the time.

I think you missed the point. You can write `a mmu b` in KDB, but what the author refers to as no clue on the surface to tell me what is A, B, or C is about the need for improved notation, not an extended maths library. That said, I think the author's notation is terrible, so I'll use a different one. In K you can write +/+*\: or explicitly {+/+x*\:y} which is a function: sum flip x times eachleft y This allows me to…

I am not sure I find your syntax intuitive, but I understand that takes individual experience.

The main point (I am the author btw) is to have a lexical layer above the programming language layer, and give the programer control on how to write code that is most fit his mind. For example, how about give you the ability of use your +/+*\: when you are programming in C?

You may not buy it, but the idea is to separate the syntax layer from language layer so programmer can have a sliding context just like the way our mind deals with daily life.

Re: Einstein Notation applied in programming

#23

Post by hzhou321 »

currentoor wrote: post #20

Nice post. I studied with this notation too but I was not clever enough to connect it to my programming. This is a good example of a situation where something like lisp's macro system would be very useful. But I don't understand what the author means by On the other end of the spectrum, lisp is designed for its upper layer elegance. Its macros are structured all the way to the top. However, to achieve that, it limits…

Obviously it is my ignorance. I'll revise it back. But I still think MyDef is more than lisp. I need find a lisp expert friend (that is willing to understand MyDef) to make better narration. :)

Re: Einstein Notation applied in programming

#24

Post by hzhou321 »

enupten wrote: post #2

There are C++ libraries which have claimed to do this. I use this regularly in Matlisp: https://github.com/matlisp/matlisp/wiki

It is not a library. It is a syntax. An important idea of MyDef is the implementation behind the syntax is accessible to the programmer so the programmer can read, check, verify, modify and create. So when the programmer later decide to optimize the code into inline assembly (just e.g.), he can, without changing any of his def code.

Re: Einstein Notation applied in programming

#25

Post by hzhou321 »

mistaken wrote: post #13

So you've discovered what macros are for. M4 can do this and a lot more: http://en.wikipedia.org/wiki/M4_%28computer_language%29

I know. But I find it too difficult to use. Maybe it is just me. The big idea behind MyDef is if the programmer find something is more natural, he should at least try it.

I (the author) do not really care if anyone use MyDef per my implementation. One could implement MyDef in Lisp, Haskell, or any language, and I would be happy. A meta layer that individual programmer can control, rather than being sold in wholesale every single time.

Re: Einstein Notation applied in programming

#26

Post by hzhou321 »

hzhou321 wrote: post #21
JadeNB wrote: post #6

Earlier quoted context omitted.

> I've never seen a cross product being defined in that way using Einstein notation. In fact, I can't understand this use of the notation—namely, C_i = A_{i + 1 `mod` 3}B_{i + 2 `mod` 3} —and am not sure that it's correct. There is no free variable on the right-hand side, so I'm not sure over what to sum. Even if this were fixed, we'd need something like, as you say, the Levi–Civita symbol, since a given entry of the…

When there is no free variable, there is no sum, just the loop. But you are right the the notion does not work as is because complicated subscript support is not implemented yet. But the equation is listed before the programming part is mentioned and it is an illustration of idea, so I believe it is ok. It is not difficult to add the implementation, although it will be tedious (but still behind the surface). It is ma…

Oh I noticed my mistake, now corrected.

Re: Einstein Notation applied in programming

#27

Post by geocar »

hzhou321 wrote: post #22
geocar wrote: post #14

Earlier quoted context omitted.

I think you missed the point. You can write `a mmu b` in KDB, but what the author refers to as no clue on the surface to tell me what is A, B, or C is about the need for improved notation, not an extended maths library. That said, I think the author's notation is terrible, so I'll use a different one. In K you can write +/+*\: or explicitly {+/+x*\:y} which is a function: sum flip x times eachleft y This allows me to…

I am not sure I find your syntax intuitive, but I understand that takes individual experience. The main point (I am the author btw) is to have a lexical layer above the programming language layer, and give the programer control on how to write code that is most fit his mind. For example, how about give you the ability of use your +/+*\: when you are programming in C? You may not buy it, but the idea is to separate th…

I enjoyed your article.

Chinese is purportedly intuitive.

For example, 人 means "person", and 山 means mountain.

I don't see it, personally. I'm given to understand 成龍 means Jackie Chan.

However good notation doesn't have to be intuitive; we're talking in English and English is definitely not intuitive. That is to say that "person" doesn't look anything like a person.

Just as we learn to fit the concept of addition into our mind with the unintuitive + symbol, I find it useful to fit the concepts of K into my mind.

It is worth learning.

On your second point, you may not realise this yet, but you've invented a new programming language. There's no "syntax layer" and "language layer", because language is just the tool our mind uses to express problems and I believe that the lexemes used to express that language become a part of our brains when we try to solve problems in it. With that in mind, you will understand what I mean when I say: You have a language for expressing solutions; a notation, and I'll explain what I meant when I said I thought the notation was terrible:

First: C is also useful. Arthur writes K in C, so he might have a function like this:

    K fun(K x,K y){K("+/+*\\:");return apply2(g,x,y);}
The K macro is basically:

    #define K(s) static K g;if(!g)g=parse(s);
He doesn't write it this way. It would probably be more like:

    K2(fun){K("+/+*\\:");R ap2(g,x,y);}
but that's because the compact notation is useful.

This isn't the only good example I've seen: Zeta-C was a C implementation in Common Lisp. You could "switch to lisp" in Zeta-C just by writing an @-sign before the lisp form, i.e.

    int fun(int x, int y) {
      return @(stuff:mmu |x| |y|);
    }
ECL uses a pre-processor that allows you to write C code in it similarly. This is what mixing two languages looks like when done well: It looks like it belongs there, and it's useful for more than just being able to call Lisp functions from C: Those things could be Lisp macros(!) and even be mixed in C macros giving the programmer an incredible flexibility in expressing themselves!

What you've got is a notation with an edge. I can see where the C/Perl is, and where your "other notation" is (i,j,etc), and I don't like it. I feel the code switch snap loudly in my mind the same way I feel when I see a You could have made it look like it belonged there, and people could dip into your language easily. It would certainly be more work, but the notation would be better. Perhaps when you flesh out all the things you want to do you will consider revisiting this.

Re: Einstein Notation applied in programming

#28

Post by hzhou321 »

geocar wrote: post #27
hzhou321 wrote: post #22

Earlier quoted context omitted.

I am not sure I find your syntax intuitive, but I understand that takes individual experience. The main point (I am the author btw) is to have a lexical layer above the programming language layer, and give the programer control on how to write code that is most fit his mind. For example, how about give you the ability of use your +/+*\: when you are programming in C? You may not buy it, but the idea is to separate th…

I enjoyed your article. Chinese is purportedly intuitive. For example, 人 means "person", and 山 means mountain. I don't see it, personally. I'm given to understand 成龍 means Jackie Chan. However good notation doesn't have to be intuitive; we're talking in English and English is definitely not intuitive. That is to say that "person" doesn't look anything like a person. Just as we learn to fit the concept of addition int…

Thanks for detailed reply. I appreciate it.

First let's get the emotion color out. Whether someone think "intuitive" or "like" is arbitrary -- depend on experience and will change. For example, I have been thinking problems in Einstein notations for decades, so the syntax just seems natural to me, but I know other people may not think so, (I know this from my colleagues who have the same work context and known to be smart). So absolute verdict of "like" or not is of no value. It is more meaningful when we compare the alternatives -- rather than just saying you don't like it, it would be more interesting to hear what alternative you like. For me, it is comparison of Einstein notation and the full-blown nested loops.

Now what I really want to clarify is what I mean the language layer and syntax layer. (Often existing vocabulary fall short when describing ideas you are not used to so bear with me if you find term "language layer" inappropriate.) Think about programming a factorial function in C and in a functional language such as Haskell. In C, you probably will write a straight loop; in Haskell, it will be a recursion. The languages have its mandates and force us to write code accordingly. That is what I mean the language layer. Now think about the loops, we can say

    for(i=0;i
or

    for(i=0:n)
or

    loop(n)
Some of them may be unfamiliar, but they all mean the exact same thing -- resulting exact the same machine code. Syntax layer does not alter your code. We can use Chinese keywords instead of "if", "while", "for", and we will write the exact same C.

Now look at the current situation: except pure macros like m4, every so called programming language force to program differently at fundamental level: with different data types, static become dynamic, swapping out libraries which changes fundamental algorithm, etc. Then, all these new language sugar coat their syntax to make you think you are just changing into a better syntax to lure you in. Once you are in, you suddenly realize every thing has changed and it become obvious that you can't program in your old language with the same kind of experience anymore, and worse yet, you find yourself eager to defend your position and zealously fights the language war, at the syntax front.

PS: If expression fits your mind, then it is intuitive because you don't have to think extra. If expression does not fit your mind, and you have to think extra to understand then it is not intuitive. So English is intuitive as long as you think in English. I do.

PS2: There is an interesting study with people in Hong Kong who speaks both Chinese and English. The research found questionnaires in Chinese or English results in different statistics. So apparently, there is more than syntax layer difference between English and Chinese. On the other hand, dialects such as Cantonese and Mandarin are probably just syntax layer difference -- maybe this can even be applied to Latin and French.

Post reply on HN