|
Post by bitvast on Jul 11, 2014 9:21:12 GMT 1
Hi Peter,
You might have overlooked this in my posts above, but "<>" isn't working if you assign the result directly to a variable (although it's ok in WHILE and IF statements)-
a = 1 b = 2
x = (a <> b) PRINT x
baconshell.bac.c: In function 'main': baconshell.bac.c:64:13: error: expected expression before '>' token x=(long)(a <> b); ^
The C version "!=" is ok.
a = 1 b = 2
x = (a != b) PRINT x
1
Obviously, in this case it's nothing to do with strings.
|
|
|
Post by Pjot on Jul 12, 2014 17:54:58 GMT 1
Hi Bitvast,
Yes, also the '<>' symbol only is parsed in IF/THEN, WHILE and REPEAT. The native '!=' always works.
BR Peter
|
|
|
Post by Pjot on Jul 13, 2014 16:01:07 GMT 1
Hi bitvast, This whole issue is somewhat ambiguous. The thing is that BaCon understands various constructions for comparisons. The following code snippets have technically an equal meaning: z% = x$ == y$
z% = x$ = y$
We can easily see the problem here. The first snippet contains an assignment which should carry the result of a comparison. But the second snippet shows two assignments on the same line, while a single '=' is valid BASIC syntax for a comparison also. So, with our BaCon eyes we cannot see what the second code snippet is supposed to mean. Therefore, constructions with '==', '<>' etc are context dependent. A single '=' and a double '==' can both be used in comparisons (e.g. IF/THEN, WHILE and REPEAT), while a single '=' can be used in a numeric or string assignment (e.g. LET). But we're slightly obstructed by the history of BASIC. In later languages like C and Pascal, such ambiguity is cleaned up by using a single '=' for assignments (Pascal uses ':='), and a double '==' only for comparisons. Concluded, for this problem I would say "just don't do it" In BASIC it is a rare thing to assign the result of a comparison to a variable anyway, while such result in fact should be TRUE or FALSE - it's just a matter of luck that C accepts '1' and '0' instead. Best regards Peter
|
|
|
Post by bitvast on Jul 14, 2014 10:23:30 GMT 1
Hi Peter, Thanks. I wouldn't be pursuing this, but in my tutorial I've introduced operators (<, !=, etc) before control structures and wanted to give a few examples of how they work, which I'm starting to realise was probably a bad idea, given that, as you say, you wouldn't ordinarily assign the result of a comparison to a variable. I think this will be more confusing to a newbie than enlightening, so think I'll remove that part. Besides, it's giving me a headache. It's ok if you use brackets, assuming the types match, in which case x% is assigned whatever y% is, then x% is assigned to z%. DECLARE x%
y% = 3
z% = (x% = y%)
PRINT z% 3
|
|
|
Post by Pjot on Jul 15, 2014 1:59:51 GMT 1
Thanks bitvast, In such case it is indeed just assignment to assignment. But to quote the manual: "Each line should begin with a statement." So even a line like 'a = (b = c)' in fact is a statement, namely LET - however, the LET keyword itself may be omitted from the code. However, LET only accepts one assignment in one level, therefore additional brackets are needed. Anyway, I will add a remark to the manual not to mix assignments with comparisons BR Peter
|
|
|
Post by bitvast on Jul 16, 2014 10:53:32 GMT 1
Thanks Peter.
I'm getting some unexpected results using FORMAT.
This is ok:
x# = 10 y# = 9
PRINT "x / y = ", x#/y# x / y = 1.11111
But adding the format statement to limit the number of decimal places:
x# = 10 y# = 9
PRINT "x / y = ", x#/y# FORMAT "%1.2f"
results in
1203947251918621462241330729493416901671145133710686310629374222279884452698276246736800454757217177202188557551608230613139724307564679371120239112241409690858135301369279242836380879149611178889085261502419818764270973878501426394059243520.00
EDIT
Ok, my mistake. It was because there should be as many parameters in the format string as there are in the print statement.
In the 2nd program it should have been FORMAT "%s%1.2f"
|
|
|
Post by vovchik on Jul 16, 2014 12:01:51 GMT 1
Dear bitvast,
You are trying to print two things but your FORMAT statement contains only one referenced element type (the number). Try this:
That works for me....
With kind regards, vovchik
PS. You beat me to it! I hadn't updated my page before replying. Sorry.
|
|
|
Post by alexfish on Jul 20, 2014 2:51:32 GMT 1
Hi Peter
this is not a bug,
Thinking...
// could // look better than old ' . // is more pronounced, ' is easy one key press ,but Not c like Nor Basic like.. REM is BASIC like , so that looks fine
Alex
|
|
|
Post by bitvast on Jul 20, 2014 10:37:58 GMT 1
Hi Peter,
The INVERSE option in the COLOR statement isn't highlighted in bacongui (latest version).
|
|
|
Post by Pjot on Jul 20, 2014 11:38:44 GMT 1
Thanks bitvast,
Fixed - after you have updated the syntaxfile it should show correctly.
BR Peter
|
|
|
Post by alexfish on Aug 6, 2014 14:18:36 GMT 1
Hi Peter
looks like got a problem.
here compiling demos with hug_elm.bac
think these two lines show what the problem is
Alex
|
|
|
Post by Pjot on Aug 7, 2014 14:26:14 GMT 1
Hi Alex,
First I thought this is a bug, but I cannot reproduce the problem. Can you show some error output?
Thanks Peter
|
|
|
Post by alexfish on Aug 7, 2014 17:25:10 GMT 1
Hi Peter Have posted code + results on Elementary thread . HEREBR Alex
|
|
|
Post by bitvast on Aug 8, 2014 12:37:38 GMT 1
Hi Peter,
Shouldn't this code generate a "divide by zero" error?
x = 1 y = 0
IF x > 0 AND (x/y) > 0 THEN PRINT
But it doesn't.
|
|
|
Post by Pjot on Aug 8, 2014 12:58:07 GMT 1
@ alex: thanks I will look at it this weekend (currently I am at an airport traveling back home).
@ bitvast: no, it doesn't. The reason is that C will evaluate from left to right. First it sees the 'x > 0' clause, which already is not the case, so the rest of the line will not be evaluated anymore.
If you really would like to see a 'division by zero' error then do the following:
IF (x/y) > 0 AND x > 0 THEN PRINT
BR Peter
|
|