Slashdot Mirror
MATLAB Can't Manipulate 64-Bit Integers
An anonymous reader writes "MATLAB, an important package of mathematical software heavily used in industry and academia, has had support for 64-bit machines for several years now. However, the MATLAB developers still haven't gotten around to implementing even basic arithmetic operations for 64-bit integers. Attempting to add, divide, subtract, or multiply two 64-bit integers will result in an error message saying that the corresponding method does not exist. As one commentator put it, 'What is the point of having numerical data types that can't be manipulated?'" The post notes that the free MATLAB clone GNU Octave deals with 64-bit integers just fine.
How is this news?
Like every other crap gnude ware has a sucky GUI.
Am I missing something here?
"The difference between genius and stupidity is that genius has it's limits" - Albert Einstein
What is the point of having numerical data types that can't be manipulated?
So they can charge more for the upgrade?
#fuckbeta #iamslashdot #dicemustdie
Ubuntu still can't recognize my wireless card... can I submit a story about?
maple 13?
Given that many values used in calculations are enormous, potentially thousands of bits long, 32 bits is quite sufficient. So long in fact, they can only be stated as 'strings' of integers. So much for different data types!
The concern should be the amount of time required to complete a calculation which MATLAB is very good at. I'd guess MATLAB is optimized for 32 bit. What is to be gained by rewriting everything for 64 bit?
So long as all calculations are done in a timely manner.
Another useful alternative is to use SciPy and NumPy packages for Python. Python doesn't have any issues with dealing with long numericals.
FWIW, GNU R, the freetard knockoff of S, also can't do anything with 64-bit numbers. It stores them in a double, which gives you 52 bits of exact integers and beyond that it's approximate. This can really bite you in the ass if you aren't aware of it ... and it's not documented anywhere except in code. It can be especially bad if you try to read a BIGINT (64-bit integer) value via RODBC, which silently truncates the value to 52 bits.
If you want raw speed, you don't code in Matlab. Simple.
Or code a MEX function.
In short, if you're relying on Matlab to do stuff fast, you're doing it wrong.
(Fast in this context, execution time. Fast in terms of algorithm development is another story)
As someone who uses math quite a lot in academia, I can tell you that I've never noticed the missing operators. I just don't use 64-bit integers. The reason *I* upgraded to 64-bit Matlab is because I kept running up against memory constraints. 64-bit Matlab can allocate much larger arrays. I am sure there are places where it would be convenient to use really big integers but I find it hard to believe that this is really a big headache for anyone; the main improvement with the 64-bit version is a much bigger memory space.
#TODO: finish up all operations for 64-bit integers.
Computers are useless. They can only give you answers.
-- Pablo Picasso
MATLAB isn't strongly typed, and by default variables are floating-point (I think 64-bit is the standard if type isn't specified). Makes sense for scientific programming. You need to go out of your way to use integer types in MATLAB, and the only reason I've ever had to do it is when trying to convert MATLAB scripts to C code to run on fixed-point processors. I do think that not supporting 64-bit integer operations is an oversight but I don't think it affects the vast majority of MATLAB users.
Obligatory.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
MATLAB does most everything with doubles, int and float formats are really only there when dealing with input/output to files. If i put A = 1 into a command line, its put in memory as a double. I use MATLAB most of my working day for signal processing algorithim design, and I don't think I've ever needed the precision of a 64 bit integer. Numbers bigger than a 32 bit integer can handle pop up from time to time, but never with more precision than a double provides.
Using the MEX API it is possible to implement operators for 64 bit integers in MATLAB. They aren't provided by default but implementing your own is quite trivial.
For some reason commercial software usually seems to lag worst on the 64 bit transition. Windows and OSX lagged Linux, Java and Flash were the last bits on my Linux systems to go 64 bit, etc. They act as if 64 bit is a fad, and people will soon come to their senses and revert to 32.
As another Engineer that uses MATLAB quite frequently, the only reason I have used 64-bit support was to analyze larger data sets.
In order for a number to need the 64th bit it must have a one in that 64th-most-significant position... and in order to add two such numbers, you end up needing a one in a 65 position... and there's your overflow error.
I mean, it's only double the size of 32 bits, so who cares? It's not like it's 4 billion times more, so, exactly - SO ?
Maybe you should buy decent hardware, or, I don't know, read the FAQ and instructions for dealing with lame-ass Broadcom Cards (like I had to do today to fix my Mother-in-Laws lame-ass HP Pavilion dv6000).
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
I'm hoping that is a joke
I'm not a MATLAB user, just someone who has had to troubleshoot problems with it for a variety of clients.
A while back, more than a few years now, MATLAB on HPUX was limited to about 1GB of memory. Any MATLAB code that needed more memory than that was shit out of luck - even on a 64-bit machine with 64GB of RAM. This was partly due to MATLAB only being available as a 32-bit binary for HPUX and partly due to MATLAB having been compiled and linked in the most naive way possible. After diagnosing the problem with a client's MATLAB code (they had a lab full of $2M computers and couldn't run this software that only needed a couple of GB of data), I wrote a short explanation of the compile and link flags necessary to enable any process to access at least 2GB of RAM with practically no impact and 3GB with only minimal impact. In either case, no code changes necessary whatsoever.
MATLAB's customer support group responded with a categorical denial that it was even possible to do - that HPUX architecturally limited all 32-bit processes to 1GB of addressable memory. While a customer-specific test release would have been the ideal response, I was really only expecting them to open a feature request and get the next release built the right way. But they wouldn't even give my client that (despite them having an expensive support contract) - just a flat out denial of reality instead. The solution for my client was ultimately to rewrite their software in C and link it with the right flags to get access to 3GB of memory.
So, given just how strong their disinterest was in even trying to make their software work for big boys doing scientific computing, I'm not surprised to hear that all these years later they still haven't even bothered to implement native 64-bit math. They are entrenched and there just isn't enough competition to make them lift a finger.
When information is power, privacy is freedom.
Any signed 64 bit number needs the 64th bit regardless of whether it's a 0 or a 1. 0-62 just depends on the number, but 63 will always be needed.
Dim PowerBallOdds as SuperSizeInt
Dim ChanceOfMeWinning as ExtraAccuFloat
Dim NeedToWorkTomorrow as Boolean = True
If you really want this support, get the user contributed package from matlab central. That wasn't too hard was it?
Can't you just move the decimal over a coupla points?
For justice, we must go to Don Corleone
a) The data types in matlab have absolutely nothing to do with the processor you are running on - and that is good - all my ml programs run on all my machines b) already the 8087 supported 64 bit integer - so no i dont know why matlab does not have it since a long time c) Usually the mathworks people care more about compatibility to the toolboxes. As long as a new feature collides with one of the important toolboxes, they rather don`t introduce it. E.g. if the signal processing toolbox fucks up when being fed 64 bit data
..when they got rid of the 'cool' undocumented commands like 'why' and 'f***'. ;)
I think it's pretty obvious. Why use a whole 64 bits when to represent 4? You should probably just use three bits. 100. That's why machines today are so slow... All these wasted bits.
You need 64 bit integers for holding indexes into arrays with more than 2 billion elements.
Just use the int64 user contributed stuff:
http://www.mathworks.com/matlabcentral/fileexchange/24725
The summary mentioned Octave as an alternative to Matlab. There is also Scilab (which has some more c-like features).
In recency I have simply been using Python. Use the iPython (interactive python) shell and load scipy (from scipy import *) and you have a very nice calculating environment. The scipy arrays are quite a joy to work with compared with what I remember from Matlab. If you're working with equal size 1D arrays then they can be used without modification in normal mathematical expressions, so a lot of my code no longer involves any iteration with for loops.
There is a graphing library (pylab) based on Matlab syntax. If you start iPython with the -pylab flag it will print out plots the same way as in Matlab. There is also Easyviz which I believe also uses Matlab syntax but interfaces with a number of standard graphing programs (like Gnuplot.)
The sympy package for doing symbolic manipulations is also quite nice, IMHO.
Disclaimer: I only used Matlab casually for my undergraduate math classes.
When things get complex, multiply by the complex conjugate.
Just another reason to switch to numeric python. The more I use Matlab the less I find that I like it.
This sig wasn't worth reading, was it.
That's a bunch of horse shit. Doubling the number of bits you process has little to do with critical path speed. Adding extra hardware to deal with changing bit lengths in the ALU has a HUGE impact on critical path speed.
That is: the way it is is far, far faster than representing numbers in arbitrary bits.
The price of Matlab (minimum of $2000), more like $10K for a decent set of tool boxes. They charge 20% per year for 'maintenance', though thankfully you don't have to buy a maintenance contract to use the software. And for all of this, they can't be bothered to support 64 bit integers? I'd be asking very pointed questions about why not, if I had a license.
There's excellent competititon for Matlab, foremost NumPy. It has tons of packages, 64bit support, and just works all around a lot better.
Matlab is succeeding not because of lack of competition, but because it's entrenched and people are lazy
You can run the following to find what it supports:
>> methods int64
>> methods uint64
Compare to
>> methods int32
>> methods uint32
Though floating point is very common for matlab use, i think this was fairly common knowledge.
Until someone makes an alternative with all the toolboxes i use, im not switching.
While this is not implemented natively, (or at least not until you use the fixed point tools to auto-generate some code for a 64bit machine), you can do a lot of fixed point math with the fixed point toolbox:
For example:
>> x=fi(5,1,64,0,'SumMode','KeepLSB');
>> y=fi(23,1,64,0,'SumMode','KeepLSB');
>> x+y
ans =
28
DataTypeMode: Fixed-point: binary point scaling
Signedness: Signed
WordLength: 32
FractionLength: 0
RoundMode: nearest
OverflowMode: saturate
ProductMode: FullPrecision
MaxProductWordLength: 128
SumMode: KeepLSB
SumWordLength: 32
CastBeforeSum: true
The documentation is here:
http://www.mathworks.com/products/fixed/
It is true that you need the fp toolbox to do that, though.
We learn from history that we learn nothing from history - Tom Veneziano
It's best to design software for limits that are frankly absurd. Since I coined the phrase "absurd limit theory", let's delve a little bit into it.
A second divided into increments enumerated by fractions of a 64 bit integer is less than the differential travel of differing wavelengths of light over a planck unit of distance. It's a smaller unit of time than matters to our current understanding. 2^64 seconds is more time than the entire history of our Universe from beginning to end even in the most ridiculous theory. Even counting photons and every known subatomic particle, an index of 2^64 is sufficient to enumerate each and every one with a unique ID that represents that one and no other. In each dimension angles discriminated in units of 1/2^64 of a circle are fine enough for any imaginable purpose.
Given that we are close to understanding these elements, 128 bits would probably be a more durable unit. 128 bits should give us a few more years of discrimination before the physical sciences discover even finer units of time, mass and distance. Some even theorize now that 64 bits are the limit: that space, mass and time have a granularity and that finer resolutions are absurd. To that I say...
If software must be designed with limits it should use limits so absurd that no user no matter how hypothetical could be constrained by those limits because the designer does not know how long his application will persist nor how its use will evolve.
It's not the most efficient design that wins. Ultimately it's the most persistent.
Help stamp out iliturcy.
Mathlab is for doing MATHS, as its name hints. Who cares about integer when you have floating point in the maths world ?
How about subtraction?
I have left slashdot and am now on Soylent News. FUCK YOU DICE.
Heh while we're bitching about MATLAB data types, where are the sparse single matrices?? Bah!!
So, maybe most people don't use over 90% of MATLAB's features. Does that mean MATLAB is bloated? Well, the thing is, everyone has different needs, and use a different 10%. Granted, most people have no use for 64 bit integers, but I'm sure somebody does, and somebody is mightily annoyed that their software that cost thousands doesn't do it.
Huh. People actually use MATLAB outside of academia? All the scientists I know who do hardcore math use FORTRAN or IDL.
Actually, Mathworks sent out a call for potential beta testers for GPGPU. I believe they plan on adding it to the parallel computing toolbox. So you'd have to pay extra if you want to access your GFX card for computational stuff. There is currently a free Matlab GPGPU toobox: http://gp-you.org/
Another thing that annoys me is the deathly slow Java interface in Matlab. Even with a fast 3D card it can take ages to manipulate complex 3-D plots.
What do we do when the value of 1 starts to float away?
QT/Octave:
>>> sqrt(-1)^((4)^1)
ans = 1
>>> sqrt(-1)^((4)^15)
ans = 1
>>> sqrt(-1)^((4)^16)
ans = 1.0000e+00 - 2.6298e-07i
>>> sqrt(-1)^((4)^17)
ans = 1.0000e+00 - 1.0519e-06i
>>> sqrt(-1)^((4)^21)
ans = 1.0000e+00 - 2.6929e-04i
>>> sqrt(-1)^((4)^22)
ans = 0.9999994 - 0.0010772i
>>> sqrt(-1)^((4)^32)
ans = 0.56253 + 0.82678i
>>> sqrt(-1)^((4)^40)
ans = -0.97448 + 0.22446i
The fractal community will be outraged.
pssh, you guys are a bunch of nerds
And are afraid to tell anyone. Another possibility is they fired 'the guy' who knows how everything works and now they can only make cosmetic changes.
http://junglevision.com -- Shamus for Gameboy
I recall reading an article back when 16 bit CPUs were a new thing which promoted the idea that 8 bit CPUs were superior for text processing because text was basically 7 bits.
http://michaelsmith.id.au
I'm hoping that is a joke
Joke or not, it's reality for anyone dealing with fixed point math. You have to go through your entire algorithm and decide which bits are worth keeping and how many you need. Things like Hamming windows don't like it when an accumulator overflows.
So you have to figure out how many numbers you're adding, take ceil(log2(N)) of that, and that's how many extra bits you need, or more to the point, how many high bits that the input data can't use. If N gets really big, that can cut way into a 32-bit integer. Trying to drop least-significant bits at various points in the vector raises your noise floor, decreasing your SNR (the noise looks like regularly-spaced impulses, too, which can hurt a clock-recovery algorithm). Also, this bit-eating effect cascades.
Multiplication is even worse: you get as many bits out as the sum of the bit counts in; 32x32 => 64.
As for Matlab... so what. Seriously. Matlab went for a very long time supporting only double precision floats (heck, it went a long time only supporting 2-D matrices). Other types were only supported in I/O; they got converted to doubles internally. They added 8-bit integers to make the video processing people happy back in the days of 3dfx. Then they added floats because some people wanted to trade precision for storage space, and integers because the fixed-point simulation stuff was getting hard to do. It's really a case study of a 90% solution.
For 18 years, I've worked at a research lab that swears by Matlab. (Though their recent licensing costs have us moving a lot of stuff to Python, and we tried Octave but dumped it because we couldn't migrate to it because they were missing key features that they didn't believe they needed. Our sponsors don't pay us to drop everything to learn Octave's internals, write patches to support what we need, and fight Octave politics to get those patches in.) And in all that time, the number of times I've seen anyone use integer arithmetic... is zero.
The vastly larger dynamic range, and logarithmic scaling, of double-precision floating point worked just peachy. Slow and memory hogging at times, to be sure. But we could crank out test algorithms in Matlab far faster than C++. Now... Python, NumPy, matplotlib... we're slowly moving over.
Python is a far more serious language than Matlab. Matlab is a hacking language like BASIC. It's lousy to manage a big project with. Seriously, one file equals one function? A class is a directory starting with an @? And there's no way to do select(), so we can't hook it up to our TCP/IP sockets and serial ports at the same time? And we're paying how much?
If you're serious, develop your algorithm in Python. 90% of the time, it'll be fast enough; the other times, you were going to have to write it in C or C++ anyway, and if you wrote your code in Python, your code will be far closer to C or C++ than if you wrote in Matlab. You'll never worry about licensing. Forget Octave and Matlab. And don't get me started on Matlab-to-C compiler. (Short version: if your program is read-compute-write-terminate, it might work for you. If it's event driven, forget it.)
If 64-bit integer A is less than 64-bit integer B, where are you going to hide the negative sign?
Two things:
1) This is true for 64-bit INTEGERS. The default data type for MATLAB is a 64-bit float, and has been forever.
2) This is a design decision by MATLAB's designers. You don't have to declare or type variables in MATLAB: you just set a = 5 and a new variable "a" is created. You set a(2) = 3, and now a grows into a 1-d array.
It's a handy feature and a core aspect of MATLAB's ease-of-use design, but to do this, you need to have a default data type.
64-bit float is the best choice: you can represent any number up to around 4,503,599,627,370,496 without error. For practical purposes, this means MATLAB will work fine for any real-world integer counting task: it only fails if you're interested in cryptography, primes, or other discrete math tasks, in which case you're not using MATLAB anyway.
Commercial 64 and 128 bit computing has been reserved for military/intelligence work for some time and they don't let this thing get out in the public quickly.
No, it's a carry. Adding a number with the 63rd bit set to a number with the 63rd bit set is an overflow.
Being the guy who implemented the proper 64-bit arithmetics support in Octave 3.2, I can maybe share some interesting points. Matlab's design choice of double as the default type is both a blessing and a curse. Usually the blessing strikes you first (I always disliked it that 1/2 is 0 in C++ and Python, finally Python 3 changed that as well), but you start to feel the curse when diving deeper, and integer arithmetics (which I agree is far less used than floating point) is a perfect example. Initially, Matlab probably had no integers. Given that double is the default, Matlab creators decided to make the integers "intrusive", in the sense that integers combined with reals result in integers, not reals, contrary to most other languages. The motivation is probably so that you can write things like a + 1 or 2*a without a silent conversion. Hence, when I is integer, D is double and OP is any operator, I OP D behaves like int (double (I) OP D). Except that things like a + 1 seem to be optimized (something Octave currently lacks, but it shouldn't be hard to do). int64 is where things start to get messy, because not all 64-bit integers can be exactly represented in double. So, using the simple formula above, 0.5 * i64 could occassionally do something else that i64 / 2, which is highly undesirable. In order to do the "right thing", Octave will choose one of two options: first, if it discovers that "long double" is at least 80-bits wide (so that it can hold any 64-bit integers), it will use that to do the operations. If not, it will employ a custom code to emulate the operation as if it was performed with enough precision. It's based on manipulating the mantissa and exponent of the double and is much slower. Although it was kinda fun to implement it, it is really a lot of work for too little music, so that can partially explain MathWorks' attitude to this. Unlike Octave, MathWorks doesn't really need to aim at source portability (as they just distribute binaries), so maybe they're just waiting for proper long double support in all compilers they use, and then they will just use the simple approach. Or maybe they're waiting for some important future design change. When I implemented this, I was fully aware that it's not a killer feature, yet I thought it may make Octave more interesting to some Matlab users. So I'm glad someone noticed :)
In any case, I suppose at some point Matlab will support this as well.
It's a slashumiliation, or humiliation by slashdotting.
I once had a signature.
Well, having to go dig an additional library to add native types is a bit paradoxal isn't it ? Even more when the software cost a lot of money and is directed at engineers. http://welcome-to-croatia.com/
not "overflow error". The carry bit is in the conditions register that all self respecting CPUs use for conditional branching and instructions like "add with carry". It's nothing to do with 64 bit, as the same concept works for 8 bit processors.
Other examples of where Octave has much better potential than Matlab are:
1) Calling matlab-like matrix functions from another programming language.
2) Using Octave on an architecture other than x86.
3) Using Octave on mobile devices.
I used Matlab extensively during my PhD (Physics), but am now switching to Python (and slowly rewriting all my code). I started because of the ridiculous licensing for Matlab, but continue because Python just has fewer stupid bugs like the submission talks about. The only thing I miss about Matlab is the extensive documentation all collected in one place and presented nicely.
Myself I am developing HornetsEye which is a Ruby-extension for doing computer vision.
The problem with supporting various types is that you end up with a lot of possible combinations when doing computations. I.e. say if you want to support arrays of 8-, 16-, 32-, and 64-bit integers (signed and unsigned) as well as 32-bit and 64-bit floating point, you have 10 ** 2 possible combinations of types when element-wise adding two arrays.
If speed is not an issue however, you could just use Ruby's dynamic typing. Ruby's integer classes use dynamic typing in their computations in order to avoid numeric overflow:
( 10 ** 2 ).class
# Fixnum
( 10 ** 10 ).class
# Bignum
Also you can seamlessly combine rational numbers, big numbers, complex numbers, and matrices in a seamless way which is really neat:
require 'mathn'
2/4
# 1/2
( Complex::I / 2 ) ** 3
# Complex(0, -1/8)
1 / 2 + Complex::I / 3
# Complex(1/2, 1/3)
( 1 / 2 + Complex::I / 3 ) ** 5
# Complex(-199/2592, 61/3888)
( 1 / 2 + Complex::I / 3 ) ** 24
# Complex(584824319281/4738381338321616896, 161741277005/32905425960566784)
a = Matrix[ [ 2 / 3, 3 / 4 ], [ 4 / 5, 5 / 6 ] ]
# Matrix[[2/3, 3/4], [4/5, 5/6]]
b = a.inv
# Matrix[[-75/4, 135/8], [18, -15]]
a * b
# Matrix[[1, 0], [0, 1]]
I make it twice that - 9,007,199,254,740,992. 52-bit mantissa, plus hidden '1' bit = all 53-bit numbers, so you can go up to (and including) 2^53. The next representable is 2^53 + 2.
It has taken much longer for consumer OSes to be 64-bit by default, but that's just because there was no need for it until >3-4GB of memory became common.
Even the statically linked "operating system" in a Nintendo 64 game console? That thing had only 4 MB of RAM and thus used 32-bit pointers, but it was still 64-bit.
There's no need for 64-bit Flash like there was for 64-bit MySQL/SQL Server/Oracle etc
Perhaps that's why a lot of Flash games still appear to be stuck in the 16-bit era of 2D.
I hate matlab - there I said it, it is an abomination, no types so when you look at a piece of matlab code you have no freaking idea what it is supposed to do - is that variable an array, an int a float, data structure? who knows? variables appear out of nowhere - aaagh! just stop it already and learn a real language.... the five minutes you think you save using matlab ends up costing 5 hours to someone else who wants to use it.
'What is the point of having numerical data types that can't be manipulated?'"
How about the point is you can store the result of two 32-bit numbers being added or multiplied? Moron?
yes, thats right, my dynamical systems are so sensitive to perturbation in their initial conditions that i require quad prec, i need 128bit floats (you insensitive clod). the intel fortran compiler supports 128bit floats, aka quad precision, with their compiler ifort. But their _optimised_ version of lapack in their mkl (math kernel library) doesnt handle 128bit floats properly. ive tried handing gemm real*16's and gotten nonsense answers, im guessing that the optimized code does even realise its been given a different data type and interpreting the quad prec's as double's and only reading the first (or last depending on machine arch) half.
intel processors have incorporated 80bit registers in the fps for some time. (the itanium has more i believe).
so real*10 should be fully supported and run at fully optimised native speed, but i can accept a slow down with quad prec, but if its supported by the compiler why not allow the mkl to make use of it. i havent benchmarked the speed difference either but im interested now. i might just grab some netlib codes for gemm aand compile them with real*16
the limit of defining arrays with more than 7 dimensions in the latest ifort, to be stored with hdf5.
it kinda weired me out to get the error msg back from the compiler that _any_ number of dimensions was not supported. i mean sure with an array of doubles, at 4bytes per element a 8 dimensional array with 1:10 extent in each dimension is going to require a mere 382meg. so why cant i declare such a variable on my machine with 4gig?
Matlab's one and only numerical data type is actually a matrix of complex numbers.
challenge accepted
Why learn one language for image processing algorithms when you still have to learn other languages to do everything else? Better have one language that does everything.
If you really want this support, get the user contributed package from matlab central. That wasn't too hard was it?
Disclaimer: I'm the dev, but I'm surprised that an iPhone/iPod calculator manages to do what MatLab does not:
Perpenso Calc, decimal arithmetic, 20 decimal digits, fractions, complex numbers, RPN
It is like saying if I put a Ferrari engine in a Chevy Suburban, it will perform as well as if i put it in a Ferrari.
Another way of putting it might be to say that, while both vehicles would then use the same engine, the Ferrari uses code structure recognition heuristics to optimize the sequence of calls it makes to the engine, while the Chevy takes a simpler approach to generating its sequence of calls.
I may not have made a very good analogy at all, I'm afraid...
Bow-ties are cool.
The difference is for Engineers versus Scientists. Engineers, who I would argue are far more likely to use MATLAB, have 0 need (with 0 being less than eps) for 64-bit integers because you will never ever ever ever measure data with accuracy of 1 part in 9,007,199,254,740,992, or anywhere near that. And as a rule, we have no need for integers because measured data and functions of measured data are much better represented using floating point. Scientists, who do work in absolutes, would have this need, but I would argue that they would not use MATLAB anyways and use something like Mathematica because it can do all calculations without losing any accuracy.
Ever.
Bow-ties are cool.
As of version 0.10.6, SmallBASIC can do 64bit operations and it supports many math functions - http://smallbasic.sf.net
I have a project that is not 'most work'. Matlab solves matrix problems for me that neither Mathematica nor any other package I've tried can. Matlab's competence shows in its description of mldivide, which is the key to my problem. It says that it tries A unless condition B is true, in which case it tries C, .... Mathematica says, trust us because we're so smart, with 1000s of routines, 1000000s of LOC etc. w/o going into details. All the free packages are jokes in this area. The only competition would be perhaps some C++ library. However Matlab probably hired its author to extend it for them.
Open SW is nice if you're not picky, but the commercial stuff, in many cases, does specialized things better.
I want an option in Matlab to start its array indexing at 2. Then I'll start using it.
Put a loop on your code, and you'll see how Mathlab craws. It slows down more than proportionaly to the number of iterations.
Rethinking email
Sigh ... sure wish I hadn't lost that source code. Back in '86 or so, Turbo Pascal and 8086 assembly language (oh yeah!) ... Toad's Infinite Integer Math. You could do all the basic math functions (add, subtract, multiply, divide, roots, powers) on integers whose length was only limited by the storage on your hard drive :-) Basically a calculator with a HUGE display screen :-) And with the largest numbers you can imagine treated as nice clean pure integers, no steenking floating point for us, unh unh! (Hell, my motherboard didn't even HAVE a math chip! Probably a Z-80 as I recall.)
Yeah, huge arrays of bytes, and simple functions that chugged through them, digit by digit :-) Worked great. Russian Peasant Algorithm, that sort of simple stuff, just with LONG numbers. And then a buddy on Usenet who heard about it sent me some more code that did some higher level math (logarithms and I forget what all; I'm no mathematician, just knocked it out as a lark).
Sure was fun, being able to manipulate numbers that were higher than the probably number of atoms in the Solar System, that sort of thing :-) And that was '86, small hard drives, 8-bit processors. Imagine what I could do with that now! Muah hah hah! The mind boggles!
But the hard drive with the source failed, the backup floppy was corrupted, my correspondent (who possibly had a copy of the source) dropped off the face of the earth, I couldn't find anything on Usenet or the usual sources. Gone gone gone [sob].
Toad of Toad Hall
Woah! Just did a search (since I hadn't looked for this for years) and ... lo and behold! Found! Discovered! Yesssss!
http://drn.digitalriver.com/category/Borland-Turbo-Pascal-programming-language/296.html
Which leads to this download:
http://drn.digitalriver.com/free-download/Borland-Turbo-Pascal-programming-language/toadlongzip/51197.html
TOADLONG.ZIP! And it's all there! Enjoy :-)
(Yes, the old Turbo Pascal compilers are still out there too.)
Boy, that WAS back in The Day. Check out my old email address :-)
kirsch@braggvax.ARPA
Hmmm, I wonder if that's still working?
Toad