Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Strange kind of math?

Author
Message
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 29th Nov 2002 12:51
Link
Try this with Patch 3:
x=16*2/4
PRINT x
WAIT KEY

With Patch 1 the result was 8 if I remember it right, but now it is 0. A new kind of mathematic?
If you use brackets, it works okay:
x=(16*2)/4
But now a division is performed before multiplication, even if the multiplication is earlier and has so higher priority, so patch 3 works this way:
x=16*(2/4)
2/4 is 0.5, so the integer result is 0, and 16*0 is 0. Any idea how this could happen? I use brackets from now on.

Aaaaaaaaarrrrrgggghhhh!
-----------------------------------------------------
PC: Amd Athlon 1200/512 Mb SDRam/GeForce2MX Dual Display Video/Win2000, 19" Monitor
ZX: ZX Spectrum 128+ Customized version.
Back to top
Profile PM
pathfinder
23
Years of Service
User Offline
Joined: 5th Sep 2002
Location:
Posted: 29th Nov 2002 13:08
Link
bah, its going to be hard going making games with all these basic maths bugs floating around

Back to top
Profile PM Email
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 29th Nov 2002 13:47
Link
It works if you use real numbers :



prints 8.

Dont forget to e-mail Lee

Good news everybody! I really am THAT good...
Back to top
Profile PM Email Website
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 29th Nov 2002 13:49
Link
or possibly not if the order precedence is actually correct...

Good news everybody! I really am THAT good...
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 29th Nov 2002 15:28
Link
MrTAToad: Surery this works, because if you use floats, it does not matter what´s first:
x#=16.00*2.00/4.00
If you operate with floats, the actual order of operation is still the same: 16.00*(2.00/4.00) is equal to 16.00*0.50, and the result is 8, but the little difference is there if you use integer, because with itegers two divided by four is not 0.5, but 0! This does not change anything about the bug. The order of mathematic operation is simply wrong.
If Lee does not read this forum, I will E-Mail him today again.
Lee, did you noticed the bug? Also the SYNC ON:SYNC bug too?

Btw: With Patch 3 the function READ FLOAT from file is four times faster than earlier with Patch 1, this is great!

-----------------------------------------------------
PC: Amd Athlon 1200/512 Mb SDRam/GeForce2MX Dual Display Video/Win2000, 19" Monitor
ZX: ZX Spectrum 128+ Customized version.
Back to top
Profile PM
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 29th Nov 2002 15:44
Link
Shame they don't list the precedence for mathematical signs in the instructions..

I must admit this certainly looks like a bug...

Good news everybody! I really am THAT good...
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 29th Nov 2002 15:52
Link
division and multiplication have the same priority, but if a multiplication is computed before division, division should not have the priority over multiplication, and it was working in such a way in patch 1, but I presume that Lee changed something in the code to patch a different bug, and caused a new one.

-----------------------------------------------------
PC: Amd Athlon 1200/512 Mb SDRam/GeForce2MX Dual Display Video/Win2000, 19" Monitor
ZX: ZX Spectrum 128+ Customized version.
Back to top
Profile PM
MrTAToad
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 29th Nov 2002 15:53
Link
Send a bug report then...

Good news everybody! I really am THAT good...
Back to top
Profile PM Email Website
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 29th Nov 2002 17:45
Link
Doesn't DBpro follow BIDMAS:- brackets, indicies, division, multiplication, addition and subtraction. If so multiplication should come after division, and so the answer is correct, anyway its not that hard to put brakets in to get around the problem anyway

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 29th Nov 2002 20:11
Link
@haggisman: Probaly since Patch 3? Then with Patch 1 the answer was not correct? (But it was correct) . Anyway, I sent the next Bug report to Lee...
I told allready that this is easy to workaround with brackets, but a bug is a bug.

-----------------------------------------------------
PC: Amd Athlon 1200/512 Mb SDRam/GeForce2MX Dual Display Video/Win2000, 19" Monitor
ZX: ZX Spectrum 128+ Customized version.
Back to top
Profile PM
Easily Confused
23
Years of Service
User Offline
Joined: 22nd Oct 2002
Location: U.K. Earth. (turn right at Venus)
Posted: 29th Nov 2002 23:43
Link
I don't know if the DBPro team intended this, it appears we can now divide by zero.

