Thanks,
Jeremy
There ARE other Basics out there that can handle "multiple-precision" math.
Seems there was something called UBasic ( I don't remember exactly ). A
poster here found it a while back and claimed it worked well.
Most of the current Windows Fortran packages can handle 8-byte integers. But,
they only go up to 19 digits +/-. Of course... there ARE free
multiple-precision packages for fortran.
Your other type of choice is to write your own package. Look at the bright
side. If you are only doing integer math... it shouldn't be too hard.
Dan :-)
Heh! Another satisfied customer! ;-}
Personally, my language of choice for arbitrarily
large integer arithmetic would be Assembly. But if
you want me to give you an exact answer for, say,
(10E30)/(10E30 - 1), that may take a day or two.
I don't know for sure yet, but I'd be happy to
research it for you on a consulting basis.
K'Plauqh!
Rich
You could possibly use some kind of app-to-app thing; I forget what
it's called - VB4 has AppActivate, but you have to jump through some
hoops. But I just now popped up Excel and it lets me go to 30 digits,
albeit pi comes up as 3.14159265358979000000000000000000000.
Anyway, I stole a whole dictionary with that function, and the send
keystroke thing and whatnot.
Did I already post that item about using Assembly? If I REALLY REALLY
needed 30 digits of precision down to the dead nuts, I'd still use
Assembly. It could be done in VB by just using strings and doing
the arithmetic one digit at a time, if you want your answer tomorrow
morning. ;-)
Good Luck!
Rich
I'd go to www.fortran.com and look at some of the references to extended
precision packages there. Then the choice is to translate one to Basic
or to make it into a DLL. I'd go Fortran because <I> know Fortran and
the array indexing is the same as in Basic which makes translating code
simpler than from C, but if OP knows C/C++, then there's bound to be
code there that could be turned into a DLL as well...
> If you are doing large numbers, you do not use VB,
> or any other MS compiler.
And why is that? Are you a compiler architecture expert? Do you have some
proof that MS compilers are not suitable for large number math? Or are you
instead a porn addled little script kiddie who can barely spell VB, much
less program in it? What do you suspect my guess about you is?
> I need to do math with large integers in VB6, >10^30. None of VB's data
> types work, because they don't keep all of the digits, and I need exact
> answers. Does anyone know how I could go about doing math with these?
A lot of professionals and enthusiastic amateurs are interested in this
subject, and there is a lot of info available online. A quick search shows
references like this:
http://www.freevbcode.com/ShowCode.Asp?ID=1622
Good luck with your development effort.
Yes. As I mentioned earlier, do a web search for UBASIC. However, I'm not
at all sure that you can incorporate UBASIC into VB.
Also, I mentioned that fortran compilers can usually do 8 byte integers good
for around 16 digits. They can also do quad precision floating point numbers
good to around 33 digits. You may be able to use those even for your integer
requirements.
Once again, there are several free fortran multiple precision packages out
there if you need them. My web seaching for multiple precision packages for VB
didn't turn up anything, though I didn't spend a lot of time looking.
Dan :-)
No way, but I know enough not to use MS compilers
for number crunching.
> Do you have some proof that MS compilers are not
suitable for large number math?
Nothing specific, but enough to make me streer
clear of them.
> Or are you instead a porn addled little script
kiddie who can barely spell VB, much
> less program in it?
Veebee, that's easy. Now what was that really
tasty URL...
>What do you suspect my guess about you is?
Wrong.
Looking back through your posts to Usenet, what I
suspect is that you know a fair bit about VB (no
guru 'though, despite what you may think), but not
much else. You come across as a pompous asshole.
You have also given similar advice, to my original
post in the past.
Good luck with your program, ho ho ho....
Best Regards
Billy
So, he's right then?
I don't know assembly, and I only know a little C/C++. I thought of using
strings or bunches of longs, but it would take a long time, and I really
don't want to write all of the operations I'm gonna need, either.
Not an elegant solution, but it will do the work and it is free.
"Jeremy" <cfg...@pants.attbi.com> wrote:
More about me: http://thelabwiz.home.mindspring.com/
VB3 source code: http://thelabwiz.home.mindspring.com/vbsource.html
VB6 source code: http://thelabwiz.home.mindspring.com/vb6source.html
VB6 - MySQL how to: http://thelabwiz.home.mindspring.com/mysql.html
Fix the obvious to reply by email.
Uhm, Ok, I got ubasic, but how do I compile programs for it? It doesn't
seem to come with a compiler...
No he is not and I really do not know what has got
George's goat, because he has given similar advice in
the past. Seriously, flames aside, if you
really want to do maths with big integers, or
real, or complex, do not even consider using a
32 bit MS compiler, be it VB or VC++. Of course
you can try and find out the truth the hard way.
If you want to do this there are plenty of very
good compilers and libraries out there, many free.
Veebee has its uses, and I use it a lot, but if
you want do do serious calculations, forget it.
Regards
Billy
Script kiddy and porn addled tosser for 30 yrs+
now!!!
I certainly can see not using VB to implement a large numbers package,
but I don't see how it follow that <any> MS compiler other than VB is
not suitable--of course, there <are> a limited number of MS compilers,
since they don't cover the gamut of development languages available.
While no particular MS fan, such blanket advice w/o any supporting
reason(s) is of zero value IMO.
I think that what he is trying to say ( without actually saying it ) is that MS
isn't known for putting together quality, high end, numerically capable
compilers. They couldn't even get their Fortran compiler cleaned up. If they
can't get Fortran working cleanly, why would anyone trust their other packages
with numerically complex stuff?
If you really need heavy duty numerical capabilities, VB isn't the first
choice. It's just not designed towards that goal. Other MS products are.
However, some of them may be of questionable reliability/quality.
Dan :-)
<snip>
>
>No way, but I know enough not to use MS compilers
>for number crunching.
<snip>
MASM32 ?
> No he is not and I really do not know what has got
> George's goat, because he has given similar advice in
> the past. Seriously, flames aside, if you
> really want to do maths with big integers, or
> real, or complex, do not even consider using a
> 32 bit MS compiler, be it VB or VC++. Of course
> you can try and find out the truth the hard way.
Since you can write ANSI C in VC++ just as easily as you can using any other
compiler, the notion that VC++ can't be used for complex math apps is just
plain stupid. If that's too rude for you, sorry, I can't think of any other
way to say it.
> If you want to do this there are plenty of very
> good compilers and libraries out there, many free.
> Veebee has its uses, and I use it a lot, but if
> you want do do serious calculations, forget it.
Virtually every complex mathematical function has been programmed in Basic
by somebody somewhere at one time or another. If I were going to program
such software, I would not pick VB as the language to do it. However, the
notion that it *can't* be done is stupid. If that's too rude for you,
sorry, I can't think of any other way to say it.
As for being "pompous" or thinking I am a "guru", I would just like to point
out that, true or false, these things have *nothing* to do with the
discussion of whether MS compilers are suitable for complex math apps. Math
apps, if they are written correctly, always give the same answer. Show me
evidence that math apps compiled with MS compilers give the wrong answers,
and you are the man. If you have no such evidence, piss off. I hope that
is not too pompous for you.
Well, I wasn't claiming they're the cat's meow, either, but I still
don't see any <real> reason for the blanket statement made (or really
support for your claim either, Dan). As for MS and Fortran (I presume
you're speaking primarily of PowerStation) I suspect that it wasn't
nearly as much a case of "couldn't" as deciding it wasn't of sufficient
economic benefit to the MS business plan as to make it
worthwhile--although I certainly agree it was a pretty sorry effort at
that. Although I don't use the C++ features at all, I do have an older
version of the VS C/C++ compiler. I use it only for the things that
aren't doable in Fortran (CVF) or VB rather than complete projects, so I
can't say I've stretched it at all. But, it appears to me to be
reasonably solid although I do detest the IDE -- if that's the best MS
can do for a programmer's editor, it's no wonder (IMO) they're other
products are so buggy.. :) Unfortunately, it's the choice Digital made
w/CVF (not surprising since they bought PS) and CVF followed, and
extremely unfortunately Intel continues the parade. It is handy in one
sense to build multi-language projects, but I still use my old editor
outside the IDE for most code development but as I noted in clf I
personally will stop at the latest CVF version rather than be forced
into upgrading the MS VStudio when I really don't need/want it.
> If you really need heavy duty numerical capabilities, VB isn't the first
> choice. It's just not designed towards that goal. Other MS products are.
> However, some of them may be of questionable reliability/quality.
A MS product with a bug???!!! NO! :)
Quad-word 64-bit integer variables
http://www.powerbasic.com/products/pbdll32/
/Henning
I have done exactly that in a 1024bit integer calculator, and it works just
fine.
A.
"Jeremy" <cfg...@pants.attbi.com> wrote in message
news:Smhqa.617961$3D1.338379@sccrnsc01...
"Jeremy" <cfg...@pants.attbi.com> wrote in message
news:Smhqa.617961$3D1.338379@sccrnsc01...
MASM is not a compiler.
-AP
True - drat, I forgot that one
Although bear in mind the following:
VB Currency data is stored in memory as an 8-byte (64 bit) integer with 4
digits
of precision achieved below the decimal point, for use in currency
calculations.
That is, if you were to copy a normal 64 bit integer over the memory space
of
a currency value, it would appear as if divided by 10000 when you viewed it
in VB.
That is because VB interprets the number in 10000'ths not units. Shifting
the decimal point
four places to the left when you display or convert.
If you have enough accuracy without the additional 4 digits, fine, if not,
you will
need to multiply and divide through by 10000 accordingly in order to use the
additional precision of the whole 64 bits.
Normal VB operations work fine with Currency.
That okay for you? - ActiveHEXX
> I don't know assembly, and I only know a little C/C++. I thought of using
> strings or bunches of longs, but it would take a long time, and I really
> don't want to write all of the operations I'm gonna need, either.
MAPM? (C/C++ source)
URL:http://www.tc.umn.edu/~ringx004/mapm-main.html
--
Joe Foster <mailto:jlfoster%40znet.com> Greed = God? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!