Lisp Questions

So I have some questions about lisp. I've been learning programming but I hear some conflicting information so I need some things cleared up.

First of all, I keep hearing that the ability to wrote code others can read is huge, but since lisp is incredibly hard to read, wouldn't that make lisp programmers inherently bad programmers?

Also, can someone post some non-trivial lisp code? Every time I see someone post lisp code it's always something very short and trivial. Is it possible to write anything real with lisp?

>>40
Some error will exist anyways when dealing with functions that were originally meant to have real outputs. There's no way you're going to store the output or something like the square root of 2 in a rational without there being some error, no matter what precision ("infinite" precision would give you the actual number, but it won't be a rational anymore, nor would you be able to compute it in full as the process would be non-halting).

>>40

arbitrary precision rational numbers are shit. If you iteravely multiply them together, they double in size after every multiplication, which makes you algorithm take explonential time and memory.

>>42
floating point numbers are shit. If you iteravely multiply them together, they double in error after every multiplication, which makes you algorithm take explonentially wrong results.

No >>43, YOU are shit. Floating point numbers are designed to work that way and it is up to YOU to understand this.

>>44
Yes, I know floating point numbers are designed to be shit.

From a Jew's face
The wicked Devil speaks to us,
The Devil who, in every country,
Is known as evil plague.

Would we from the Jew be free.
Again be gay and happy.
Then must youth fight with us
To get rid of the Jewish Devil.

>>43
explonentially
excellent term

>>9
and was rewritten to python because it was unmaintainable

>>47

it was an accident. I'll make typos where I blend words together, like withe for with the, and I'll blend of the beginnings of different words together. I decided to not correct that one.

>>49
Accident or not, we should keep it.

>>41
Yes, some error will always exist once we have redundant representations. This is not the problem. The problem is how floating point numbers deal with that redundancy. Fast floating point units in hardware are a reasonable compromise in some cases, especially when the errors will not reasonably compound. (I still think IEEE standard is bad. But whatever, that's life.) But if you are going to use arbitrary precision floats then what is the point? Clearly speed is not your concern. In that case you might as well just use direct rationals, especially for common functions which have continued fraction representations. In such computations you can limit your error directly without sacrificing precision as there is no better rational approximation of that particular real. That's not my opinion, that's a fucking theorem.

tl;dr floats are fucking garbage and you're a tool

ellen page

>>42
The implementation detail you complain about is not essential to the problem

>>53

If you want complete precision, and if you happen to be squaring a rational over and over, the number of digits in the numerator and denominator with double after every squaring, regardless of the implementation for the multiplication. Dividing out a greatest common divisor is not possible in this situation, assuming the fraction starts out in a simplified form. The point is that there are times where arbitrary precision is not possible (or at least no worth the time and memory, which can grow exponentially with the number of squaring operations), and you will need to sacrifice precision after a certain point. This isn't hard to do, but if you are going to do it, you may as well just use fixed point decimal and use enough digits to represent the range of values you'll need.

>>54
I am sure I could concoct fantasy worlds where arbitrary precision floats were actually a better solution than arbitrary precision fractions if I thought about it hard enough, but most applications would be wrong to use it.

>>54
Yes but what is in question is using arbitrary precision floats versus arbitrary precision rationals. This should be a no-brainer, even if you're still truncating the floats after some non-hardware-supported-level of precision. Floats are not particularly well-behaved and understanding how errors compound is highly calculation dependent.  Choose one formula and you need three times as many bits just to avoid losing precision from the input value. Choose another formula that should be mathematically equivalent (say, manipulation through trig identities), and you don't need the extra precision at all. This kind of result using continued fractions is impossible.

Lisp is shit.

>>56

yeah, I was just thinking of high precision fixed point decimals. It could also be a fraction where the denominator is always a high, constant value.