Print 12/0 will return 12.

"Earth is the cradle of humanity,
but one cannot live in a cradle forever"
Konstantin E. Tsiolkovsky (1911)
Back to top
Profile PM
hexGEAR
23
Years of Service
User Offline
Joined: 3rd Nov 2002
Location: Naytonia
Posted: 29th Nov 2002 23:54
Link
BODMAS - the rule of BODMAS states the division has priority over multiplication (hence D before M), thus 16* 2/4, so 2/4 is treated first b4 16 * 0.5.

your birth was a blessing, sent to live and die on earth as a lesson, we each have a star all you have to do is find it, once you do, everyone who sees it will be blinded - DMX
Back to top
Profile PM Email Website
Flashing Blade
23
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 30th Nov 2002 00:31
Link
i still on patch 2 and i get 0 too but thats correct answer becuase x is integer
ie 2/4=0.5 (which is 0 as integer)
but x#=16.0*2.0/4.0=8
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 30th Nov 2002 01:45
Link
@Flashingblade: So Patch 2 introduced this... I never was able to use Patch 2. I was working with variables, so anything was integer math, and I expected that multiplication is executed first, because division and multiplication should have equal priority like in any other BASIC language.
@hexgear: Where in the manual or help file is this BODMMAS mentioned? As I said before, all was fine with Patch 1.
If DBP uses BODMAS rule, so why in the Hell this was introduced in Patch 2 without mentioning it? I´m still sure that this is a bug!
@Easily Confused: Division by ZERO? Huh, that did not crash the compiler? Strange Math, but it is okay. so I did not need to to use (cn1+1).

PC: AMD 1200/512 Mb SDR/GF2MX Dual Display/Win2000, 19" Monitor
ZX: Spectrum 128+ Customized version.
Current Project: BMP2SCR Pro (with LDIR)
Back to top
Profile PM
Flashing Blade
23
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 30th Nov 2002 16:07
Link
very interesting. I thought DBP was correct in returning 0 from equation 16*2/4 because of the BoDMAS rule.
But I compiled the following in Borland C++

#include <stdio.h>

void main()
{
int x;
x=16*2/4;
printf ("%d",x);

return 0;
}

now according to the BoDMAS rule it should have returned 0, but it returned 8!

So who's correct - Viktor & Borland or DBP & BoDMAS?
Back to top
Profile PM Email Website
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 30th Nov 2002 16:51
Link
They are both right as long as the progams are following their math rule set properly.

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 30th Nov 2002 17:23
Link
Because I sent this problem to Lee vie Mail, we will see with the next patch, who was right... If Lee will fix this, so it was a bug, and if he did not fix it, then it is a feature .
@haggisman: Please tell me any other language that follows these BODMAS rules and give a result of 0... Try this wits QuickBasic, Turbo Basic, RapidQ, Dark Basic and any other language, the result is allways 8 as it should be.
Probaly Rich or Lee can join the discussion and tell us who is right and who is completly wrong.

PC: AMD 1200/512 Mb SDR/GF2MX Dual Display/Win2000, 19" Monitor
ZX: Spectrum 128+ Customized version.
Current Project: BMP2SCR Pro (with LDIR)
Back to top
Profile PM
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 30th Nov 2002 17:46
Link
there is no right or wrong, The bidmas set of rules are very common in mathematics today, It doesn't matter whither some rules give different answers to others, as long as they are consistent. Im sure if you go to another country their laws will be different, even some to extremes, would it make their laws any less than yours?

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Flashing Blade
23
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 30th Nov 2002 19:47
Link
no right or wrong?? - DBP gives 0 and C++ gives 8 (two different answers to same equation - how can both be right?)
I'm saying if 0 is the correct answer then DBP is right (and BoDMAS is used).
If 8 is correct answer then BoDMAS is not used and C++ (and Viktor) are right. Or D&M in BoDMAS only have priority over each other in accordance with where they appear in the equation (like viktor says).
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 30th Nov 2002 20:02
Link
I am 98% sure that the 1987 ANSI spec for BASIC
indicates that in a BASIC statement

