LOG and LN lack of standardisation?

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
Richard Russell
Posts: 1091
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

LOG and LN lack of standardisation?

Post by Richard Russell » Tue Jul 16, 2019 9:28 pm

It is well known that the BBC requested of Acorn that BBC BASIC be largely compatible with the de-facto standard Microsoft BASIC of the day, but it has been stated at the Raspberry Pi forum that in those Microsoft BASICs the LOG() function calculated the natural (base-e or Napierian) logarithm, not a base-10 log as it does in BBC BASIC. If that is indeed the case, it would imply that Acorn failed to meet the requirement and in so doing introduced a significant incompatibility.

Unfortunately (but predictably) I have no recollection of any discussions on this subject at the time, there may have been but my memory is very poor. I wonder if anybody can shed any light on this; if it really is incompatible I'm surprised that it wasn't addressed back in 1981.

User avatar
Rich Talbot-Watkins
Posts: 1577
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: LOG and LN lack of standardisation?

Post by Rich Talbot-Watkins » Tue Jul 16, 2019 10:08 pm

The original MS 1978 BASIC did indeed only support log base-e with the LOG keyword. This version was licensed to Commodore and made it into the VIC 20 and C64. However, my first machine was an Oric 1, which also had a MS variant BASIC, but had both LOG and LN keywords. Meanwhile, Sinclair BASIC only had the LN keyword.

I always saw BBC BASIC as a somewhat separate dialect, with its own idiosyncrasies, but far superior to the other offerings. I don't remember other BASICs with all the inverse trig functions, for example; let alone the high level constructs like PROC/multi-line FN/REPEAT..UNTIL or a built-in assembler.

But it was often distinct enough to require substituting lines of code in printed listings in generic BASIC (as was Sinclair BASIC, which had the (a TO b) mechanism for string slicing instead of the standard LEFT$, MID$, RIGHT$). I don't think this harmed the reputation of BBC BASIC at all, apart from the arcane VDU sequences I've mentioned in the past, which looked incomprehensible to newcomers.

User avatar
jgharston
Posts: 3798
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: LOG and LN lack of standardisation?

Post by jgharston » Tue Jul 16, 2019 10:11 pm

Possibly it was Microsoft Basic that was out of step. For decades LOG has meant base-10 and LN has meant natural/base-e. My mid-'70s HP calculator has buttons for ln and log which give natural and base-10 respectively, as does my mid-'80s Casio Scientific, which I bought when calculating trig required too much accuracy for what I could do with pen, paper, memory, and straight lines. ;)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3798
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: LOG and LN lack of standardisation?

Post by jgharston » Tue Jul 16, 2019 10:18 pm

Rich Talbot-Watkins wrote:
Tue Jul 16, 2019 10:08 pm
I don't think this harmed the reputation of BBC BASIC at all, apart from the arcane VDU sequences I've mentioned in the past, which looked incomprehensible to newcomers.
Just think, if the BBC has been a 6809 the code density would have allowed squeezing in COLOUR l,p, DEFCHR$, PLOT x,y, GCOL c, ON, OFF (though those last two would have required seeing the future that VDU 23,1 would exist). The 6502 BASIC I ROM is full Full FULL, reading through the code you can see where heavy squeezing has been applied.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1577
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: LOG and LN lack of standardisation?

Post by Rich Talbot-Watkins » Tue Jul 16, 2019 10:24 pm

I think there's possibly scope to pack BBC BASIC a bit tighter, as I've noticed in the past that quite a lot of the maths code is unrolled, i.e. repeating an operation four times, for the four bytes of an integer or the FP mantissa, instead of using a loop. Whether this gave a useful performance improvement or not, I have no idea. It may just be that it simplified the code as it freed up an index register to use for something else.

User avatar
Richard Russell
Posts: 1091
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: LOG and LN lack of standardisation?

Post by Richard Russell » Wed Jul 17, 2019 8:34 am

jgharston wrote:
Tue Jul 16, 2019 10:11 pm
Possibly it was Microsoft Basic that was out of step. For decades LOG has meant base-10 and LN has meant natural/base-e. My mid-'70s HP calculator has buttons for ln and log which give natural and base-10 respectively, as does my mid-'80s Casio Scientific, which I bought when calculating trig required too much accuracy for what I could do with pen, paper, memory, and straight lines. ;)
Most interesting. In that case I wouldn't be at all surprised if the BBC received advice from educational experts which led to a deliberate decision to break with the Microsoft convention in this specific regard.

User avatar
Rich Talbot-Watkins
Posts: 1577
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: LOG and LN lack of standardisation?

