Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5921 > unrolled thread

BASIC oddity?

Back to article view | Back to comp.sys.acorn.programmer

Contents

  BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-03 17:16 +0000
    Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-03 19:31 +0000
      Re: BASIC oddity? druck <news@druck.org.uk> - 2020-01-03 21:00 +0000
        Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-03 22:26 +0000
          Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-04 10:40 +0000
            Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-04 16:08 +0000
              Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-04 16:22 +0000
                Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-04 17:24 +0000
                  Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-04 18:47 +0000
                    Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-06 08:58 +0000
                    Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-06 16:20 +0000
                      Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-07 08:49 +0000
                        Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-07 11:20 +0000
                          Re: BASIC oddity? David Higton <dave@davehigton.me.uk> - 2020-01-07 15:05 +0000
                            Re: BASIC oddity? Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-08 08:23 +0000
                              Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-08 10:26 +0000
                                Re: BASIC oddity? druck <news@druck.org.uk> - 2020-01-08 21:02 +0000
                                  Re: BASIC oddity? Richard Ashbery <basura@invalid.addr.uk> - 2020-01-09 12:53 +0000
                                    Re: BASIC oddity? Steve Fryatt <news@stevefryatt.org.uk> - 2020-01-09 23:16 +0000
                                Re: BASIC oddity? Steve Fryatt <news@stevefryatt.org.uk> - 2020-01-08 22:35 +0000
                              Re: BASIC oddity? Martin <News03@avisoft.f9.co.uk> - 2020-01-08 23:51 +0000
            Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-10 11:30 +0000
              Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-10 12:38 +0000
        Re: BASIC oddity? Jean-Michel <jmc.bruck@orange.fr> - 2020-01-06 20:39 +0100
          Re: BASIC oddity? Alan Adams <alan@adamshome.org.uk> - 2020-01-06 21:13 +0000
            Re: BASIC oddity? Steve Drain <steve@kappa.me.uk> - 2020-01-08 12:46 +0000

Page 2 of 2 — ← Prev page 1 [2]

#5946

On 08 Jan in article <bc36062f58.Matthew@sinenomine.freeserve.co.uk>,
   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> I hope you can both agree that BASIC is inconsistent between
> add/sub and multiplication.  

[Snip]

> If BASIC gave you access to the overflow and carry indicators or
> allowed you to declare variables as signed or unsigned it would be
> better.  However, we have to live with it as it is: I'm certainly
> not advocating changing it.

I agree it is inconsistent, but unless BASIC magically gains a
(backwards compatible) means of typing signed integers different from
unsigned, I am afraid we are stuck with it. 

The only way I can think of is to add a new Function keyword which
after and add or subtract returned the 4 possible flags for
Signed/Unsigned Underflow/Overflow. But I am not sure if it would be
any real use.

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#5949

Steve Drain wrote:
> druck wrote:
>> But anyway this highlights the lack of date and time manipulation
>> SWIs in RISC OS.
> I approached this lack ages ago in Basalt, which has a comprehensive
> set of datetime keywords. Maybe I could develop a module from this.

What SWIs do you think are lacking?

Does anyone else notice a lack of SWIs?

I have written quite a few time manipulation routines in assembler which 
I would be happy to incorporate, but I need a feel for which direction 
to go in. ;-)

[toc] | [prev] | [next] | [standalone]

#5950

In message <qv9n8o$9dt$1@gioia.aioe.org>
          Steve Drain <steve@kappa.me.uk> wrote:

> Steve Drain wrote:
>> druck wrote:
>>> But anyway this highlights the lack of date and time manipulation
>>> SWIs in RISC OS.
>> I approached this lack ages ago in Basalt, which has a comprehensive
>> set of datetime keywords. Maybe I could develop a module from this.

> What SWIs do you think are lacking?

> Does anyone else notice a lack of SWIs?

> I have written quite a few time manipulation routines in assembler which
> I would be happy to incorporate, but I need a feel for which direction
> to go in. ;-)

Maybe a Date_Calc one, allowing arithmetic operations on 5-byte time 
values.

ADD and SUB would be obvious. Maybe an option to return the result as 
centiseconds, or minutes, or hours, days, weeks, months, years for 
example. The centiseconds one would need to return in a 5-byte buffer. The 
others could, for example, return as the "convert to ordinals" one.

