TechVani: Semester 6 Electives and Labs | BTech CSE Practical Guide

Semester 6 - Page 5: Electives and Labs. 24 numbered practical topics, highlighted rules, worked cases, answered viva questions, workflow diagrams, evidence tables and a complete Python demo. General practical guide, not an official course basket, lab list, syllabus or submission rule. Check your current approved scheme and faculty handout.

Offline demo: Python 3, standard library only; six behavior assertions are executed. Synthetic console checks illustrate UCS cost, safe arithmetic, numeric rotation and simulated ownership. No graphics window, real authentication or complete compiler is provided. Linked lab files have their own runtime requirements.

Topic map

Electives and official course baskets
Selection by preparation, interest and goal
Lab aims and acceptance evidence
Clean setup and reproducibility
AI problem representation
BFS and DFS practicals
UCS and A* cost evidence
Heuristic admissibility and consistency
CSP and reasoning experiments
Learning evaluation and leakage
Lexer token evidence
Parsing, precedence and ASTs
Semantic checks and intermediate code
Compiler negative tests
Line rasterization and rounding
Transform order and conventions
Projection, clipping and perspective divide
Textures, depth and rendered evidence
Authorized security lab scope
Security controls and privacy evidence
Cross-subject test matrix
Report, citations and contribution
Viva demonstration and fallback
Semester revision and next step

1. Electives and official course baskets

An elective is chosen from an approved list, not an unrestricted internet course catalog. Offerings, credits, prerequisites and assessment depend on the current department scheme.

Worked example: Check this term's actual list before comparing Secure Coding with Data Visualization.

Exam question: Can this guide guarantee an elective is offered?
Answer: No. The current official scheme and timetable decide.

2. Selection by preparation, interest and goal

Use interest, prerequisites, goals and support to compare available options. A preference score does not override eligibility or scheduling conflicts.

Worked example: Scores 4+5+5+3=17 and 5+2+2+4=13 provide a comparison only after mandatory requirements pass.

Exam question: Does the higher sum guarantee the correct choice?
Answer: No. Availability, prerequisites and personal priorities still matter.

3. Lab aims and acceptance evidence

Define one observable outcome, input domain, expected result and environment before implementation. Distinguish a suggested exercise from a required experiment.

Worked example: For a line rasterizer, list endpoints, integer coordinate convention and the expected included endpoints.

Exam question: Can a generic lab idea replace the faculty experiment list?
Answer: No. Use the actual assigned list and format.

4. Clean setup and reproducibility

Record tool/runtime versions, dependencies, commands and data. Test a clean run rather than relying on hidden state from an earlier attempt.

Worked example: A Python numeric demo needs no graphics window; an OpenGL exercise needs a suitable rendering context.

Exam question: Does a copied screenshot prove a clean execution?
Answer: No. Reproducible code and actual run evidence are needed.

5. AI problem representation

Define state, start, goal test, legal successors and costs. Compare algorithms on exactly the same problem to isolate their behavior.

Worked example: A small maze's walls and neighbors stay fixed while BFS and UCS vary their frontier ordering.

Exam question: Does changing both graph and algorithm provide a clean comparison?
Answer: No. It mixes causes.

6. BFS and DFS practicals

BFS explores by depth and yields shortest edge count in an unweighted graph; DFS explores one branch deeply. Record visited handling and ordering.

Worked example: A cycle needs visited-state control. Neighbor order can change the returned DFS path.

Exam question: Does BFS optimize arbitrary weighted path cost?
Answer: No. Its shortest-path guarantee concerns equal/unit edge costs.

7. UCS and A* cost evidence

UCS prioritizes path cost; A* prioritizes g+h. State nonnegative-cost and heuristic assumptions, including graph-search handling.

Worked example: S-A-G costs 4+4=8; S-B-C-G costs 1+1+1=3. The three-edge route is cheaper.

Exam question: Is fewer edges always the cheaper route?
Answer: No. Compare actual edge weights.

S -> A (4) -> G (4): cost 8
S -> B (1) -> C (1) -> G (1): cost 3

Shortest edge count and cheapest weighted route are different objectives.

8. Heuristic admissibility and consistency

Admissibility means never overestimating remaining optimal cost; consistency requires h(u) <= c(u, v)+h(v). Implementation details matter for optimal graph search.

Worked example: A heuristic returning zero gives UCS ordering; deliberately larger values require explaining lost guarantees.

Exam question: Does a fast-looking heuristic automatically preserve optimality?
Answer: No. Check properties and algorithm handling.

9. CSP and reasoning experiments

Specify variables, domains and constraints, then test both satisfiable and impossible instances. Track pruning/branching evidence rather than only final answers.

Worked example: Two neighboring map regions cannot share a color under the stated constraint; an exhausted domain needs backtracking.

Exam question: Does domain pruning alone guarantee a solution?
Answer: No. It can expose failure or reduce search.

10. Learning evaluation and leakage

