jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 10:43 am

Heater wrote:
Thu Dec 13, 2018 7:31 am
That is exactly what happens. Running under the Linux Subsystem for Windows the Task Manager shows it consumes about 5GB of my 8GB RAM and then is showing a lot of disk activity.

I'm now worried how much life that took off my SSD having been doing it all night.
Sorry to hear that.

5GB is a lot, the C version allocates 9.3MB only in one single malloc call (and the executable is a tiny 8.4KB with -O3)

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 12:08 pm

No, no, that 5GB is what is uses when compiled with the address sanitizer options:

Code: Select all

$ g++ -Wall -O0 -ggdb -fsanitize=address -fno-omit-frame-pointer -o fibo_karatsuba fibo_karatsuba.cpp bint.cpp
It's all the memory asan uses for it's bookkeeping.

Built normally fibo_karatsuba is only using about 5MB according to the Task Manager.

The executable is a bit big at 19K. But that's only because I use iostream. Not really required.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 12:13 pm

@Heater:
The line of code question is kind of null and void when you are doing so many memory allocations, would not you say? As was already stated (I think by you), there is no reason to allocate mem and copy for each split in the multiply routine, so why do you do it that way? Is there a reason you avoid using a shared block allocation for this instead of running wild around memory?

And I think we will have to agree to disagree on the issue of lines of code. As was pointed out the tool you used does not account for multiple statements on a line, I have somewhere a quick program I wrote that ignores blank lines, null lines, and comments, and counts every line of code even if on the same line of the file as another line of code (that is correctly treating every statement as a line of code, and ignoring #defines that just assign a simple value as that is not a line of code). I had written the util a long time ago when I got to looking at how to implement things in as few lines of code as possible, as I had gotten tired of hand counting or using utilities that do not account for multiple lines of code on a file line (or count null lines as lines of code).

@jahboater:
jahboater wrote:
Thu Dec 13, 2018 10:43 am
Heater wrote:
Thu Dec 13, 2018 7:31 am
That is exactly what happens. Running under the Linux Subsystem for Windows the Task Manager shows it consumes about 5GB of my 8GB RAM and then is showing a lot of disk activity.

I'm now worried how much life that took off my SSD having been doing it all night.
Sorry to hear that.

5GB is a lot, the C version allocates 9.3MB only in one single malloc call (and the executable is a tiny 8.4KB with -O3)
I believe that he was talking about when he was tracking memory allocations, that has to take more memory than the program itself.

I still do not like the amount of time the C++ version spends in malloc/free/memcopy and related calls. Wonder if Heater thought about doing static allocations.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 2:20 pm

The BBC BASIC port to Raspbian by RichardRussell supports assembly, and as BBC BASIC is one assembler that works well on both RISC OS and now ARM Linux I am using the built in assembler in BBC BASIC V to do the assembly language version.

I think this will make things easier for all . I am finally begining to understand the Karatsuba algorithm, just had to look at a couple of references that include the mathmatic proof to get a good understanding for how it works, it is not as archane as it looks on the surface.

This means that I will be including 3 copies of the source listing, one as part of the forum posting, one as a correct ASCII text dump of the source, and one tokenized source listing (which should work on any system with BBC BASIC that supports ARM Assembly, and be listable on any system with BBC BASIC). The ASCII dump and the tokenized source will be in a zip once everything is working.

So I am now having fun with this one.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 3:03 pm

DavidS,
The line of code question is kind of null and void ...
Yes, I'm glad you now see you point about C++ lines of code had no validity.
...when you are doing so many memory allocations...
We were not talking about memory allocations. We were talking about lines of code in C and C++. The issue of memory management is completely beside the point.
As was pointed out the tool you used does not account for multiple statements on a line,
Opinions on how to count lines of code are probably as varied as opinions on source formatting so I don't want to fret over that much.

As it happens when I remove some unused API definitions, sum(), sub(), mul(), tweaked the addition and subtraction code a bit, and reformat the thing to the LLVM project style it shrinks to 238 lines:

Code: Select all

$ cloc fibo_karatsuba.cpp bint.h
       2 text files.
       2 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 1.70  T=0.03 s (60.0 files/s, 8872.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header                     1             39             14            214
C++                              1              5              0             24
-------------------------------------------------------------------------------
SUM:                             2             44             14            238
-------------------------------------------------------------------------------
Seems that contrary to your claims C is possitively verbose compared to C++ :)

Oh, I shoved all of bint into a single header file. Thought you might like that better.

See it here: https://github.com/ZiCog/fibo_4784969/b ... %2B/bint.h
Memory in C++ is a leaky abstraction .

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 3:53 pm

DavidS,
About those memory allocations:

Firstly the good news: By rearranging how things are done in my additions and subtractions, and judicious use of "const" and "inline" on the methods, the fibo(4784969) is now 20% faster.
As was already stated (I think by you), there is no reason to allocate mem and copy for each split in the multiply routine, so why do you do it that way? Is there a reason you avoid using a shared block allocation for this instead of running wild around memory?
Yep.

It's my project. I will write it how I like :)

Like you I had never even heard of karatsuba til this thread happened. So I wanted to be able to write myself one from scratch, no peeking at other peoples code. To that end I wanted to keep things as simple as possible. Just so I know I have the algorithm down pat. Ergo no worrying about details like memory allocations.

Now that working well and I understand what karatsuba should do exactly step by step, I can get down to the problem of optimizing it. Which may include a total rewrite! But see below...
Wonder if Heater thought about doing static allocations.
Depends what you mean. If it's allocated it not static now is it?

I have certainly thought of the obvious thing, alloc all the memory you need at start up then manage where all your big ints are inside it manually, then release all the memory in one go at the end. This has been discussed here before.

Now, I want to keep my fibo() function as it is. This is C++, we are using operator overloading, might as well do it in C otherwise. So the question is: How to we do that thing with memory allocation whilst keeping the API the same?

An answer might be to replace "new" and "delete" with ones own memory allocator. That memory allocator would grab a big block of memory when initialized, then dole it out as needed, releasing it in one go at the end. That would pretty much do what ejolson has done in C I believe.

Then there is some low hanging fruit: As we said before high() and low() need not create new big ints. They only need to provide views into what exists already, no allocation, no copying.

Of course that depends on not changing the thing that one is taking the high/low of. For example this would fail:

Code: Select all

    bint x = "79763491934591549154";
    bint y = high(x);
    x = "0";
    // Now y is corrupted
We don't need to do that of course, and can prevent others from doing it my making high/low private methods.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 3:56 pm

@Heater:
Ok now you know what I said. I know that C++ can be done well, as you usually do. I am saying that many people take advantage of the opertunity to write overly verbose code in C++ which seems to make it a bit easier to go more verbose.

Lines of code is not very important anyway, the real tests are not in any of this anyway.

The important test factors of code are:
  1. The correctness of the implementation of the algorithm.
  2. The correctness of the algorithm to begin with.
  3. The effeciency of the implementation of the algorithm.
  4. How little memory it uses (the less for the same functionality the better).
  5. How easy it is to improve on later.
  6. How little time it takes to compile (the less the better), also speaks of the compiler.
  7. How large the final executable code is, along with its inline data (the smaller the better, given equal functionality), the compiler contributes to this, as do any static linked libraries (including stub startup code).
  8. How fast it runs on the same HW, this can also speak to the compiler.
The list is in order of importance with the first item being the most important, and on down, with the last item still being important though weighted by the ones above it.

So I hope this gets us away from the loop of lines of code talk that we seem to be looking for a break condition to. I use assembly, which often means more simpler lines of code to produce correct binary executables that are smaller than those from most compilers, fast enough, take almost extremely little time to assemble, and are very easy to improve on later. And we all know that the portability of assembly is limited to systems on the same CPU at best, so no need to bring that up.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 4:08 pm

DavidS,

Please ensure your ARM assembler is usable on Raspian without needing to install closed source software. As far as I can tell Richard Russell's BASIC is closed.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 4:12 pm

Heater wrote:
Thu Dec 13, 2018 4:08 pm
DavidS,

Please ensure your ARM assembler is usable on Raspian without needing to install closed source software. As far as I can tell Richard Russell's BASIC is closed.
Depending on how big it is, it may be fairly easy to translate it into UAL or A32.
Last edited by jahboater on Thu Dec 13, 2018 4:20 pm, edited 1 time in total.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 4:19 pm

@Heater:
Sounds like a good reason for being ineffecient, it took a good bit of study for me to completely get my head around this algorithm as well. Though it is so simple once I finally got my head around it that I will likely never forget it.

And it sounds like you are already thinking about the allocation issue in a reasonable form. Just thought I would ask above, good answer for sure.

Heater wrote:
Thu Dec 13, 2018 4:08 pm
DavidS,

Please ensure your ARM assembler is usable on Raspian without needing to install closed source software. As far as I can tell Richard Russell's BASIC is closed.
Huh, how could it be closed source, I had not yet looked at the license. Though if it is closed source I guess I will have to do it using Asasm (open source, available for both RISC OS and Linux).

One debate though on the use of asasm for assembly, to be cross platform. As different make utilities still to this day have different syntaxes, would it be acceptable to include a build script for each OS (Obey file in RISC OS, Bash Script in Linux) that simply copies the appropriate makefile before invoking make?
Or as simple as this is perhaps not even use make, though have the two scripts that assemble the correct file for the two OS-Dependant bits of code and link?
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 4:26 pm

As my above list of the important factors of code was incomplete if seen by someone that does not already think about each detail, here is a more complete version of what is important to consider in any source code.

If these things are qualified from the first to the last in order (one further down the list has less meaning if one higher on the list is not considered first).

Keeping in mind that a program is just the implementation of an algorithm, often a very complex algorithm that can be broken down into a number of small simple algorithms (and is usually built up from a number of small simple algorithms). The important test factors of code are:
  1. The correctness of the algorithm to begin with.
  2. The appropriateness of the algorithm to the application.
  3. The effeciency of the algorithm for the application.
  4. The correctness of the implementation of the algorithm.
  5. The effeciency of the implementation of the algorithm.
  6. How little memory it uses (the less for the same functionality the better).
  7. How easy it is to improve on later.
  8. How little time it takes to compile (the less the better), also speaks of the compiler.
  9. How large the final executable code is, along with its inline data (the smaller the better, given equal functionality), the compiler contributes to this, as do any static linked libraries (including stub startup code).
  10. How fast it runs on the same HW, this can also speak to the compiler.
The list is in order of importance with the first item being the most important, and on down, with the last item still being important though weighted by the ones above it.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 4:38 pm

DavidS,

I could not find a license or source to Richard Russell's BASIC.

I have a vague memory of asking him about this ages ago on one of his threads, with the answer being that it is closed source. I could remember wrongly or the situation may have changed.

Why worry about make files and such?

I understand your preferred idea is to put everything in one file. If it's any kind of commonly understood assembler syntax anyone can figure out how to assemble it.

I was just starting to think about adding a make file to the fibo_4784969 repository. But that would build all the different solutions, where they need building, and run them all producing a timing report.

When you code gets into the repo that make file will deal with it as well.
Memory in C++ is a leaky abstraction .

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 5:14 pm

Heater wrote:
Thu Dec 13, 2018 4:38 pm
DavidS,

I could not find a license or source to Richard Russell's BASIC.

I have a vague memory of asking him about this ages ago on one of his threads, with the answer being that it is closed source. I could remember wrongly or the situation may have changed.

Why worry about make files and such?

I understand your preferred idea is to put everything in one file. If it's any kind of commonly understood assembler syntax anyone can figure out how to assemble it.

I was just starting to think about adding a make file to the fibo_4784969 repository. But that would build all the different solutions, where they need building, and run them all producing a timing report.

When you code gets into the repo that make file will deal with it as well.
Will be at least 3 source modules actually. One for the Karatsuba multiplication, one with the rest of the math and the fibo function, and one with the platform specific print and exit routines. This makes it portable among OS's given the same ISA, that would be 4 files total (as one is only ARM Linux OABI one is only RISC OS).

And yes asasm is easy to use on any platform, and ld is well known as a linker. I will try to locate the instructions for compiling asasm on ARM Linux so that everyone knows how to install the assembler (it is fairly easy, takes about 5 minutes on the RPi B+ BCM2835 at 700MHz, most of that time human reading instructions).
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 6:26 pm

DavidS wrote:
Thu Dec 13, 2018 5:14 pm
And yes asasm is easy to use on any platform, and ld is well known as a linker. I will try to locate the instructions for compiling asasm on ARM Linux so that everyone knows how to install the assembler (it is fairly easy, takes about 5 minutes on the RPi B+ BCM2835 at 700MHz, most of that time human reading instructions).
There are some instructions for asasm here on this site from Tim Rowledge
viewtopic.php?t=56725
You also need to install subversion and something called "autoreconf" which I have not yet found.

ejolson
Posts: 5137
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 6:54 pm

Heater wrote:
Thu Dec 13, 2018 4:38 pm
I could not find a license or source to Richard Russell's BASIC.
He open-sourced it a couple months ago citing failing health as the reason and uploaded a tarball somewhere. I don't think anyone jumped in to help or even put it on GitHub, but something of the sort appears to be what he wants. Any volunteers?

viewtopic.php?f=34&t=223160

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:05 pm

This is interesting:

I tweaked my high() and low() methods to return views of the original digits rather than making copies. With the following result:

Number of allocations and memcpy's down from almost 2 billion to 1.4 billion.
Run time down from 73 seconds to 55 seconds.

All in all 37% faster than the original 1 minute 28 seconds.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:10 pm

ejolson,
He open-sourced it a couple months ago citing failing health as the reason...
That was only back in September. And I read it. And I replied to Richard. Seems my memory is fading.

Hope Richadr Russell is OK.

Some enthusiast must be interested in that, it sounds like a fine project and it would be a shame to see it go to waste.
Memory in C++ is a leaky abstraction .

plugwash
Forum Moderator
Forum Moderator
Posts: 3599
Joined: Wed Dec 28, 2011 11:45 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:17 pm

I would advise not relying on oabi compatibility support going forward. Apparently it's still enabled in raspberry pi foundation kernels but other kernels may have it turned off (it comes at a performance penalty) and arm64 kernels don't support it at all.

jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:33 pm

See also,
https://wiki.embeddedarm.com/wiki/EABI_vs_OABI
Its deprecated anyway. I cant see any point in using it.

ejolson
Posts: 5137
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:43 pm

Heater wrote:
Thu Dec 13, 2018 7:05 pm
This is interesting:

I tweaked my high() and low() methods to return views of the original digits rather than making copies. With the following result:

Number of allocations and memcpy's down from almost 2 billion to 1.4 billion.
Run time down from 73 seconds to 55 seconds.

All in all 37% faster than the original 1 minute 28 seconds.
Woohoo! Do you think the clarity of the code was affected?

Assuming you slept for 8 hours and that the SSD experienced a 40MB/sec write rate for 4 of those hours, then a total of 562.5 GB of data was written. Given an 120GB drive, this means you've transferred as much data as 5 times the size of the drive. I think the rule of thumb is that you can write 3 times the size of the drive per day for 5 years. If this is true, it would appear that you have lost about one day from the expected life of the drive. If anyone knows how to perform a more detailed wear analysis or finds an error in my reasoning, it would be nice to know.

jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 7:59 pm

Since we are in the off-topic forum, I saw this in the news recently:
The total number of photons emitted by all the stars in the universe from day one (13.7 billion years ago) has been estimated as 4e84
Which you can easily store in a standard "double" in C.

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 8:21 pm

jahboater,
The total number of photons emitted by all the stars in the universe from day one (13.7 billion years ago) has been estimated as 4e84
I read that as well. I wondered if it was in any way a useful number to know?
Which you can easily store in a standard "double" in C.
Yes but that is overkill. We could devise a differnt floating point type to represent that much more efficiently. Say one byte for the exponent and one byte for the mantissa.

Then 4e84 becomes: 0x54, 0x04.

Yes but that is a really small number compared to our fibo(4784969) which is 1.072e1000000
Last edited by Heater on Thu Dec 13, 2018 8:32 pm, edited 1 time in total.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15808
Joined: Tue Jul 17, 2012 3:02 pm

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 8:31 pm

ejolson,
Woohoo! Do you think the clarity of the code was affected?
Judge for yourself:

For example bint::high() changed from:

Code: Select all

const bint bint::low(int mid) const
{
    assert(width > 1);
    assert(mid < width);
 
    // Make a result half the size of this, containing low half of this
    bint low(mid);
    std::memcpy(low.value, value, mid * sizeof low.value[0]);
    return low; 
}
to

Code: Select all

    inline const bint high(int mid) const {
        assert(width > 1);
        assert(mid < width);

        bint high;
        high.value = &value[mid];
        high.width = width - mid;
        high.parent = this;
        return high;
    }
The bint::sum changed from:

Code: Select all

bint bint::sum (const bint& n)
{
    // Ensure "a" operand is longer than "b" operand
    const bint *a = this;
    const bint *b = &n;
    if (n.width > width)
    {
        a = &n;
        b = this;
    }

    // Make a result of the same size as operand "a"
    bint sum(a->width);

    int i;
    uint64_t s = 0;
    uint64_t carry = 0;
    for (i = 0; i < a->width; i ++)
    {
        if (i < b->width)
        {
            s = a->value[i] + b->value[i];
        }
        else
        {
            s = a->value[i];
        }
        s += carry;


        if (s >= BASE)
        {
            s -= BASE;
            carry = 1;
        }
        else
        {
            carry = 0;
        }
        sum.value[i] = s;
    }

    // If carry is set here we need more digits!
    if (carry)
    {
        sum.grow();
        //width++;
        sum.value[i] = 1;
    }
    return sum; 
}
To this:

Code: Select all

    inline bint operator+(const bint &n) const {
        // Ensure "a" operand is longer than "b" operand
        const bint *a = this;
        const bint *b = &n;
        if (n.width > width) {
            a = &n;
            b = this;
        }

        // Make a result of the same size as operand "a"
        bint sum(a->width);

        int i = 0;
        uint64_t s = 0;
        uint64_t carry = 0;
        uint64_t *aPtr = a->value;
        uint64_t *bPtr = b->value;
        uint64_t *sPtr = sum.value;
        while (i < b->width) {
            s = *aPtr++ + *bPtr++ + carry;
            carry = (s >= BASE);
            s -= BASE * carry;
            *sPtr++ = s;
            i++;
        }
        while (i < a->width) {
            s = *aPtr++ + carry;
            carry = (s >= BASE);
            s -= BASE * carry;
            *sPtr++ = s;
            i++;
        }
        sum.width += carry;
        *sPtr = carry;
        return sum;
    }
[code]
Or read the whole thing: https://github.com/ZiCog/fibo_4784969/blob/master/c%2B%2B/bint.h
Memory in C++ is a leaky abstraction .

ejolson
Posts: 5137
Joined: Tue Mar 18, 2014 11:47 am

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 9:53 pm

jahboater wrote:
Thu Dec 13, 2018 7:59 pm
I saw this in the news recently:
The total number of photons emitted by all the stars in the universe from day one (13.7 billion years ago) has been estimated as 4e84
Which you can easily store in a standard "double" in C.
While the estimate has only one digit precision, an 84 digit integer can only be stored as a double after losing 69 significant digits of precision. Such rounding might remove the Earth's own Sun and thousands of other stars from the universe. For safety, it is best to work with large integers using suitable big number arithmetic, which fortunately puts us back on topic in this off-topic thread--especially as I see lots of stars in the new C++ code.

jahboater
Posts: 5642
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why Avoid BASIC on RPi?

Thu Dec 13, 2018 11:19 pm

At least the estimate is rather more accurate than the number of atoms in the observable universe with is thought to be
between 10e78 to 10e82. The precision may be limited, but the range of a "double" seems to be enough for any practical purpose, even the US national debt. And factorial 170.

Return to “Off topic discussion”