* and / take precedent over + and -

* and / are processed left to right

then + and - are processed left to right
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 30th Nov 2002 20:07
Link
There should be no question about this.
I assume that Lee has at least one of these.

The BASIC language is described in these standards:
ANSI Standard for Minimal BASIC (X3.60-1978)

ANSI Standard for Full BASIC (X3.113-1987)

ISO Standard for Minimal BASIC (ISO 6373:1984 Data processing - Programming languages - Minimal BASIC)

ISO Standard for Full BASIC (ISO/IEC 10279:1991 Information technology - Programming languages - Full BASIC)
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 30th Nov 2002 20:14
Link
After reading this google result, I'm now 100% sure that my recollection of the 1987 ANSI BASIC spec is exactly how FORTRAN works.
--------------------------------------------------------

Search Result 4
From: M. J. Saltzman ([email protected])
Subject: Re: Interpretation of unparenthesized expressions
View: Complete Thread (27 articles)
Original Format
Newsgroups: sci.math
Date: 1991-04-18 15:59:16 PST


In article <[email protected]> [email protected] (Jeff Carroll) writes:
>
> It wasn't until I took my freshman FORTRAN class that I was introduced
>to the concept of operator precedence. Even there I was taught that it was not
>good programming style to count on operator precendence when using parens
>would make code easier to read.
>
FORTRAN, C, Pascal, Modula-2, PL/I, BASIC all conform to the same notion of
operator precedence (at least WRT *, /, +, -). (APL and LISP were the
first languages I encountered that didn't.) A compiler for any of
these languages that doesn't perform * and / before + and - is simply
broken. I firmly believe that this was done to conform to the
convention in the rest of the world that * and / have precedence
over + and -. It certainly wasn't done to make writing the compiler
easier.

The advice to parenthesize expressions in FORTRAN stems in part from
the fact that finite-precision arithmetic is not associative, that is,
(a+b)+c may give a different numerical result than a+(b+c) due to
cancellation, loss of precision or overflow. In FORTRAN, the
programmer can control the order of association of operators at the
same precedence level by adding parentheses, and (if I recall
correctly) the compiler must follow the sequences implied by the
parenthesized expression. If there are no parentheses, the compiler
is free to make any association that is convenient. C compilers do
not have this requirement, that is, the compiler is free to choose
(a+b)+c even if the programmer wrote a+(c+b). Of course, this does
*not* affect the precedence of * over +, that is (...) will override
the precedence in (a+b)*c.

Readability is important too, but it has nothing to do with the
definition of the language. Over-parenthesizing doesn't help
readability either...
Back to top
Profile PM Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 30th Nov 2002 20:20
Link
This is pretty imporrtant
One more thing and I'll give it a rest.
Quoted From
http://www.nos.org/htm/basic1.htm

24.8 ARITHMETIC EXPRESSIONS

A BASIC system can handle arithmetic expressions involving the five arithmetic operators + (addition), - (subtraction), *(multiplication), /(division) and ^ (exponentiation). The hierarchy of operations is as follows:

(i) Exponentiation

(ii) Multiplication and division

(iii) Addition and subtraction

Thus, in a particular arithmetic expression, the order of execution is as per this hierarchy, i.e. all exponentiation operations are performed first, then multiplication/division and the addition/subtraction operations are the last to be carried out. Note that within a particular hierarchical group, the operations are executed form left to right. Normal hierarchy of operations can be altered by use of parentheses. The operations within the innermost parentheses are performed first and then the second innermost and so on.
Back to top
Profile PM Website
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 30th Nov 2002 20:37
Link
hmm i wonder if those standards have any information about types in BASIC or even using vertex shaders?

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 30th Nov 2002 20:57
Link
These "Standards" are the minimum requiremenst to call a Language "BASIC". Any "BASIC" can have additional features, instruction sets, to handle special tasks like 3D graphic, but these features are not standartized, so another BASIC did not need to have the same instructions. The names of additional instructions may be also changed from version to version (DOT/PSET/PLOT), because BASIC standartizes just the Core, and it was standartized before it was common to write grapic routines, But Math was something common at this time, and so it is standartized.
After reading the answers from heartbone, I´m even more sure, this is a bug. We all learned a different kind of Math at the school.
LEE or RICH!!! Please help out!

PC: AMD 1200/512 Mb SDR/GF2MX Dual Display/Win2000, 19" Monitor
ZX: Spectrum 128+ Customized version.
Current Project: BMP2SCR Pro (with LDIR)
Back to top
Profile PM
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 30th Nov 2002 22:50
Link
Well i learnt Bidmas at school and am still using it during my A-level maths course. Maybe its just a british thing

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
hexGEAR
23
Years of Service
User Offline
Joined: 3rd Nov 2002
Location: Naytonia
Posted: 30th Nov 2002 22:58
Link
ok, i still have db classic, and just now i ran the code:

set cursor 200,200:print 16*2/4

it kept on printing 0 to the screen, the BODMAS rule is taken into account in db classic! since 2 and 4 are not considered real, 2/4 = 0, 16 * 0 = 0.

your birth was a blessing, sent to live and die on earth as a lesson, we each have a star all you have to do is find it, once you do, everyone who sees it will be blinded - DMX
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 1st Dec 2002 01:45
Link
(Surprised...) Huh, DB Classic, et tu, Brute?
I already sold my DB1 because I got the DB Pro not as upgrade, but as a full version, but afaik, the code that I tried was working correctly here. If someone is still forced to use DB Pro Patch 1, please retest this operation.
Okay, I´m from Austria, and Austrian school level is just a few levels over the American, but still not so good as British, polish or russian, so I learned that Division and Multiplication have the equal priority that is over +/-, and +/- has equal pririty too and all operations are executed from left to right, and to override the priority I had to use brackets.
How stupid we austrians are...

Okay, I changed any critical mathematic operation now to use brackets, this solved the problems completly, but i must code more carefuly to avoid the colliosion of the both mathematic systems.

PC: AMD 1200/512 Mb SDR/GF2MX Dual Display/Win2000, 19" Monitor
ZX: Spectrum 128+ Customized version.
Current Project: BMP2SCR Pro (with LDIR)
Back to top
Profile PM
Karlos
23
Years of Service
User Offline
Joined: 18th Nov 2002
Location: United Kingdom
Posted: 2nd Dec 2002 11:56
Link
int x=16*2/4

Firstly DBP is correct in processing the divide first (BODMAS)
BUT... I think DBP should process the right hand side of the equation using real numbers to ensure accuracy before storing the final result as an integer.

This is why C++ is correctly storing 8 as a result.

Brackects seem a simple enough work around for now though.

Karlos

If it ain't broke - try harder.
W2K Pro - Geforce2 MX400 64MB - Athlon 900
Back to top
Profile PM Website
Thade!
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: Austria
Posted: 2nd Dec 2002 12:46
Link
x = 16*2/4
Print x

DisplaySurfW=450
DisplaySurfH=500
MySurfaceW=567
MySurfaceH=425

TempH=1.0*MySurfaceH/MySurfaceW*DisplaySurfW
Print TempH

WaitKey()

In Blitz3D the results are 8 and 337 what is right.
And without the 1.0 (what makes it a floatcalculation) its 0 what is right, too.

The same in Jamagic:

x = 16*2/4;
WriteLn(x);
DisplaySurfW=450;
DisplaySurfH=500;
MySurfaceW=567;
MySurfaceH=425;

TempH=1.0*MySurfaceH/MySurfaceW*DisplaySurfW;
WriteLn(TempH);

While(1);

Results in 8 and 0.00166569
That shows that the wrong behaviour is even translated into Floating Point Values
In Jamagic there is a priority of Division (/) bfore Multiplication (*) documented!


x= 16*2/4
print x

DisplaySurfW=450
DisplaySurfH=500
MySurfaceW=567
MySurfaceH=425

TempH=1.0*MySurfaceH/MySurfaceW*DisplaySurfW
print TempH

wait key

Dark Basic Pro (Patch3.1) Results: 0 and 0

This is - we have to admit completely wrong. That's what a 2 year old child would answer.

We notice that Basic <> Basic or Basic != Jamagic
And even simple math rules are interpreted different in different languages.
The annoying thing is, that there's no documentation how it functions - so we all have to work out our workarounds by ourselves and waist time and (time is money) money for that.
Back to top
Profile PM Email
Kale
23
Years of Service
User Offline
Joined: 8th Sep 2002
Location: United Kingdom
Posted: 2nd Dec 2002 14:20
Link
FYI PureBasic and JavaScript both calculate this to 8!

x=16*2/4
PRINT x

What the flame does not consume, consumes the flame.
----------------------------------------------------------------------
AMD XP2100+, Geforce4Ti 4400, 512Mb DDR, Abit KX7, WinXP Home
Back to top
Profile PM Email
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 2nd Dec 2002 19:54
Link
Within a legal implementation of BASIC
for this statement x=16*2/4
x must evaluate to 8

DBP is incorrect in processing the divide first.
BODMAS is not legal BASIC.

Viktor is entirely correct
there is a bug in operator precedent evalation.

Lock this topic.
Back to top
Profile PM Website
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 2nd Dec 2002 21:40
Link
why should they lock the topic? Just because the packages name contains 'Basic' doesn't mean it has to follow the law to the letter. I like the current math system, so i don't see why they should change it.

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Viktor
23
Years of Service
User Offline
Joined: 7th Oct 2002
Location: Austria
Posted: 3rd Dec 2002 01:13
Link
Okay, I got it, Some users think, this is correct, but all other know that this is a bug, just like me. Lee did not send me anything that confirms that this is not a bug, but we will see in next patch... So, now topic can be closed.

PC: AMD 1200/512 Mb SDR/GF2MX Dual Display/Win2000, 19" Monitor
ZX: Spectrum 128+ Customized version.
Current Project: BMP2SCR Pro (with LDIR)
Back to top
Profile PM
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 3rd Dec 2002 04:44
Link
Its also wrong for the intermediate value in the calculation to be converted to an int. Only the final value should be converted.
These should all produce the same result.

x=16 * (2/4)
print x
x=16 * 0.5
print x
print 16 * (2/4)
print 16 * 0.5
rem force floats
x = 16 * (2.0/4.0)
print x
wait key

Back to top
Profile PM
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 3rd Dec 2002 05:11
Link
It should work like this
http://mathforum.org/dr.math/faq/faq.order.operations.html

PEMDAS vs BEDMAS
These are the same. MD or DM left to right is the same thing. The only difference is BEDMAS refers to brackets [] like [16*2]/4 . Its more common to use parentheses (16*2)/4

Back to top
Profile PM
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 3rd Dec 2002 17:33
Link
No swdave this isn't a discussion of math.
This is a discussion about a lanugage implementation.

In that context DarkBASIC should follow the other LEGITIMATE IMPLEMENTATIONS of B.A.S.I.C. as defined in the ANSI and ISO specs. How could there possibly be any other resolution?

swdave for your education, 16*2/4 processed with the divide first becomes zero (16*0), there is a difference.


Also if any of the operands of a computer math operation are float, the result is a float else the operations are ALL integer. Computer operations would be too slow if your belief of internal amth calculations being done in float was actual practice.
Back to top
Profile PM Website
IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 3rd Dec 2002 21:40
Link
I program regularly in 3 different languages, and they all have different operator precedence. Personally, I don't think that it really matters.

If you always parenthesise your equations, they'll work anywhere. Because I do this, I didn't even notice that the DBPro implementation had changed

However, it is always nice to have stated and predictable levels of precedence.
Back to top
Profile PM Email Website
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 4th Dec 2002 00:47
Link
There is no math standards that say division first. They say division or multiplication process left to right before addition and subtraction.

Do you really think this is right?

print 2/4

Do you really think it matters how fast you can calculate the wrong answer?

Back to top
Profile PM
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 4th Dec 2002 01:21
Link
There is no math standards that say division first. They say division or multiplication process left to right before addition and subtraction.
Do you really think this is right?

YES THAT IS CORRECT.

print 2/4

Do you really think it matters how fast you can calculate the wrong answer?
No it doesn't, it matters how fast you can caluclate a correct answer. 2/4 = 0 for a computer and that is the expected answer.

I program regularly in 3 different languages, and they all have different operator precedence. Personally, I don't think that it really matters.
I am curous, what languages have different operator precedent rules than FORTRAN/BASIC/C?
Back to top
Profile PM Website
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 4th Dec 2002 03:30
Link
Rubish, 2/4=0 is wrong.

x = 2
y = 4
a# = x/y
print a#
wait key

Intermediate values should not be forced to an int.

Back to top
Profile PM
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 4th Dec 2002 05:12
Link
swdave for a computer
2 = 00000010
when the CPU divides by 4 it probably does two LSR
(Logical Shift Right) to the register
00000001 then 00000000
sorry bout that but dems de facks
Back to top
Profile PM Website
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 4th Dec 2002 08:02
Link
Sorry the x86 does not include an LSR instruction.
Use SHR instead or go back to mac programming.

I believe the result had been cast to an int.
a# = (int)(2/4)

Bye...

Back to top
Profile PM
Kangaroo2
23
Years of Service
User Offline
Joined: 26th Sep 2002
Location: United Kingdom
Posted: 4th Dec 2002 14:17
Link
You know what? I wouldn't mind about these problems because there are ways around them, but what happens once we all spend hours programming a working game, and then the rules change next patch?

Its just a suggestion, but in my programs I put a 'rem' statement about each aprt of my program I think is working around a bug, or may be different in the next update. That way if there are complications down the line, I'll have more idea which lines of code are causing the problem

* If the apocalypse comes, email me *
Back to top
Profile PM Email Website
Flashing Blade
23
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 4th Dec 2002 16:45
Link
sdwave -
x as int
x=2/4
print x

Every programming language out there would print "0"

As for intermediate values not being converted to integer and only the final result being integer....try this in C++:

x=16*2/4 (this results in x being 8)
x=16*(2/4) (this results in x being 0)

I was taght BODMAS at school but it seems, as far as programming languages go, it appears to be BO - D&M are calculated in the order of where they appear in the equation (left to right) - AS
I agree with heartbone and viktor - DBP should follow the same mathematical rules as all other languages.
Back to top
Profile PM Email Website
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 4th Dec 2002 21:52
Link
But DBpro aint every other language, its DBpro! If every other language decided you had to code in greek would you want DBpro to do the same.

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
Flashing Blade
23
Years of Service
User Offline
Joined: 19th Oct 2002
Location: United Kingdom
Posted: 4th Dec 2002 22:38
Link
yes
Back to top
Profile PM Email Website
swdave
23
Years of Service
User Offline
Joined: 6th Oct 2002
Location: United States
Posted: 4th Dec 2002 23:20
Link
x=16*2/4 (this results in x being 8)
x=16*(2/4) (this results in x being 0)

I tried it in c++ the result is 8 for both cases

Back to top
Profile PM
haggisman
23
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 4th Dec 2002 23:22
Link
Ok flashingBlade write some greek and lets see how well you do...

Specs:- 1GHZ athlon, Radeon8500, 192mb ram, winxp
Back to top
Profile PM Email Website
heartbone
23
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 5th Dec 2002 03:47
Link
C++ is non standard. Although it's been trying for quite a few years now to become standardized. swdave, what version are you using that promotes integers to floats in the intermediate calculations?

No matter what, DBPro is B.A.S.I.C. not C++, C#, C^ or what ever else they try to makeup. As a dialect of an established language it must conform to established standards.
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2026-06-10 07:54:25
Your offset time is: 2026-06-10 07:54:25