Gỡ rối tơ lòng
Các thắc mắc về KHMT, về toán học máy tính, về cách post bình luận trên blog, … xin post ở đây. Chúng tôi sẽ cố gắng trả lời nếu khả năng và thời gian cho phép. Các bạn đọc của blog cũng có thể trả lời và thảo luận các câu hỏi. Nếu câu hỏi có implication sâu hơn thì ta chuyển thành một bài mới.
179 lời bình cho bài “Gỡ rối tơ lòng”
Trang: « 1 … 2 3 4 5 6 7 8 9 10 11 [12] Xem hết
Trang: « 1 … 2 3 4 5 6 7 8 9 10 11 [12] Xem hết
Gui anonymous: FT ban đầu xuất phát từ ý tưởng của J. Fourier là có thể xấp xỉ một hàm bất kỳ bằng tổng vô hạn các hàm Sin và Cos và 1 giá trị hằng số nào đó (bực quá vì không gõ được công thức toán). Ý tưởng này ban đầu nhằm giải quyết bài toán truyền nhiệt từ 1 điểm ra môi trường xung quanh. Sau này FT kết hợp với công thức Euler được phát triển và ứng dụng trong rất nhiều ngành Kỹ thuật, vẫn còn có giá trị đến tận bây giờ, ít ra là trong ngành Xử lý tín hiệu.
Điểm hay của FT là:
- Thông qua FT có thể phân tích bất kỳ tín hiệu đầu vào thành tổng của các tín hiệu cơ sở, trong khi đó ta đã biết đáp ứng của hệ thống tuyến tính đối với từng loại tín hiệu cơ sở này rồi. Do vậy đáp ứng ra của hệ thống tuyến tính bằng tổng của các đáp ứng của hệ thông tuyến tính đối với từng thành phần của tín hiệu đầu vào
- Có thể tính đạo hàm cấp n một cách rất dễ dàng (bên Toán gọi là “tính đạo hàm thông qua thác triển Fourier”)
- Phân tích phổ của tín hiệu, hệ thống
…
Điểm chưa hay của FT là:
- Biến đổi Fourier có độ phân giải phổ là vô hạn
- Biến đổi Fourier không có độ phân giải trong miền thời gian
- Vận tốc hội tụ thấp đối với các tín hiệu có tồn tại một số điểm bất liên tục vì: để xấp xỉ được những điểm bất liên tục hoặc những điểm biến đổi nhanh, tham số n trong hàm sin và cos phải tiến đến vô cùng.
Để giải quyết những hạn chế trên, Biến đổi Fourier thời gian ngắn đã được để xuất như sau: Trước khi lấy tích phân ta nhân với hàm cửa sổ, do vậy phép biến đổi Fourier thời gian ngắn có một số hạn chế sau:
- Bề rộng cửa sổ cố định do vậy không thích hợp đối với loại tín hiệu có cả đoạn biến đổi chậm và nhanh
- Độ phân giải bị giới hạn bởi nguyên lý bất định của Heinsenberg.
Thật khó diễn giải vì tôi không gõ được Công thức ở đây, nếu bạn quan tâm, hãy gửi email tới hoangmanhha@yahoo.com , ta sẽ trao đổi tiếp
HTA
Chào anh Hưng,
Em đang học về theory of computation, có thắc mắc sau: liệu giả thuyết Church-Turing ở một trường hợp riêng cho máy tính PC quen thuộc thì đã được chứng minh hay chưa.
Ý của em là: liệu có ai đó đã bỏ công ra chọn một bộ vi xử lí theo kiến trúc Intel thật đơn giản, rồi ngồi chứng minh chặt chẽ rằng quả thật TM có thể giả lập được tập lệnh cơ bản của bộ vi xử lí đó và ngược lại.
Sở dĩ em có câu hỏi này là do đọc được một tài liệu tiếng Việt nói rằng, “người ta ĐÃ CHỨNG MINH được mọi máy tính quen thuộc ngày nay đều tương đương với một TM”. Trong khi đó em nghĩ từ trước đến giờ người ta chỉ hay chứng minh TM tương đương với các máy trừu tượng khác như post, lamda, … chứ chưa bao giờ chứng minh nó tương đương với một cái máy tính thật (chẳng hạn CPU X086 của Intel) vì người ta tin chắc rằng nó sẽ tương đương và hơn nữa việc chứng minh này là quá phức tạp không ai dại gì làm.
Em tra Internet mãi mà khong thấy có chỗ nào nói về việc chứng minh TM tương đương với một CPU nào có thực cà.
Anh giúp em nhé, cám ơn anh.
Hình như dạo này mọi người ít quan tâm đến “Gỡ rối tơ lòng”
ít thấy có tranh luận sôi nổi như trước đây
HTA
Em chào các anh chị trên diễn đàn!
Em đang làm cái nén ảnh tĩnh JPEG dùng biến đổi DCT với Arithmetic Coding theo chuẩn JPEG có đề cập trong cuốn sách này “JPEG Still Image Data Compression Standard”. Em không có cuốn này mà chỉ có thể xem nó trên Google Books tại:
http://books.google.com.vn/books?id=AepB_PZ_WMkC&printsec=toc&dq=%22Still+Image+Data+Compression+Standard%22%2B%22William+B.+Pennebaker%22%2Bdownload&source=gbs_toc_s&cad=1#PPA167,M1
Tuy nhiên có một số trang quan trọng thì họ không cho xem.
Em đang đọc chương 9, JPEG BINARY ARITHMETIC CODING, nhưng trang cuối cùng là trang 168 thì không xem được.
Nếu anh chị nào có cuốn này thì có thể cho em xin một số trang đó được không ạ. Có thể là bản scan của trang đó chẳng hạn.
Em xin chân thành cảm ơn!
Chào các anh chị!
Em có câu hỏi nhỏ thắc mắc từ lâu mà chưa nghĩ ra được câu trả lời.
Em không thể nào lấy nổi một ví dụ trực quan để minh họa là Sai suy ra Đúng lại là Đúng.
và tương tự với sự tương đương giữa (A suy ra B) với (không A hoặc B). Chả lẻ chỉ có thể dùng bảng chân lý để chứng minh thôi sao?
Chào anh Hưng
Em có câu hỏi sau về C, tra Internet và hỏi mọi người nhưng chưa ra. Anh giúp em nhé:
Tại sao lại không được dùng toán tử & (lấy địa chỉ) với phần tử của mảng 2 chiều kiểu FLOAT. Ví dụ nếu muốn người dùng nhập giá trị kiểu FLOAT cho phần tử của mảng bằng lệnh scanf(…)
float a[3][5];
scanf(”%f”, &a[0][1]);
thì khi kiểm tra lại:
printf(”%f”, a[0][1]);
lại thấy không đúng với giá trị đã nhập vào (!!). Cách khắc phục thường là nhập qua một biến trung gian rồi gán lại cho phần tử của mảng.
Hơn nữa điều này chỉ xảy ra với kiểu FLOAT không xảy ra với các kiểu nguyên.
(em dùng DevC tức compiler là GCC)
Tại sao lại lạ vậy ???
PS: à anh trình bày lại code cho nó dễ nhìn hộ em cái
Ăn mừng Nga vừa qua được vòng bảng tí!
Xin lỗi chú Hưng, hôm nay gặp phải một vấn đề hóc búa mà chưa tìm ra lời giải đáp. Ngặt nỗi lại không biết hỏi ai. Tuy vấn đề không liên quan đến sở trường của chú, nhưng biết chú là người học cao, hiểu rộng nên cháu đánh bạo, hỏi thử một phen.
Câu hỏi là:
“Làm cách nào mà ta đo được điện tích q của một vật nào đó?”
Bởi vì câu hỏi có liên quan đến định luật Coulomb mà cháu đang học ở lớp 11, bài giảng về phần thí nghiệm của Coulomb quá sơ sài, làm cháu cứ thắc mắc mãi. Số là như mọi người có lẽ đã biết: F điện =k.|q1.q2|/r^2 khi xét hệ hai vật. Ông Coulomb hồi xưa dùng cái cân xoắn chi chi đó mà tính được hằng số K. Cháu không thể hiểu được là tại sao ông ta lại làm được, vì theo SGK, từ thí nghiệm của mình, ông chỉ mới xác định được lực F và r, chứ SGK chưa có nói là làm sao ông ta tính được điện tích q1, q2 cả. Nếu chú giúp được cháu câu này thì sẽ giúp cháu trả lời thêm các câu hỏi khác nữa. Cháu xin chú giúp đỡ, có thể trả lời giùm cháu, hoặc chỉ cho cháu tư liệu để tìm đọc ạ. Cám ơn chú rất nhiều!
HDuc: có lẽ một forum khác như Diễn Đàn Vật Lý là nơi mọi người biết tốt hơn tôi về câu hỏi này.
Chào anh Hưng,
Em đang có ý định sẽ đi theo con đường research trong ngành Computer Science, nhưng lại gặp vấn đề là em không thích coding/debugging nhiều, mà lại thích proving theorems như bên toán nhiều hơn.
Anh có thể cho em biết trong Computer Science có những hướng nghiên cứu nào ít liên quan đến việc coding/debugging và dùng nhiều các kỹ thuật về toán được không ?
Cám ơn anh.
Ai nói với Cường là Theorem proving không có debugging :-). Tôi mất vài tuần vừa rồi debug một chứng minh trong một bài báo sắp nộp, cuối cùng phải thiết kế lại chứng minh và chịu kết quả yếu hơn.
Anyway, làm về coding theory, algorithms, complexity theory, machine learning, distributed systems, v.v. đều có thể làm “prover” mà không làm “coder”. Cá nhân tôi nghĩ cách tiếp cận này là sai lầm. Coding is a LOT of fun và thật sự quan trọng cho phát triển tư duy trong ngành, kể cả khi chỉ chủ yếu là chứng minh định lý thì cũng cần biết và cần code. Một số định lý phải tìm “conjectures” bằng chương trình, chẳng hạn.
Cám ơn anh Hưng đã trả lời.
Thật sự thì khả năng coding của em cũng không tệ, và em cũng không phải là muốn bỏ hẳn việc coding, nhưng chỉ là muốn tìm những hướng nghiên cứu mà trong đó theory đóng vai trò chủ đạo và coding sẽ được dùng để hỗ trợ cho việc tìm các theorem hoặc chứng minh các theorem.
Em chỉ cảm thấy mình không thích những cách tiếp cận mà trong đó việc coding/debugging chương trình và làm experiment chiếm một khối lượng chủ yếu; ví dụ như mày mò ra một algorithm, coding/debugging, làm experiment để so sánh với các thuật toán khác, nếu không tốt thì phải quay trở lại tìm algorithm…
Nhưng nhiều khi em cũng thắc mắc không biết cách tiếp cận này (thiên về theory một chút và dùng coding để hỗ trợ) có thích hợp không ? Nếu không thích hợp thì theo anh Hưng em nên làm thế nào ?
Hi Cường,
Dĩ nhiên thích theorem proving và các hướng lý thuyết nói chung không có gì sai.
Tôi chỉ không thấy thoải mái khi ý thích này thòng theo “vì theorem proving ít involve debugging/coding” (tôi hiểu là ít “cơ bắp” hơn một chút). Hai cái đó nên độc lập với nhau. Chúng ta thích một ngành lý thuyết vì bản chất thú vị của nó (ví dụ như nó trả lời những câu hỏi fundamental mà trí tò mò khoa học của ta cần được thỏa mãn) chứ không cần phải thêm là ta thích vì nó “ít coding” hơn.
Khi đã nghĩ như vậy, nếu các câu hỏi fundamental đó cần coding thì ta coding, cần theorem proving thì ta chứng minh. Tất cả đều chỉ là công cụ và ta dùng công cụ nào hiệu quả/thích hợp nhất để trả lời. Không hiểu tôi nói vậy có rõ ý không?
Em đã hiểu ý anh.
Cám ơn anh Hưng đã trả lời.