Split by the unit/time boundary required by the problem, fit preprocessing on training data only and report actual metric counts..

Worked example: Future outcomes must not enter features used for earlier predictions; held-out results should not drive repeated tuning.

Exam question: Can repeated tuning on the final test leave it untouched?
Answer: No. It becomes selection evidence.

11. Lexer token evidence

A lexer maps source characters to tokens with types, lexemes and positions. State identifier/number rules and reject invalid input rather than silently skipping it.

Worked example: For count+12, show ID, PLUS and INT with source positions; spaces can be skipped under an explicit rule.

Exam question: Is tokenization the same as parsing?
Answer: No. Parsing organizes tokens by grammar.

12. Parsing, precedence and ASTs

A parser checks grammar structure and builds a useful tree. Precedence and associativity must match the language specification.

Worked example: For 2+3*4, the multiplication belongs below addition in the AST; the arithmetic result is 14.

Exam question: Must an AST keep every punctuation mark?
Answer: No. It retains structure relevant to meaning.

Multiplication binds inside addition for 2+3*4.

13. Semantic checks and intermediate code

Separate valid syntax from declaration/type rules and later runtime behavior. Explain temporary values and evaluation dependencies in intermediate code.

Worked example: For 2+3*4, t 1=3*4 then t 2=2+t 1; an undeclared variable can be a semantic error despite parse success.

Exam question: Does parse success prove a program is meaningful or safe to run?
Answer: No. Later checks are separate.

14. Compiler negative tests

Test invalid characters, missing delimiters, leftover tokens and semantic violations. Save the observed error category and location.

Worked example: An expression with unmatched parentheses should fail with a useful diagnostic, not return a partial successful result.

Exam question: Can a lexer discard unknown characters without changing meaning?
Answer: Not generally. That can hide errors or alter the accepted program.

15. Line rasterization and rounding

Compare DDA and Bresenham across horizontal, vertical, gentle, steep and reversed endpoints. State tie behavior and endpoint inclusion.

Worked example: The Graphics core page's integer line code checks endpoints and adjacency; screenshot evidence adds display behavior separately.

Exam question: Does equal mathematical geometry always imply equal discrete pixel lists?
Answer: No. Rounding and tie conventions can differ.

16. Transform order and conventions

Record origin, axes, angle units and vector/matrix convention. Matrix composition order determines which operation acts first.

Worked example: In y-up coordinates, rotating (2, 1) +90 degrees about origin gives (-1, 2); screen y-down conventions need explanation.

Exam question: Can translation and rotation generally be swapped?
Answer: No. Their composition usually differs.

17. Projection, clipping and perspective divide

Separate model, view, projection, clipping and viewport stages. State orthographic/perspective choice and homogeneous-coordinate assumptions.

Worked example: A numeric transformed point is not proof that a renderer correctly clips a triangle crossing the view boundary.

Exam question: Does a matrix calculation alone establish a correct graphics window?
Answer: No. Actual rendering evidence is separate.

18. Textures, depth and rendered evidence

Compare filtering/mipmaps and depth behavior with repeatable camera/viewport settings. Record actual screenshots from the runtime being assessed.

Worked example: A distant textured surface can alias without appropriate minification handling; show the controlled comparison.

Exam question: Can a console-only demo claim texture rendering proof?
Answer: No. It reports numbers/text, not rendered pixels.

19. Authorized security lab scope

Use dummy data and local training systems with explicit permission. Record allowed actions and stop outside them.

Worked example: Practice owner checks against synthetic rows, not real classmates' accounts or a public production portal.

Exam question: Does enrollment in a security course authorize arbitrary scanning?
Answer: No. Permission and boundaries remain explicit.

20. Security controls and privacy evidence

Separate authentication, object authorization, query binding and output handling. Minimize collected fields and state a justified retention plan.

Worked example: A bound task ID plus trusted owner predicate addresses different boundaries; data collection still needs a purpose.

Exam question: Does hiding an edit button enforce server access control?
Answer: No. The server must check the action/resource.

21. Cross-subject test matrix

Each claimed behavior needs a specific expected/actual check. Keep negative cases and assumptions alongside positive results.

Worked example: The runnable local demo below checks one weighted search, one arithmetic syntax tree, one rotation and one synthetic permission boundary.

Exam question: Does this small demo replace complete subject lab work?
Answer: No. It illustrates separate contracts and explicit limits.

Four local contracts with explicit limits

import ast, heapq, math
# Tiny nonnegative weighted graph: this is UCS, not a complete AI lab suite.
graph = {"S": [("A", 4), ("B", 1)], "A": [("G", 4)], "B": [("C", 1)], "C": [("G", 1)], "G": []}
frontier = [(0, "S")]; best = {"S": 0}
while frontier:
    cost, node = heapq.heappop(frontier)
    if cost != best[node]: continue
    if node == "G": break
    for neighbor, weight in graph[node]:
        candidate = cost + weight
        if candidate < best.get(neighbor, math.inf):
            best[neighbor] = candidate
            heapq.heappush(frontier, (candidate, neighbor))