Post by Rich Talbot-Watkins » Wed Jul 17, 2019 10:10 am

Richard Russell wrote:
Wed Jul 17, 2019 8:34 am
Most interesting. In that case I wouldn't be at all surprised if the BBC received advice from educational experts which led to a deliberate decision to break with the Microsoft convention in this specific regard.
It may also be that BBC BASIC then set the precedent for other BASIC variants to follow, e.g. Oric BASIC, as previously mentioned, which had both LOG and LN. Locomotive BASIC on the Amstrad CPC also had both, although they were called LOG and LOG10.

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: LOG and LN lack of standardisation?

Post by Coeus » Wed Jul 17, 2019 6:54 pm

Rich Talbot-Watkins wrote:
Wed Jul 17, 2019 10:10 am
It may also be that BBC BASIC then set the precedent for other BASIC variants to follow, e.g. Oric BASIC, as previously mentioned, which had both LOG and LN. Locomotive BASIC on the Amstrad CPC also had both, although they were called LOG and LOG10.
This is the worst kind of incompatibility, though, to have a function with the same name that does something different.

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: LOG and LN lack of standardisation?

Post by Coeus » Wed Jul 17, 2019 7:20 pm

Rich Talbot-Watkins wrote:
Tue Jul 16, 2019 10:24 pm
I think there's possibly scope to pack BBC BASIC a bit tighter, as I've noticed in the past that quite a lot of the maths code is unrolled, i.e. repeating an operation four times, for the four bytes of an integer or the FP mantissa, instead of using a loop. Whether this gave a useful performance improvement or not, I have no idea. It may just be that it simplified the code as it freed up an index register to use for something else.
Ok, so I decided to have a look at this. This is on B-Em, but other than patching the BASIC ROM, it's the same B-Em in each case so I am looking at the difference. First, CLOCKSP with BASIC 2 on a BBC B. It's under 2Mhz because I have not disabled interrupts:
clocksp_unch.png
Next I decided to patch the routine which the Advanced Basic ROM User Guide calls iplus, which adds an integer variable to BASIC's integer accuumlator A. Here's the original:

Code: Select all

    9C5B: A0 00       LDY #00     
    9C5D: 18          CLC         
    9C5E: B1 04       LDA (04),Y  
    9C60: 65 2A       ADC 2A      
    9C62: 85 2A       STA 2A      
    9C64: C8          INY         
    9C65: B1 04       LDA (04),Y  
    9C67: 65 2B       ADC 2B      
    9C69: 85 2B       STA 2B      
    9C6B: C8          INY         
    9C6C: B1 04       LDA (04),Y  
    9C6E: 65 2C       ADC 2C      
    9C70: 85 2C       STA 2C      
    9C72: C8          INY         
    9C73: B1 04       LDA (04),Y  
    9C75: 65 2D       ADC 2D      
    9C77: 85 2D       STA 2D      
    9C79: 18          CLC         
    9C7A: A5 04       LDA 04      
    9C7C: 69 04       ADC #04     
    9C7E: 85 04       STA 04      
    9C80: A9 40       LDA #40     
    9C82: 90 C1       BCC 9C45    
    9C84: E6 05       INC 05      
    9C86: B0 BD       BCS 9C45    
    9C88: 4C 0E 8C    JMP 8C0E    
and here's the first attempt to patch it:
patch1.png
This doesn't work correctly - CLOCKSP gets into an infinite loop. The problem is that the CPY is nobbling the carry flag that should be carried from one byte to the next. We can't run the loop in the opposite direction and use DEY instead of CPY without making the storage format of integers big-endian. Here's the next attempt:
patch2.png
patch2.png (6.24 KiB) Viewed 806 times
So, given we don't need the value in A between it being stored and the next byte being loaded, this saves the carry by rotating it into A. This should be faster than pushing it on the stack. This does seem to generate the right answers so running clocksp:
clocksp_pat.png
The integer repeat loop is measurably slowed. Apart from the overhead of comparing and branching to implement the loop and the two extra instructions to save/restore carry , the instructions to index into the integer accumulator are now 16bit addressing rather than page zero addressing. So it is possible to gain a small amount of space this way bit is not as trivial as it first appears and it is as the expense of speed.

So if other parts of the ROM look squeezed when there is an obvious target like this it tends to suggest that Sophie optimised the core of BASIC for speed and the less commonly used bits for space.

User avatar
hoglet
Posts: 8825
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: LOG and LN lack of standardisation?

Post by hoglet » Wed Jul 17, 2019 7:34 pm

It's likely no faster than what you have, but another alternative to CPY #4 in this case is:

Code: Select all

TYA
AND #$03
BNE loop
Dave
Last edited by hoglet on Wed Jul 17, 2019 7:35 pm, edited 2 times in total.

scruss
Posts: 159
Joined: Sun Jul 01, 2018 3:12 pm
Location: Toronto
Contact:

Re: LOG and LN lack of standardisation?

Post by scruss » Thu Jul 18, 2019 1:02 am

Coeus wrote:
Wed Jul 17, 2019 6:54 pm
This is the worst kind of incompatibility, though, to have a function with the same name that does something different.
Though here it's BBC BASIC, not Locomotive BASIC, that's non-standard. BBC BASIC fails every one of of the tests in ANSI BASIC test 124.1. By adding LOG10, Loco BASIC doesn't break any standards.

Some history of how these were named:
  • FORTRAN for the IBM 704 (1956) had LOGEF() and LOG10F()
  • Dartmouth BASIC (196x) had LOG(X) for natural log
  • FORTRAN-77 (1978) had LOG() and LOG10()
  • ANSI/ECMA BASIC (1978) (and likely ISO/IEC BASIC) just has LOG() for natural log

User avatar
Richard Russell
Posts: 1091
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: LOG and LN lack of standardisation?

Post by Richard Russell » Thu Jul 18, 2019 7:09 am

scruss wrote:
Thu Jul 18, 2019 1:02 am
BBC BASIC fails every one of of the tests in ANSI BASIC test 124.1.
The ANSI BASIC standard came along a couple of years after BBC BASIC, I think, so isn't something that could have influenced the decision taken by Acorn and the BBC at the time.

scruss
Posts: 159
Joined: Sun Jul 01, 2018 3:12 pm
Location: Toronto
Contact:

Re: LOG and LN lack of standardisation?

Post by scruss » Thu Jul 18, 2019 8:57 am

It's my understanding that the draft ANSI Minimal BASIC standard came out in January 1976, the parallel (but compatible) ECMA standard came out January 1978, and the ANSI test spec was published in 1978 too. John Coll's 1980 spec says:
The general syntax of all commands should be identical to Microsoft BASIC 5.0 (repeat 5.0). If there is any conflict between what is said below and the relevant Microsoft implementation then the latter should be used.
The MS BASIC 5.0 manual is firmly in natural log country for LOG() (and touts its ANSI compliance¹, too). I think the simplest explanation is that someone at Acorn dun goofed.

If it's any consolation, Clive didn't read the spec either: Sinclair BASIC has LN() but no LOG() …


--
¹: ANSI compliance would likely have been an important detail for the then-young Microsoft. US federal government purchasing rules required that any computer system with BASIC sold to the government had to meet the Minimal BASIC standard. Having a chance at government contracts would have been worth Microsoft's time. For Acorn, though, this would have been far less of a priority.

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: LOG and LN lack of standardisation?

Post by Coeus » Thu Jul 18, 2019 9:07 am

scruss wrote:
Thu Jul 18, 2019 8:57 am
It's my understanding that the draft ANSI Minimal BASIC standard came out in January 1976, the parallel (but compatible) ECMA standard came out January 1978, and the ANSI test spec was published in 1978 too. John Coll's 1980 spec says:
The general syntax of all commands should be identical to Microsoft BASIC 5.0 (repeat 5.0). If there is any conflict between what is said below and the relevant Microsoft implementation then the latter should be used.
Why version 5.0? Was this the first version that was ANSI compliant? It does look like this was a mistake. Reading that test case, though, is a useful reminder of how much improved BBC BASIC is generally from this "minimal" BASIC.

User avatar
BigEd
Posts: 2775
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: LOG and LN lack of standardisation?

Post by BigEd » Thu Jul 18, 2019 9:14 am

I believe Sophie was a fan of Cody & Waite for numerical recipes - the copy I've seen is dated 1980 and on page 45 it describes the behaviour of log() and ln(). Which is, as noted above, also consistent with most scientific calculators (back to the HP-35 even.)

Oddly, the chapter in question is titled ALOG and ALOG10 which is evidence of the opposite convention - perhaps from Fortran?

User avatar
Rich Talbot-Watkins
Posts: 1577
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: LOG and LN lack of standardisation?

Post by Rich Talbot-Watkins » Thu Jul 18, 2019 9:53 am

Coeus wrote:
Wed Jul 17, 2019 7:20 pm
Ok, so I decided to have a look at this. [...]
Thanks for trying that - really interesting result!

So by my rough scribblings, changing the routine to this (I believe the most optimal):

Code: Select all

    LDY #&00
