Forum > General
Questions regarding the use of ORD to optimize the code
jamie:
I now have a better understanding why there are so many confused people programming.
Left isn't right and right isn't left.
Warfley:
Im personally of the opinion that for higher level languages and high level types such as boolean, the programmer should not care about what the compiler does underneath. I think you should write code like:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---if A > B then Result := 1else Result := 2;or similar and the compiler should figure out if it wants to implement this via ord or via a jump. Or else you have things like this above:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- b := Boolean(4); WriteLn(Ord(b)); if b = True then WriteLn('b is True'); if ord(b) <> ord(True) then WriteLn('b is not truely True'); Where b is equal to true but not really
MarkMLl:
Since we don't have an if-then-else (or for that matter a case-of) expression one possibility would be
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---type TI_B= array[boolean] of integer; const i_b: TI_B= (2, 1); begin result := i_b[A > B];
and so on, but this would have the obvious disadvantage that it would work only for constants (unless the result values were rarely-changing so could justifiably be written to an array).
This would have the advantage that it would be handled by an address computation rather than a control transfer, which shouldn't cause a pipeline stall.
MarkMLl
MarkMLl:
--- Quote from: Warfley on April 29, 2022, 08:09:44 pm ---
--- Quote from: winni on April 29, 2022, 06:22:55 pm ---this has nothing to do with ord but with negativ, zero, positiv
--- End quote ---
Did you stop reading after the first line?
--- End quote ---
Happens :-)
--- Quote ---
--- Quote from: jamie on April 29, 2022, 06:29:14 pm ---The value u really can depend on is false. That should always be 0
--- End quote ---
This is not necessarily true. The language can define what is the result of comparisons, as well as the value of the true constant.
--- End quote ---
I've seen discussion of this in a forum far, far away (and long, long ago :-) where somebody came up with an example of true having the numeric value zero. I think it was something fairly extreme like BBC or Sinclair BASIC, but even a single attested example is sufficient to disprove an "always" assertion.
There's also the UNIX doctrine where zero indicates success, and any negative number indicates failure... without the numeric value necessarily providing useful information.
So I think the best that can be said is that when generating a Boolean value false is usually zero, and true should be "not false". But when evaluating a Boolean value things are far less clear-cut, with C generally taking non-zero as true while Pascal at its strictest insists that anything other than (the Booleans that correspond to) zero or one is erroneous.
MarkMLl
Bart:
There are more places in RTL where Ord(A Boolean) is used, so it's a pretty safe bet that Ord(False)=0 and Ord(True)=1.
Even things like Val() would fail if this weren't true.
Bart
Navigation
[0] Message Index
[#] Next page
[*] Previous page