|
PI
Nov 30, 2007 7:41:43 GMT -5
Post by Empyrion Martyr on Nov 30, 2007 7:41:43 GMT -5
I thought it meant factorial in the real world... Please don't blaim me for over the head sarcasm, my intentions are not bad
|
|
|
PI
Dec 1, 2007 3:07:49 GMT -5
Post by Pizzasgood on Dec 1, 2007 3:07:49 GMT -5
Yeah, those. They sound about the same, and I've been really tired lately. And I'm trying to keep 92 hiragana and katakana characters straight, so symbols like "!" that I'm not using in any of my current classes get a little fuzzy.
Hmmm... I messed it up a couple posts back too. Factorials are what I missed in high school. Fractals are just in my head because they're one of the things I want to play around with over Christmas break. I wanted to play with them months ago, but I've been too busy.
|
|
|
PI
Apr 8, 2009 9:48:42 GMT -5
Post by UNDISCLOSED on Apr 8, 2009 9:48:42 GMT -5
To get PI use the formula for circumfrence and rearange it, e.g.
DIM Pi# = <Circumrence>/<Diameter>
Just Make up the values, the should correspond tho.
DIM Pi# = 6.283185307/2
and then You can use the variable Pi anywhere
|
|
|
PI
Apr 12, 2009 1:22:08 GMT -5
Post by Pizzasgood on Apr 12, 2009 1:22:08 GMT -5
Dude, you posted the wrong value - yours is doubled. From memory, PI is approximately: 3.141592653589793238462643383279502884197169399375105820 That is literal, not rounded. I believe the next digit is actually a 7.
I don't see how people can memorize thousands of digits. The measly 55 that I learned weren't very hard, but I doubt I could easily learn more than another 55. After that I think I'd start getting lost in the numbers.
But it is nice knowing that I know PI to greater precision than my graphing calculator, and greater than most computer programs (I figure it would require a bare minimum of a 182 bit variable to contain that much precision, and that would be a pretty unusable sort of variable unless you added some more bits, as it would otherwise be limited to numbers between 0 and about 6.13, because it lacks a sign bit and bits describing the placement of the decimal). Not that it's hard to write code to handle it, just that most programs don't include such code.
|
|
|
PI
Apr 12, 2009 1:31:31 GMT -5
Post by smc44 on Apr 12, 2009 1:31:31 GMT -5
Dude, you posted the wrong value - yours is doubled. From memory, PI is approximately: 3.141592653589793238462643383279502884197169399375105820 That is literal, not rounded. I believe the next digit is actually a 7. I don't see how people can memorize thousands of digits. The measly 55 that I learned weren't very hard, but I doubt I could easily learn more than another 55. After that I think I'd start getting lost in the numbers. But it is nice knowing that I know PI to greater precision than my graphing calculator, and greater than most computer programs (I figure it would require a bare minimum of a 182 bit variable to contain that much precision, and that would be a pretty unusable sort of variable unless you added some more bits, as it would otherwise be limited to numbers between 0 and about 6.13, because it lacks a sign bit and bits describing the placement of the decimal). Not that it's hard to write code to handle it, just that most programs don't include such code. no he didnt, its write, make sure you noticed it says divied by 2, its just shorter
|
|
|
PI
Apr 17, 2009 6:42:45 GMT -5
Post by Pizzasgood on Apr 17, 2009 6:42:45 GMT -5
Oh, he did. My bad. I thought that / was a 1. Now I feel stupid. And blind.
In other words, perfectly normal ;D
|
|
|
PI
Apr 17, 2009 7:02:21 GMT -5
Post by shadow008 on Apr 17, 2009 7:02:21 GMT -5
ur only human...
|
|
|
PI
Apr 17, 2009 21:00:43 GMT -5
Post by dw817 on Apr 17, 2009 21:00:43 GMT -5
On the same topic of real number accuracy. Is there a way to caculate long real #s ?
n#=1.2345678987654321 n$=str$(n#) print n$
1.2345679
if you skipped the n$ conversion and just printed n#, it's worse:
1.23457
is not accurate enough.
|
|
|
PI
Apr 18, 2009 15:02:23 GMT -5
Post by matthew on Apr 18, 2009 15:02:23 GMT -5
You've just encountered perhaps one of the worst limitations there is in Basic4GL. I've been annoyed about it for quite some time, Basic4GL only has 3 simple datatypes, Integer, Real & String. It stores floating point numbers using the C++ float datatype which isn't exactly accurate, so no single or double precision. You can type the following... dim x as double
But Basic4GL will still store the number as a float & not a double.
|
|
|
PI
Apr 18, 2009 15:12:55 GMT -5
Post by dw817 on Apr 18, 2009 15:12:55 GMT -5
Wow.. That's rough, Matthew. I was planning for long math calculations to do interesting mosaic and rotoscope effects.
Is there a longint so:
999,999,999,999,999,999,999,999,999 is possible to save in a variable ?
And just what is the limit of memory ? I was experimenting making an array of: dim scrn(1023,767,2,15) and it seems to be taking it.
Printing FRE(0) does not yield memory remaining. How do you check on that ?
|
|
|
PI
Apr 18, 2009 15:23:17 GMT -5
Post by matthew on Apr 18, 2009 15:23:17 GMT -5
There are no additional datatypes apart from Integer, Real & String, sorry. But it may be posssible to add more if you created a plugin that could use them. I tried creating a zoomable fractal some years ago but whenever I attempted to zoom in on an area the program would crash with a Stack Overflow error because Basic4GL could not handle the size of the numbers being generated. According to this post that tom made, Basic4GL has got 400MB of variable memory. I don't actually think that there is a command for checking the amount of memory.
|
|
|
PI
Apr 18, 2009 15:29:49 GMT -5
Post by dw817 on Apr 18, 2009 15:29:49 GMT -5
Hi Matthew:
* Man, only 3 types. Not even a byte| variable class ..
I really didn't understand the tutorials for C++ and Thinbasic for making your own DLL. I'm a pretty literally minded fellow and if I can't see the solution in the first 2-lines of code, I get discouraged and chalk it up to bloated code.
I crashed B4GL several times now messing with strings as virtual storage for image records. What is the max # of chars a single string can have ?
|
|
|
PI
Apr 18, 2009 16:23:27 GMT -5
Post by matthew on Apr 18, 2009 16:23:27 GMT -5
Ok, I had a quick browse through the Basic4GL source code & found the following at the beginning at the TomVM.h file. #define VM_MAXSTACKCALLS 1000000 // 1,000,000 stack calls (4 meg stack space) #define VM_MAXUSERSTACKCALLS 10000 // 10,000 user function stack calls #define VM_MAXDATA 100000000 // 100,000,000 variables (.4 gig of memory) #define VM_MAXSTACK 250000 // First 250,000 (1 meg) reserved for stack/temp data space #define VM_DATATOSTRINGMAXCHARS 800 // Any more gets annoying...
It seems to be where all the Basic4GL memory limitations are created. If Basic4GL is anything like thinBasic it should have several GigaBytes of space for text.
|
|
|
PI
Apr 18, 2009 20:01:54 GMT -5
Post by dw817 on Apr 18, 2009 20:01:54 GMT -5
Hi Matthew: * It apparently does have limitations ! I've crashed the IDE several times now. Hopefully Tom can implement an autosave feature found here: basic4gl.proboards.com/index.cgi?board=Suggest&action=display&thread=2781Failing that, adding spaces to a string slows down considerably. File access is much quicker; code follows: results are 568320, very nice for a string to have that much storage.
|
|
|
PI
Apr 18, 2009 20:04:43 GMT -5
Post by Darkjester on Apr 18, 2009 20:04:43 GMT -5
your going to be writing that a long time!! 565677 is how many times that for next block executes lol
|
|