assert best["G"] == 3
# Safe whitelist interpreter of a Python AST, not a full compiler.
def arithmetic(node):
    if isinstance(node, ast.Constant) and type(node.value) is int:
        return node.value
    if isinstance(node, ast.BinOp) and isinstance(node.op, (ast.Add, ast.Mult)):
        left, right = arithmetic(node.left), arithmetic(node.right)
        return left + right if isinstance(node.op, ast.Add) else left * right
    raise ValueError("unsupported teaching expression")
result = arithmetic(ast.parse("2+3*4", mode="eval").body)
assert result == 14
try:
    arithmetic(ast.parse("x+1", mode="eval").body)
except ValueError:
    rejected = True
else:
    rejected = False
assert rejected is True
# Exact +90-degree y-up integer rotation, not a rendering window.
x, y = 2, 1
rotated = (-y, x)
assert rotated == (-1, 2)
# Synthetic permission predicate; real identity must come from trusted auth.
record = {"owner": "Asha", "title": "Revise transforms"}
def permitted(user): return user == record["owner"]
assert permitted("Asha") is True
assert permitted("Ravi") is False
print("6 behavior assertions passed")
print("UCS goal cost:", best["G"])
print("arithmetic:", result, "unsupported name rejected:", rejected)
print("rotated point:", rotated)
print("owner/other:", permitted("Asha"), permitted("Ravi"))
print("Synthetic console checks only: no graphics window, real auth or full compiler.")

Checked output:

6 behavior assertions passed
UCS goal cost: 3
arithmetic: 14 unsupported name rejected: True
rotated point: (-1, 2)
owner/other: True False
Synthetic console checks only: no graphics window, real auth or full compiler.

22. Report, citations and contribution

Include aim, method, versions, test inputs, actual output, failures, limits and sources. Credit borrowed code and each contributor.

Worked example: A team report identifies who implemented/tested each module instead of presenting external sample code as original work.

Exam question: Can copying a project solution be justified by calling it practice?
Answer: Submission must follow current academic rules and truthful attribution.

23. Viva demonstration and fallback

Run a complete story, explain a failure case and prepare a clean local fallback for unavailable hosted services. Do not claim the fallback proves the hosted path.

Worked example: Show a successful owner read and denied other-owner read, then explain trusted identity is simulated in the teaching demo.

Exam question: Should a failed hosted demo be described as working because local code runs?
Answer: No. State the difference and show the verified path.

Demo: one complete story
   -> invalid/permission case
   -> actual test evidence
   -> honest limits + contribution

Fallbacks stay useful without claiming unverified hosted behavior.

24. Semester revision and next step

Review AI search costs, lexer/parser/semantic boundaries, graphics conventions and authorization/privacy scope. Match final evidence to the actual assessment rubric.

Worked example: Use the linked tested lab files for additional exercises after checking their runtime notes and your official required list.

Exam question: What should be checked before submission?
Answer: Assigned requirements, clean execution, actual tests, attribution, private-data removal and honest limits.

Subject-to-practical evidence

Subject	Practice	Evidence
AI	Same-graph search comparison	Cost, route and implementation assumptions
Compiler	Tokens/grammar/semantics	Positive plus precise error cases
Graphics	Rasterization/transforms/rendering	Conventions plus numeric/pixel evidence
Security	Owner checks and bound queries	Authorized dummy-data positive/negative tests
Privacy	Purpose and minimum fields	Use/access/retention rationale

Test matrix

Case	Expected	Evidence
Weighted search	Cheapest supported route	Exact edges and total
Expression precedence	2+3*4 gives 14	AST structure and actual result
Invalid syntax/input	Useful failure	Error category/location; no silent skip
Rotation	(-1,2) for y-up +90 degrees	Input/convention and actual output
Unauthorized owner	No protected record returned	Real identity boundary in production
Graphics window	Expected drawn output	Actual runtime screenshot, not console only

Runtime distinctions

Exercise	Environment	Limit
Portable Python numeric demo	Python 3 standard library	Console data/text only
LLVM frontend tutorial	Tutorial C++ build/runtime	Not every online compiler
OpenGL renderer	Suitable libraries + graphics context	Console matrix is not rendered proof
Security sandbox	Explicitly permitted local system	No arbitrary account/network testing
Elective course	Current official basket	Generic suggestions do not grant eligibility

Submission and viva checklist

Check assigned experiments, course eligibility and format. Run clean setup, retain actual outputs and negative tests, cite sources and contributors, remove secrets/private records and state all limits. Additional linked lab files are resources, not a guarantee about your college requirements.

Resources and sources

Original links are preserved. The existing OWASP 2021 link is a historical resource, not a claim about the current ranking. Subject core pages and official documentation explain current concept/application assumptions.