6/21 My math and/or perl fu is weak. Is there a way to get integer
multiplication in Perl the way it's done in C? i.e. limiting
to 32 bits. Like 1588635697 * 1117695901 = 1166976269 in C.
\_ Can't you just multiply and then mask all but the last 32 bits?
\_ I don't think so; that's not the same as mult overflow.
> perl -e 'print (1588635697 * 1117695901)'
> 1.77561160671918e+18
> perl -e '$foo = (1588635697 * 1117695901); printf("%u",$foo)'
> 4294967295
> perl -e '$f=(1588635697*1117695901)&0xffffffff;printf("%u",$f)'
> 4294967295
I guess I could call C from perl but I'd rather not. Or construct
my own slow 32-bit binary multiplier in Perl, haha.
\-ObUseLISP
\_ People sometimes give me a hard time for disliking Perl, but I
really do feel it's not a well-designed programming language.
This is one example of why. Most other high level languages
have a notion of a native integer and native floating point
type. Lisp and ML languages certainly do. By the way,
what you want to do is 'use integer;'. In other words:
perl -e 'use integer; $f=(1588635697*1117695901);printf("%u",$f)'
-- ilyas
\_ Perl never claimed to be strong computationally. It's
a text munging engine at its core. That "use integer"
is required isn't all that surprising.
\_ Neither Lisp nor ML claim to be strong computationally
either (they are both meant for symbolic processing).
This does not stop them from having good design, and
a GC that doesn't leak. Matlab, which is often used
for numerical tasks, has a base numeric type that is
a complex-valued matrix! This excuse is neither here
nor there. Perl's poor quality coupled
with Perl's popularity really lowered consumer
expectations, I feel, which is a pity. -- ilyas
\_ Thanks, that works... except I had to play around a bit.
For example this case doesn't work:
perl -e 'use integer; $f=1117695901*(3177271395/2); printf("%u",$f)'
> 137188522
The division seems to throw a wrench in it. But it works
if I put only the multiplication in a block by itself,
with 'use integer' there. I'm not sure I trust this thing.
\_ how do you get the C-integer behavior in Lisp?
\_ Lisp, by default, uses bignums in case of overflow,
but it is possible to get around this with some
syntax verbosity, for instance in cmucl:
(defun f (x y)
(declare (optimize (safety 0)))
(declare ((unsigned-byte 32) x y))
(the (unsigned-byte 32) (* x y)))
(print (f 1588635697 1117695901))
There's probably a shorter way, but I don't care
enough to find it. At least it does the Right Thing
always, unlike Perl above. Notice that Lisp treats this
issue as one of type safety -- setting the safety knob
to 0 forces it to use the unsigned 32 bit integer type
for the result even if it cannot prove the result will
'fit.' -- ilyas
\_ well those people are idiots. Perl is not a programming
language, it's a bunch of ugly hacks that look like a
programming language. The fact that Perl is so popular
is not so much that it is intuitive or has features of
good languages, but the fact that it has one of the
most comprehensive libraries out there. I hate Perl,
but I also hate writing stuff in Java or scripts where I
need to build or find my own CGI lib, XML parser, code
generator, sql mod, and all the extra nice things that
are readily available on Perl.
\_ You should give Python a try. It has plenty of
drawbacks, like any interpreted language, but its
a million times better than Perl IMO. And you get a
huge set of the aforementioned bells and whistles that
are roughly comparable to what Perl has. Note that
one of the first complaints about Python is usually its
use of whitespace as a block delimiter, so if you can't
get past that you're probably SOL.
\_ I feel Python is a poorly implemented, inelegant
Lisp with decent library support. See Norvig's
essay on this subject. -- ilyas
\_ From Norvig's site: "The two main drawbacks of
Python from my point of view are (1) there is very
little compile-time error analysis and type
declaration, even less than Lisp, and (2)
execution time is much slower than Lisp, often by
a factor of 10 (sometimes by 100 and sometimes by
1). Qualitatively, Python feels about the same
speed as interpreted Lisp, but very noticably
slower than compiled Lisp. For this reason I
wouldn't recommend Python for applications that
are (or are likely to become over time) compute
intensive. But my purpose is oriented towards
pedagogy, not production, so this is less of an
issue."
Overall from what I can tell, he seems to *like*
Python despite these objections, and his main
objection seems to be that you can't compile it.
I've done tons of useful production work with
Python, so while I see where he's coming from I
don't see the practical downside of his complaint.
I can see why a computer scientist might object
to Python, though.
\_ You have to understand that Norvig works at
Google now, and Google has standardized on
Python, like it or not. I am not really
familiar with internal politics over there,
but it wouldn't surprise me if he was somewhat
pressured to not hate Python too much. I feel
scheme + SICP is the best pedagogy tool for
CS. There are a lot of really clunky things
about Python I don't like, but then again,
that's true of most languages. That's why I
want to roll my own one day. Also, the kinds
of things I like in programming languages are
fairly obscure, hard to explain and verbalize
things. -- ilyas
\_ Well, roll your own then. It's
actually pretty easy these days. Jim
Gray is quoted as wondering why
everyone isn't doing it.
\_ Writing is easy. Designing is hard.
-- ilyas
\_ "A poorly implemented, inelegant Smalltalk
with decent library support," is probably
a more accurate description of the language.
- ciyer
\_ How do you feel about ruby? -aspo
\_ Yeah, ruby is a new take on smalltalk
(dynamic typing, everything is an object).
Python resembles lisp more than
smalltalk. -- ilyas
\_ So. What do you think about ocaml?
\_ I don't like ocaml as much as I once
did. It's a good implementation
(which is rare), but I have been
finding design problems. E-mail me
if you are interested in a serious
discussion rather than half-hearted
trolling attempts. -- ilyas
\_ Foolish me for thinking that perl used bignums instead of
magically converting ints to floats. -pp
\- people who think perl is good as opposed to useful
typically have not been exposed to something actually
good. while one can debate what is the "Right Thing"
it's pretty pointless to debate what somebody else
finds useful. i use perl now and then but at the back of
my mind i am always a little nervous because of all the
things it is doing behind the scenes [to allow sloppiness]
which i dont understand. although admittedly i havent
seen perl do too many really crazy things since perl 4
[where you would hit crazy implementation as opposed to
design bugs like you would reorder a case statement and
all of a sudden perl core dumped. it's funny how berkeley
unix was the example of "worse is better" in the famous
"essay" and now BSD Unix is sort of the gold standard.
\_ psb, did you write some Open Source polynomial solvers
in Lisp? I came across some code by a "psb" at my
last job.
\- um, i did write some stuff for MACSYMA a while ago.
this was sort of pre-open src so it was more like
i threw it out there. this actually indirectly came
out of a ucb linear algebra class. a dumbass friend
of mine brought us what he said was an extra credit
homework problem, but turned out sort of a hard
problem [maybe a Knuth 42] and this lead to some
useful stuff being written. the only place i was
aware this was being used was IBM.
\_ My favorite thing that Perl got wrong is their
garbage collector, which leaks on cyclic data structures.
There is even an AI koan about this very subject.
-- ilyas
\_ point is valid. Luckily, most Perl programs
like CGI/PHP don't persist too long. Perl doesn't
scale well for real huge programs.
\_ Is that a GC bug or a result of the way it was
designed?
\_ It was designed that way. -- ilyas
\_ It was designed that way. See koan #2 here:
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?AI+koan
-- ilyas |
http://csua.com/feed/