John Fredsted

2238 Reputation

15 Badges

20 years, 170 days

MaplePrimes Activity


These are replies submitted by John Fredsted

I have noticed that too, see my posts Pacman post and Maple tags intentional. Frankly speaking, it is quite depressing to know that ones meticulously formatted posts now partially lie in ruins visually.

I have a hard time understanding why something that worked almost flawlessly earlier (if one knew exact how to enter the code) have now been replaced by something that seems never to work, and, even more, why no real action to resolve this issue seems to be taken.

Even though I have used `+`(...) and `*`(...) many times, I have never given `.`(...) a thought.

It is from attending this forum that I have gathered over time a bag of these nice compact notations. Now, there is one more in the bag.

Even though I have used `+`(...) and `*`(...) many times, I have never given `.`(...) a thought.

It is from attending this forum that I have gathered over time a bag of these nice compact notations. Now, there is one more in the bag.

Actually, I did wonder about the format of your code. For a moment I thought it was code in document mode, which I never use, but trying that in Maple persuaded my otherwise. You are quite free to laugh at my ignorance - the only excuse I have is that it was before my first cop of coffee.

Anyway, I don't have any experience with C, unfortunately, but why do you use four nested loops when two, as done below in analogous Maple code (if I have not completely misunderstood what you want to achieve), will do:

maxRow := 1:
maxCol := 1:
maxValue := k[maxRow,maxCol]:
for a from 1 to 20 do
for b from 1 to 20 do
	if k[a,b] > maxValue then
		maxRow := a;
		maxCol := b;
		maxValue := k[a,b];
	end if
end do
end do:
maxRow,maxCol,maxValue;

Actually, I did wonder about the format of your code. For a moment I thought it was code in document mode, which I never use, but trying that in Maple persuaded my otherwise. You are quite free to laugh at my ignorance - the only excuse I have is that it was before my first cop of coffee.

Anyway, I don't have any experience with C, unfortunately, but why do you use four nested loops when two, as done below in analogous Maple code (if I have not completely misunderstood what you want to achieve), will do:

maxRow := 1:
maxCol := 1:
maxValue := k[maxRow,maxCol]:
for a from 1 to 20 do
for b from 1 to 20 do
	if k[a,b] > maxValue then
		maxRow := a;
		maxCol := b;
		maxValue := k[a,b];
	end if
end do
end do:
maxRow,maxCol,maxValue;

Thanks, Doug. This very post will make my leaf become red - what a milestone :-).

Using the GET-parameter page=1 as well as an anchor-ID the posts are reachable: my previous post Broken thread is now reachable from this post.

Note added: Corresponding to the note added in my previous post, using page=1 could become incorrect if the number of posts per page under the "Comment viewing options" are increased. How can these potential inconsistencies be avoided? Surprisingly, though, it seems that sticking by page=1, as used in the link above, the browser can still correctly locate the post.

My previous post Paragraps (in this thread) seems not to be reachable by clicking the link because this long thread is now broken across two pages so that the browser cannot locate the HTML-anchor corresponding to the comment-ID.

Note added: The problem does, of course, disappear if one chooses a higher number of posts per page under the "Comment viewing options" which I have just become aware of. However, this does not settle the issue because different users can have different settings.

I certainly have noticed that switching from source mode to WYSIWYG mode and then back again usually introduces some paragraph tags. That, however, I can live with.

What problems are you experiencing using the backspace?

Any update on these?

I am still missing them. The only way now is to switch back and forth between the WYSIWYG view and the source view.

Of course, your suggestion is the correct approach.

Actually, I did suspect that there were some builtin types concerning odd/even functions: I did look up the help page on type but after having found that the type odd concerned only integers I hastily and wrongly concluded that there were none concerning odd/even functions. Obviously, I should have been a little more patient.

Of course, your suggestion is the correct approach.

Actually, I did suspect that there were some builtin types concerning odd/even functions: I did look up the help page on type but after having found that the type odd concerned only integers I hastily and wrongly concluded that there were none concerning odd/even functions. Obviously, I should have been a little more patient.

I was almost certain that you couldn't resist the temptation to crack also this nut :-).

Or what about the 65537-gon? :-).

I certainly didn't expect anybody to give a derivation like that (if any at all), but I guess that says quite a bit about your contra my abilities in mathematics and in the use of Maple.

First 43 44 45 46 47 48 49 Last Page 45 of 68