.iplus_loop
    LDA (&04),Y
    ADC &002A,Y
    STA &002A,Y
    INY
    TYA
    AND #&03
    BNE iplus_loop
saves 14 bytes, but requires 39 more cycles (from 54 to 93)! That's quite a big hit.

Another example is the Push Integer to BASIC stack routine:

Code: Select all

    LDY #&03
    LDA &2D
    STA (&04),Y
    DEY
    LDA &2C
    STA (&04),Y
    DEY
    LDA &2B
    STA (&04),Y
    DEY
    LDA &2A
    STA (&04),Y
That's blatantly an unrolled loop, yet writing it as a loop would save 10 bytes but cost 17 cycles (from 44 to 61).

With a quick browse, I spotted around 30 integer and floating point routines in total which could probably benefit from size optimisation, which could maybe win back 300 bytes if not more, but the performance hit would possibly be significant - to the point that I could imagine maths code maybe running 30% slower.

So, yes, I agree with your conclusion that Sophie optimised the maths code for speed, and the rest was packed in a far more space efficient way.

The biggest problem with the 6502 architecture for this kind of optimisation is that there is no zp,Y addressing mode (to use at the same time as (ind),Y). As soon as you need to mix the two in a loop, you either need to bring in X as an additional index counter (going from &FC to &00 if necessary), or you have to deal with 16-bit memory accesses.

User avatar
BigEd
Posts: 2775
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: LOG and LN lack of standardisation?

Post by BigEd » Thu Jul 18, 2019 10:20 am

It seems likely that you'd write a 16k Basic by first writing everything you need, and as you overflow the 16k cramming down the stuff which seems least performance critical. At the end, you just fit the ROM and the remaining code is as fast as it could be. (If you'd needed to squeeze a bit more in, then some of the existing code would have to get smaller and go slower.)

scruss
Posts: 159
Joined: Sun Jul 01, 2018 3:12 pm
Location: Toronto
Contact:

Re: LOG and LN lack of standardisation?

Post by scruss » Thu Jul 18, 2019 11:05 am

Coeus wrote:
Thu Jul 18, 2019 9:07 am
Reading that test case, though, is a useful reminder of how much improved BBC BASIC is generally from this "minimal" BASIC.
Minimal BASIC, though, was intended as a subset standard that all BASICs should support. Kemeny, of Dartmouth BASIC fame, sat (chaired?) the ANSI BASIC working group. There's ANSI/ECMA Full BASIC developed in the mid-80s which has graphics support, a much richer syntax for structured programming and reinstates Dartmouth's matrix functions. It also expects support for decimal floating point which was spottily supported by developers. MSX BASIC uses decimal floating point but most other MS BASICs don't.

User avatar
Richard Russell
Posts: 1091
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: LOG and LN lack of standardisation?

Post by Richard Russell » Thu Jul 18, 2019 3:13 pm

scruss wrote:
Thu Jul 18, 2019 8:57 am
I think the simplest explanation is that someone at Acorn dun goofed.
It wasn't Acorn's decision though. They could propose LN() and LOG() but it was up to the BBC - and in part that meant me - to approve them. As the evidence points to it being well known at the time that the proposal was non-standard it seems more likely that the BBC was persuaded that it had advantages that outweighed the incompatibility. Although I was probably closely involved, my age and dementia have sadly robbed me of any memory of it.

User avatar
BigEd
Posts: 2775
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: LOG and LN lack of standardisation?

Post by BigEd » Thu Jul 18, 2019 4:02 pm

I can readily imagine that anyone from secondary education would be in favour of base 10 logs - they are the sort of logs they themselves would have used, from log tables. Only with base 10 can you relate the decimal point's location simply to the size of the log.

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 4:11 pm

Maybe, but when I was at secondary school, log tables, although taught, were quickly being superseded by the electronic calculator. I think we only used them for a couple of lessons. This was in the early to mid 1980s.

Mark

User avatar
BigEd
Posts: 2775
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: LOG and LN lack of standardisation?

Post by BigEd » Thu Jul 18, 2019 4:57 pm

Right, but your teachers would remember them well!

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 4:58 pm

So, a look through the (paper) manuals that I have shows:

BBC A, BBC B - LN - natural logarithm base e
BBC A, BBC B - LOG - common logarithm base 10

ZX81 - LN - natural logarithm base e
Memotech MTX - LN - natural logarithm base e
ZX Spectrum - LN - natural logarithm base e
QL - LN - natural logarithm base e
QL - LOG10 - common logarithm base 10

Video Genie - LOG - natural logarithm base e
Tandy TRS-80 Model 100 - LOG - natural logarithm base e