Would reverse calculations be useful, returning a 5-byte date-time?

I'm not sure it would need to handle dates as strings - the Territory 
module is the route for that.

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5933

In message <quoa19$o6o$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 03/01/2020 19:31, Martin wrote:
>> There is no way for BASIC to subtract two 5-byte integers, apart from
>> spliiting each to one 5-byte integer and one 1-bute - and handling
>> the case where the result is negative.

> I'd always opt for a bit of assembler to do that, as its every easy to
> do arbitrary sized arithmetic when you've got access to the CPU flags.

>> However, if the difference is small, or you can ignore the lest
>> significant byte, you may be able to chose a single 4-bytes that will
>> provide the difference.

> I'd never recommend that, no matter how sort the interval, an over flow
> will occur at some point (the next in about 10 years from now).

> But anyway this highlights the lack of date and time manipulation SWIs
> in RISC OS. The only things you can do with a 5 byte time is convert it
> to or from a string.

SWI Territory_ConvertTimeToOrdinals
return an integers block with centisecond, second, minute, hour, etc
PRM3 page 815


-- 
Jean-Michel BRÜCK (France)
Mél :jmc.bruck@orange.fr
Site : https://jeanmichelb.riscos.fr/
RiscOS 5.23 : RiscPc/IyonixPC/Raspberry/ARMX6.

[toc] | [prev] | [next] | [standalone]

#5934

In message <8c773c2e58.jmb@jmc.bruck.orange.fr>
          Jean-Michel <jmc.bruck@orange.fr> wrote:

> In message <quoa19$o6o$1@dont-email.me>
>           druck <news@druck.org.uk> wrote:

>> On 03/01/2020 19:31, Martin wrote:
>>> There is no way for BASIC to subtract two 5-byte integers, apart from
>>> spliiting each to one 5-byte integer and one 1-bute - and handling
>>> the case where the result is negative.

>> I'd always opt for a bit of assembler to do that, as its every easy to
>> do arbitrary sized arithmetic when you've got access to the CPU flags.

>>> However, if the difference is small, or you can ignore the lest
>>> significant byte, you may be able to chose a single 4-bytes that will
>>> provide the difference.

>> I'd never recommend that, no matter how sort the interval, an over flow
>> will occur at some point (the next in about 10 years from now).

>> But anyway this highlights the lack of date and time manipulation SWIs
>> in RISC OS. The only things you can do with a 5 byte time is convert it
>> to or from a string.

> SWI Territory_ConvertTimeToOrdinals
> return an integers block with centisecond, second, minute, hour, etc
> PRM3 page 815

And it  would be possible to do date-based arithmetic using this. Messy in 
the general case, because of varying month lengths, and leap years. For 
just elapsed time within a day or two, not too bad.

I did wonder whether switching to BASIC VI and putting the data into 
floats would be a workaround. The floats in BASIC VI have more than 40 
bits of precision.


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5942

Alan Adams wrote:
> Jean-Michel wrote:
>> druck wrote:
>>> But anyway this highlights the lack of date and time manipulation SWIs
>>> in RISC OS. The only things you can do with a 5 byte time is convert it
>>> to or from a string.
>> SWI Territory_ConvertTimeToOrdinals
>> return an integers block with centisecond, second, minute, hour, etc

And the other variants, now subsumed into Territory_ConvertTimeFormats 
in RO5.

The Territory SWIs are not very friendly. ;-)

> And it  would be possible to do date-based arithmetic using this. Messy in
> the general case, because of varying month lengths, and leap years. For
> just elapsed time within a day or two, not too bad.

You also have 'Day of Week' (DOW) and 'Day of Year' (DOY) which might be 
useful, but for extended periods you need the Julian Day Number (JDN). 
There is a suitable algorithm on the Wikipedia page.

> I did wonder whether switching to BASIC VI and putting the data into
> floats would be a workaround. The floats in BASIC VI have more than 40
> bits of precision.

With care I have used BASIC V floats to represent unsigned integer 
values greater than &7FFFFFFF, to do things like DIV and MOD in special 
cases. There is no universal way to do this, though.

In addition, a BASIC V float is adequate to hold a 5-byte UTC value. You 
cannot do anything with it directly, but the '|' indirection operator 
can copy it back into a buffer to be manipulated.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web