4 ms·

one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple co

by em-bee 2y ago

one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast. in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.

xscott 2y ago
I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now. However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.
- em-bee 2y ago
  heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
the-smug-one 2y ago
That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower
- xscott 2y ago
  Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
  - em-bee 2y ago
    that's not what pike is doing though. int and float are still kept separate. btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly
    - xscott 2y ago
      You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
      - anonzzzies 2y ago
        Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
        xscott 2y ago
        > Besides his nick, was he smug? Saying, "That's nice." is a cliche condescension. You're free to disagree, but I think his intent was clear.
        anonzzzies 2y ago
        Ah, I did not read that into it. But guess that might be what he was doing.
  - Dylan16807 2y ago
    > This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.

by em-bee 2y ago

xscott 2y ago

I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now. However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.

em-bee 2y ago
heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))

the-smug-one 2y ago

That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower

xscott 2y ago
Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats. This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
- em-bee 2y ago
  that's not what pike is doing though. int and float are still kept separate. btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly
  - xscott 2y ago
    You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
    - anonzzzies 2y ago
      Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
      - xscott 2y ago
        > Besides his nick, was he smug? Saying, "That's nice." is a cliche condescension. You're free to disagree, but I think his intent was clear.
        anonzzzies 2y ago
        Ah, I did not read that into it. But guess that might be what he was doing.
- Dylan16807 2y ago
  > This is where you say something about "exact" vs "inexact" as though that will hand wave it away. I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.