Commodore 64 - LOG - natural logarithm base e
Commodore 128 - LOG - natural logarithm base e

Amstrad CPC6128 - LOG - natural logarithm base e
Amstrad CPC6128 - LOG10 - common logarithm base 10

Cambridge Z88 (BBC BASIC) - LN - natural logarithm base e
Cambridge Z88 (BBC BASIC) - LOG - common logarithm base 10
Note: this is version 3.00 copyright R.T.Russell 1987

Amstrad NC200 (BBC BASIC) - LN - natural logarithm base e
Amstrad NC200 (BBC BASIC) - LOG10 - common logarithm base 10
Note: this is version 3.12 copyright R.T.Russell 1992

Mark
Last edited by 1024MAK on Thu Jul 18, 2019 5:27 pm, edited 2 times in total.

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 5:18 pm

So one thing that I have noticed, is the U.K. computer companies mostly use LN. Whereas the U.S.A. and international companies use LOG.

The ZX Spectrum, QL, and Memotech MTX almost certainly took LN forward as that was the function on the ZX81.

Later machines that presumably had larger ROM chips, or which used more compact code, included LOG10.

If the BBC BASIC ROM is full, maybe LOG started off as LOG10, but the 10 was dropped to save a couple of bytes?

Mark
Last edited by 1024MAK on Thu Jul 18, 2019 5:19 pm, edited 1 time in total.

User avatar
Richard Russell
Posts: 1091
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: LOG and LN lack of standardisation?

Post by Richard Russell » Thu Jul 18, 2019 5:38 pm

1024MAK wrote:
Thu Jul 18, 2019 5:18 pm
The ZX Spectrum, QL, and Memotech MTX almost certainly took LN forward as that was the function on the ZX81.
So which was the first home computer to use LN rather than LOG? The ZX81 was released a year or so before the BBC Micro, so it must surely have been a major factor in BBC BASIC using LN.

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 6:22 pm

Looking online...

MITS ALTAIR BASIC 1975 - LOG - natural logarithm base e - see http://altairclone.com/altair_manuals.htm

Microsoft BASIC-80 5.0 - LOG - natural logarithm base e - http://altairclone.com/altair_manuals.htm

Microsoft BASIC copyright 1979, 1982 - LOG - natural logarithm base e - see http://chiclassiccomp.org/docs/content/ ... erence.pdf

Microsoft GW-BASIC - LOG - natural logarithm base e - see http://www.divonasperi.it/divona/tam/te ... glese).pdf

Mark

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 6:29 pm

Richard Russell wrote:
Thu Jul 18, 2019 5:38 pm
1024MAK wrote:
Thu Jul 18, 2019 5:18 pm
The ZX Spectrum, QL, and Memotech MTX almost certainly took LN forward as that was the function on the ZX81.
So which was the first home computer to use LN rather than LOG? The ZX81 was released a year or so before the BBC Micro, so it must surely have been a major factor in BBC BASIC using LN.
I don’t have an answer to that, but the Wikipedia article on Natural Logarithm is interesting reading. So it makes me wonder if this difference in the name of the function came from mathematics.

Mark

User avatar
jgharston
Posts: 3798
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: LOG and LN lack of standardisation?

Post by jgharston » Thu Jul 18, 2019 6:40 pm

hoglet wrote:
Wed Jul 17, 2019 7:34 pm
It's likely no faster than what you have, but another alternative to CPY #4 in this case is:

Code: Select all

TYA
AND #$03
BNE loop
EOR #matchvalue is a CMP-without-carry, leaving A=0 and EQ if matches.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3798
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: LOG and LN lack of standardisation?

Post by jgharston » Thu Jul 18, 2019 6:43 pm

Richard Russell wrote:
Thu Jul 18, 2019 7:09 am
scruss wrote:
Thu Jul 18, 2019 1:02 am
BBC BASIC fails every one of of the tests in ANSI BASIC test 124.1.
The ANSI BASIC standard came along a couple of years after BBC BASIC, I think, so isn't something that could have influenced the decision taken by Acorn and the BBC at the time.
Also, being intended to be used in schools, I think it's a valid comment that teachers would have wanted the functions to have the same name as the labels on calculators, avoiding hours of "Sir! Sir! My calculator says the computer's wrong!"

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
1024MAK
Posts: 9603
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: LOG and LN lack of standardisation?

Post by 1024MAK » Thu Jul 18, 2019 6:48 pm

Last edited by 1024MAK on Thu Jul 18, 2019 7:42 pm, edited 2 times in total.

Post Reply